We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Network Nightmare: Ruling the nightlife between shutdown and boot with pxesploit

00:00

Formale Metadaten

Titel
Network Nightmare: Ruling the nightlife between shutdown and boot with pxesploit
Serientitel
Anzahl der Teile
122
Autor
Lizenz
CC-Namensnennung 3.0 Unported:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen.
Identifikatoren
Herausgeber
Erscheinungsjahr
Sprache

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
The best techniques for exploitation, maintaining access, and owning in general move down the stack, using low-level code to bypass security controls. Take the preboot execution environment and get bios-level access to the hardware from across the network, outside any control of the on-disk operating system. In this presentation I will detail the pxesploit attack I wrote, releasing a new metasploit-based comprehensive PXE attack toolkit to deliver any payload reliably to many different operating systems. Also new will be the ability to host a PXE attack through a meterpreter session in memory, using it to escalating privileges and own remote networks. Matt Weeks has performed research in mathematics in chaos and cryptology, and focuses on information security. He enjoys finding ways to break application security, writing shellcode, and creating post-exploitation techniques. Also known as scriptjunkie, he is a developer for the Metasploit framework, wrote the sessionthief MITM tool, and broke a cryptosystem based on chaos theory.
54
106
112
SchlussregelRechnernetzBootenKryptologieMathematikTwitter <Softwareplattform>Lokales NetzThermodynamisches SystemAnalysisProxy ServerKryptoanalyseIntelFirmwareKontrollstrukturComputerSpezialrechnerPhysikalisches SystemMetropolitan area networkArithmetisches MittelBootenMultiplikationsoperatorAggregatzustandSystemverwaltungExploitBildgebendes VerfahrenSoftwaretestNormalvektorHackerRechnernetzSoftwareschwachstelleDämon <Informatik>Dichte <Stochastik>Thermodynamisches SystemGüte der AnpassungOrdnung <Mathematik>IntelKryptologieZweiNeuroinformatikHash-AlgorithmusCASE <Informatik>TypentheorieServerSpeicherabzugGamecontrollerFramework <Informatik>NetzbetriebssystemSystemstartBitFestplatteSoftwareentwicklerDifferenzenrechnungGebäude <Mathematik>ZahlenbereichCodeNetzadresseFokalpunktHintertür <Informatik>Web ServicesBaumechanikSkriptspracheMereologieTwitter <Softwareplattform>ComputersicherheitUmwandlungsenthalpieProtokoll <Datenverarbeitungssystem>TermWurm <Informatik>VirenscannerDifferenteSchreib-Lese-KopfGraphische BenutzeroberflächeGeradeLesezeichen <Internet>Notebook-ComputerEinflussgrößeNabel <Mathematik>SondierungFirmwareBrowserFirewallAnalysisHardwareProxy ServerCoprozessorSchnelltasteForcingDienst <Informatik>Mini-DiscWeb logExistenzaussagePi <Zahl>DruckverlaufPlastikkarteWeb SitePeer-to-Peer-NetzInterface <Schaltung>MAPLokales NetzInverser LimesNP-hartes ProblemEinsKryptoanalysePhysikalismusNichtlinearer OperatorComputeranimation
RechenwerkElektronische PublikationSystemstartExogene VariableRechnernetzServerMaßerweiterungBootenClientProtokoll <Datenverarbeitungssystem>Dynamic Host Configuration ProtocolMereologieUmwandlungsenthalpieDatenfeldSchnittmenge
MaßerweiterungDynamic Host Configuration ProtocolCodeLokales NetzStrom <Mathematik>Bildgebendes VerfahrenServerSoftwareKonfigurationsraumRegelungSystemstartStrategisches SpielSpeicherabzugDemo <Programm>ATMCASE <Informatik>TropfenRechter WinkelKernel <Informatik>HalbleiterspeicherSoftwareBildgebendes VerfahrenBootenWurm <Informatik>SystemstartInformationClientReelle ZahlKonditionszahlFestplatteDateiverwaltungGamecontrollerTreiber <Programm>SystemverwaltungPhysikalisches SystemDynamic Host Configuration ProtocolDifferenteServerElektronische PublikationNichtlinearer OperatorThermodynamisches SystemDoS-AttackeCodeRechnernetzAdressraumUmwandlungsenthalpieSchwebungDiagrammSkriptspracheDistributionenraumSchreib-Lese-KopfHackerProgrammierungKonfigurationsraumMereologieRegelungUniformer RaumBestimmtheitsmaßNetzbetriebssystemPunktNabel <Mathematik>MultiplikationsoperatorVerzeichnisdienstInnerer PunktMini-DiscSpeicherabzugComputeranimation
MenütechnikLokales MinimumEin-AusgabeSpeicherabzugRechenwerkBacktrackingPackprogrammElektronische PublikationSkriptspracheDateiverwaltungNetzadresseVideokonferenzMailing-ListeThermodynamisches SystemDistributionenraumLoopBildgebendes VerfahrenKernel <Informatik>KonfigurationsraumDynamic Host Configuration ProtocolServerNabel <Mathematik>ZweiCASE <Informatik>KugelkappePunktInterface <Schaltung>RoutingRechnernetzSpannweite <Stochastik>SystemstartDatenstrukturBootenNeuroinformatikLastGraphische BenutzeroberflächeTropfenFigurierte ZahlProgramm/Quellcode
RechenwerkLastThermodynamisches SystemServerKernel <Informatik>HardwareZweiSystemstartAdressraumLAN-PartySchreib-Lese-KopfComputerunterstützte ÜbersetzungBootenNabel <Mathematik>Programm/Quellcode
DateiverwaltungGamecontrollerFestplattePartitionsfunktionRechnernetzPlastikkarteThermodynamisches SystemNabel <Mathematik>BildschirmfensterWurzel <Mathematik>TaskBitCASE <Informatik>MultiplikationsoperatorPunktComputeranimation
CodeRegelungTreiber <Programm>p-V-DiagrammInjektivitätWurzel <Mathematik>BootenSystemstartBinärcodeEinbettung <Mathematik>KonfigurationsdatenbankCoxeter-GruppeAdressraumPunktUmwandlungsenthalpiePatch <Software>TeilbarkeitProgrammMenütechnikMobiles EndgerätWurm <Informatik>Thermodynamisches SystemPlastikkarteBinärcodeElektronische PublikationCodeBootenRichtungPunktHackerWurm <Informatik>Software Development KitCoprozessorSchaltnetzBildschirmfensterSchlüsselverwaltungMailing-ListeSystemstartSystemverwaltungMAPRechnernetzPhysikalisches SystemCommon Information Model <Elektrotechnik>Wurzel <Mathematik>Nabel <Mathematik>LoginProzess <Informatik>SpeicherabzugInstantiierungComputervirusQuaderDienst <Informatik>Domain <Netzwerk>Notebook-ComputerHash-AlgorithmusEinbettung <Mathematik>DifferenteKonfigurationsdatenbankVersionsverwaltungLeistung <Physik>ClientRegelungCASE <Informatik>Rechter WinkelAutorisierungNetzbetriebssystemTreiber <Programm>RootkitMultiplikationsoperatorRPCApp <Programm>TropfenSystem FStapeldateiComputerarchitekturPasswortVektorraumHalbleiterspeicherProjektive EbeneComputersicherheitInjektivitätTouchscreenZahlenbereichBefehl <Informatik>Güte der AnpassungWeb SiteUmwandlungsenthalpieSkriptspracheFestplatteGamecontrollerServerComputeranimation
TouchscreenBinärcodeDienst <Informatik>Prozess <Informatik>Einbettung <Mathematik>CodeElektronische PublikationArchitektur <Informatik>Minkowski-MetrikThermodynamisches SystemAdditionKonfigurationsdatenbankSchlüsselverwaltungProgrammbibliothekSpieltheorieWort <Informatik>Pivot-OperationROM <Informatik>SystemprogrammierungLokales NetzMaßerweiterungSystemstartSystemaufrufWurm <Informatik>GasströmungDynamic Host Configuration ProtocolKernel <Informatik>Demo <Programm>ServerBildgebendes VerfahrenDynamic Host Configuration ProtocolProzess <Informatik>GarbentheorieSchlüsselverwaltungKonfigurationsraumWorkstation <Musikinstrument>SystemstartOrdnung <Mathematik>HalbleiterspeicherSystem FLAN-PartyHochdruckClientMaßerweiterungRegulärer Ausdruck <Textverarbeitung>Thermodynamisches SystemHauptidealZeichenketteInterpretiererTypentheorieWurm <Informatik>VersionsverwaltungTelekommunikationMathematikBootenPhysikalisches SystemStrömungsrichtungKonfigurationsdatenbankDifferenteBildschirmfensterGamecontrollerProxy ServerFestplatteCodeTouchscreenMinkowski-MetrikBinärcodeDateiformatComputerarchitekturEinbettung <Mathematik>Nabel <Mathematik>SystemzusammenbruchDienst <Informatik>SpeicherabzugLoginNetzbetriebssystemSoftwaretestExogene VariablePunktWärmeausdehnungKonditionszahlMereologieInstallation <Informatik>SkriptspracheLastDickeÄquivalenzklasseHyperbelverfahrenAggregatzustandZahlenbereichZusammenhängender GraphMailing-ListeBinärdatenCASE <Informatik>Elektronische PublikationProgrammbibliothekDatensichtgerätModallogikLokales NetzPivot-OperationNP-hartes ProblemKernel <Informatik>
Demo <Programm>ExploitNabel <Mathematik>Elektronische PublikationMaßerweiterungInterpretiererCASE <Informatik>Dynamic Host Configuration ProtocolLastBildschirmfensterRechnernetzSchnelltasteServerThermodynamisches SystemThumbnailBinärcodePunkt
VIC 20LastServerThermodynamisches SystemBildschirmfensterExploitFestplatteLokales NetzZählenReelle ZahlBootenSystemstartZweiPunktMessage-PassingProgramm/QuellcodeComputeranimation
Demo <Programm>KraftDynamic Host Configuration ProtocolServerFirewallVirtuelles LANInternationalisierung <Programmierung>Domain <Netzwerk>KonfigurationsraumSystemprogrammierungGrenzschichtablösungSystemstartKonsistenz <Informatik>Dienst <Informatik>FirmwareMaßerweiterungRadikal <Mathematik>PasswortGüte der AnpassungOffene MengeWurzel <Mathematik>Vorzeichen <Mathematik>GamecontrollerThermodynamisches SystemRoutingBootenSchnittmengeShape <Informatik>Virtuelle MaschineRechnernetzDynamic Host Configuration ProtocolDifferenteProgrammfehlerMailing-ListeServerSoftwareMechanismus-Design-TheoriePhysikalisches SystemFirewallMathematikKonfigurationsraumClientNeuroinformatikEndliche ModelltheorieFirmwareIntServHauptplatineHilfesystemCodeSystemstartUmwandlungsenthalpiePublic-Key-KryptosystemForcingAutomatische DifferentiationATMRPCVirtuelles LANNetzadresseNabel <Mathematik>MaßerweiterungDigitales ZertifikatPunktSoftwaretestComputersicherheitMereologieSystemverwaltungRechter WinkelPhysikalismusComputeranimationProgramm/Quellcode
ZahlenbereichWeg <Topologie>
Transkript: Englisch(automatisch erzeugt)
So anyway, welcome to Network Nightmare. Um, ruling the nightlife between shutdown and boot with PixiSploit. I want to take a few minutes to tell you a little bit about myself, because most of you probably haven't heard any of my talks, the other one that I gave once,
or might not be familiar with me. I've done a lot of development with the Metasploit framework. I wrote the new GUI. I wrote a bunch of different exploits, payloads, post-exploitation features, stuff like that. I also go by ScriptJunkie, so if you see tools or something like that, that's probably me. I do have a Twitter, which I don't use a whole lot,
but there's a lot of peer pressure, I might start using that one more. And you can find my website at scriptjunkie.us. I run a blog, try to keep that dealing with security research, stuff like that, and if you want to contact me, you can go ahead and do that at scriptjunkie,
look at your keyboard, scriptjunkie.us. So, first of all, let me give you a brief overview of what this talk is about. So, this is designed with the scenario in mind that you have access to a network somehow. Maybe you've gone and, you know, plugged your computer into the network, or maybe you've compromised the system in the LAN.
You got somebody to go click OK on your signed applet or exploit their browser or PDF or however you did that. And what you need to do is you need to escalate privileges to root. You need to go compromise other systems on the network to get what you want to get. They may be different operating systems, they may be harder.
Currently, you may do a lot with abusing legitimate credentials, so maybe you've gotten credentials from whatever keyloggers, or maybe you could escalate privileges and dump hashes. That's an option, but if that isn't working out for you, what you've got to do is you've got to go ahead and somehow use another method to take over this other system.
So, you might think that, well, now it's going to come down to I've got to exploit some service on the other system, but that can be really tough. You might be able to pull off a web service exploitation, but you might have to do, you know, real man's hacking and go ahead and start fuzzing or do static analysis
to try to identify vulnerabilities in some daemon that you know they have running and try to come up with an exploit for those, and then you're still stuck because they may have exploit mitigation technologies like DEP ASLR, which you've got to try to come up with a way to bypass. And even if you can do that, finally you've got your session
and you're still running as some limited network service and you still have to escalate privileges. So, it can be a lot of work, and a lot of people don't do that. Well, what if this is, you know, what if there's an easier way? And that's what this is about since this talk is really for the lazy hackers, since I know you guys out there are pretty lazy.
And so the idea here is, why don't we run an offline attack? And so with offline attack, you're probably thinking, you know, I'm going to walk up to the system, unplug the hard drive, plug it into my external reader, go read whatever data I want off or drop whatever I want onto the disk, and it's going to be simple as pie. That's kind of like a variant, another variant would be the evil mate attack.
If you're not familiar with the evil mate attack, this is basically how it works. I know a lot of you probably have laptops that you left in your hotel room. I actually paid the hotel mate to go over to each of your rooms and go plug a USB drive into your laptop, so when you come back, I'm going to have a shell on all your systems. That's basically how that one works.
Alright, the other type of offline attack would be, you could, from the crypto world, they'd say this would be a rubber hose cryptanalysis, and XKCD has illustrated that beautifully for us here. You go ahead and get credentials via brute force of another kind.
So there's lots of good ways that you can go ahead and run these offline attacks. There are some problems with them, though. Usually you will need physical access to the system, and if you happen to be nearby, that's okay, but if you're trying to do a pentest on a company on the other side of the city, state, nation, world,
that's not going to work out. Also, you're very likely to get caught, and since you're actually there by caught, it doesn't mean they know your IP address, it means you're in handcuffs. So that's also something that you want to avoid, because jail is not a fun place.
It's a place with bars, not a chroot. It's very bad, you don't want to be stuck there. Having said that, physical access attacks are still common, not the rubber hose cryptanalysis type, but the pentester walks into a building and goes ahead and plugs in his phone plug or whatever, and goes ahead and gets access.
So it is still an option. Well, that brings us to the focal point of this talk, which is the pre-boot execution environment, which is going to provide us with a way of going ahead and taking over lots of other systems on a LAN that we have access to. Couple things, this is not a new vulnerability,
this is a protocol insecurity, and it has been around forever. What I'm presenting here is really a new way of exploiting that. I've not seen a lot of security talk on the subject. So let me tell you a little bit about PXE. Intel and SystemSoft introduced this a long time ago.
It's a protocol, they produce firmware, which is loaded into most BIOSes to boot from the network interface card if you have network booting enabled. And since this runs from the BIOS, it will provide you with full system control. You can go ahead and run code straight on the processor,
access the hard drive, access the hardware, do whatever else you want. It totally bypasses anything on the hard drive if you're booting from the network since the hard drive is never touched. Any operating system, any virus, firewalls, all that kind of stuff. The other good part about this is it works no matter what operating system you have. You don't have to really find out a lot about this system.
You can just use the PXE specification itself, which gives you enough to work with. And best of all, it works over the network. So you do not have to be physically at this system to run this attack. So bring it down to layman's terms.
How it works is you turn off your computer, whatever you do, I know a lot of you have a lot of attachment to your computer, so you tuck it in at night and sing it a lullaby, whatever you do. It goes down, and then before the operating system boots, when that boots up, it notices something's a little bit different,
something's a little bit wrong. You might have something that you didn't really expect there. So you didn't really want this to happen to you. So it makes a good attack, though. So the question is, all right, this sounds like a cool idea.
How likely am I to see this? And from what I've seen, I'm not aware of any widespread surveys or other measures which tell you how often this thing is available, but just about every system BIOS that I've seen
is capable of booting off the network. And I have seen it left on. In this case, what I'm talking about is the network boot is set in, it's enabled and set in a higher place in the boot order than the hard drive. What normally happens is the system boots, it searches for a PXE server,
after a few seconds times out, gives up, and then does a normal hard drive boot. So I'm not saying you're actually using PXE all the time to actually boot. It's just left on. And like I said, I've seen that. I've also seen it occasionally enabled when admins, they'll go around,
enable this, and then use it to, let's say, push out an image, and then turn it off. Or I've seen it just left off all the time. So it definitely may be something that you encounter. And so, okay, Intel has gone ahead and put this horrible BIOS level backdoor into all of our systems.
How could they possibly do this to us? Well, my guess at the top sysadmin reasons for why this would be enabled in an environment would be image deployment would be number one. This is where I've seen it most commonly used, just to go ahead and push out images. In a similar vein, this could also be used for system restoration.
Every time the system boots, it gets a clean image, and it's ready to go. Or maybe it's enabled just in case we do want to push out images or do something like this, and we just leave it there, because it's another feature that we don't have to worry about running around all of our systems to turn back on. Or, my favorite, PXE? What's that? I don't know.
All right, so how does PXE work? It follows an extension of DHCP and TFTP protocols. What's going to happen is, in the DHCP discover, the first pack that's going to be sent out on port 67,
it's going to have an additional field, an option, which specifies this is a PXE request. The DHCP server, if it supports that, is going to send back a response saying, here's your IP, and here are some PXE-specific options saying, yes, I've got it. I have a PXE server for you to boot from.
Normally, it will include a server IP and a file name. The client will not have to go ahead and do this part, although it can make another request to get the file name. Then what happens is, it makes a TFTP download from the TFTP server specified,
which, with the file name that was specified, downloads that and goes ahead and runs it. That will be the network bootstrap program. It will be loaded up at address 0x7c00 and executed in real mode.
This gives us a couple difficulties. You might be thinking, awesome, I'll just plug my shellcode in and let it fire, but you'll run into some problems. First of all, it's passive. You're going to have to wait for a system to boot to use this. However, in some cases, you may be able to send out a wake online packet and make it boot, or use a denial of service exploit
and make it reboot, something like that. That's not a big issue, but there might be some waiting involved. The main big issue, or one of the big issues you're going to have is you're going to have to beat the real DHCP server. When it sends out its request, you're going to have to send out your request and beat it.
For some reason, DHCP servers, like taking in your IP and saving it to a log file, and updating Active Directory, and saying hi to the neighbor's dog, and all this other stuff. I have not found this a difficult race condition to beat, but it is something you'll have to take advantage of. At that point, you're going to have to, for the forwarding to TFTP part,
you will have to have a TFTP server available. This is not a huge deal, but once again, it's another thing that you're going to have to have. Then you'll be executing code. This is the biggest difficulty, hands down. You're going to be executing code basically on the bare metal in real mode. Now, some of you, probably like a third of you,
are thinking, I don't know what real mode is, but it sounds terrible and you're right. The other majority of you, or most of the rest of you, are thinking, I know what real mode is, and that sounds terrible. You're right. There's a very small portion of you who are probably sitting out in the corner somewhere who are thinking, awesome, I love writing bootloaders.
I'm going to break out my assembler and start coding up int1ah instructions and go ahead and own this thing. This is going to be great. Like I said, this talk is for the lazy hackers. We'll get your head examined later. Even if you do want to code up one of these,
the serious issue there is, if you want to interact with one particular operating system, you can, without too much difficulty, read a file off NTFS. But then if you want to change something, you may not be able to write that without having a whole lot of drivers. You may not be able to access the whole hard drive. You may not support all the other file systems
you want to encounter, et cetera, et cetera. So that's not something I did. This is a helpful diagram from the PXE specification of what that network bootstrap program is going to need to do. And no, it's not fun. Thankfully, however, there are admin tools which have already been created, which can help us do this.
The problem with that is most of them are not written to be attack tools. Like I said, the biggest use that I've seen is with using PXE as imaging systems. So there are those tools, and then there's also PixiLinux. So first of all, imaging systems. Now, imaging systems, you will need this software installed,
and it does take a lot of time, and none of that really matters because this is how imaging works. We're going to take your hard drive, and we're going to overwrite it with whatever our image is. So if you're trying to extract data from a system, if you're trying to compromise a system and go ahead and pull anything useful off of it,
if you're trying to... Think of it this way. If you're trying to get information from Hiroshima, this is not a good tool. This will not get you the information that you want. This will do this. This is bad. If you're a pen tester, your clients will sue you. So don't do that.
So that leaves us with PixiLinux, which is really an awesome tool. Now, PixiLinux is a Linux bootloader kind of like IsoLinux or SysLinux to boot off a CD or hard drive. And what it will do for us is it will read in a configuration file. We can have lots of different options,
but basically what it's going to do is it's going to pull up a kernel and initrd, which is an initial RAM disk, which will be basically an initial file system in memory. And it will go ahead and execute whatever program is specified there. So that is convenient. Now, having said that, although it is nice,
it does entail some difficulties. So like I said, we're once again manually going to have to install all these servers, configure DHCP to forward this to us. And this is difficult to deploy. Most likely we're going to be in the case where we're maybe not sitting with physical access to the LAN and maybe we've compromised one system there. This is difficult in and of itself to deploy remotely.
Also, the PXE bootable systems that are generally available out there aren't really written as attack tools, aren't really easy to drop payloads into and do things like that. However, you can go ahead and use this for online control.
So what online control is, is we're going to take a pixie bootable system. There are different Linux live CDs which can be pixie booted. DSL, Tinycore, and Knopix are one of those. DSL and Tinycore are really awesome because they're some of the only Linux distributions I know of that can fit entirely within an initrd.
So you won't need anything other than pixie Linux to boot those. Knopix can boot and then connect back via NFS. That will entail some difficulties, which I'll talk about later, but I just stuck with Tinycore because it's fast and small and all self-contained. So this is basically what you're going to do.
You're going to take the live CD, remaster it, set up some scripts there so that when you boot it via PXE the scripts will auto-run, connect back, and you'll get a shell. So, let's try this out.
Start this. Alright, so in this case, what I'm doing is I'm starting with a backtrack image and a Tinycore ISO. What you're going to do is you're going to create a folder to extract the ISO into. You're going to create a folder to serve your PXE files from. This is going to be your TFTP server folder. And that's going to have your pixie Linux kernel initrd
and configuration file in it. And then you're going to create a folder initrd, which you're going to extract the initrd into, add your scripts, package it back up, and it'll be ready to go. So, first thing we do is extract the ISO.
I'm making this video available so if you want you can see all the steps necessary to go ahead and do this yourself. As you see, in the ISO, all we have is isolinux, which is a bootloader BZ image, which is a kernel, and tinycore.gz, which is the initrd. And we're going to take the kernel and initrd,
drop it into our pixie folder, and then what we're going to do is we're going to use the metasploit pixisploit server. In this case, we're not going to jump right into everything that that has with it. We're just going to use this as an easy-to-setup
DHCP and TFTP server. And in this case, update one is pixilinux, update two is a configuration file, update three will be the kernel, and update four will be the initrd. So all we have to do is paste those files in here, rename our files to match the metasploit names
of update form and update three, and then we'll just tell metasploit to use our images instead of the pixisploit attack images that it has with it. So at this point, we have tinycore set up to boot
from pixilinux, but we haven't added our script. So what we're going to do is we're going to extract the file system. It is a gzipped CPIO archive, so thankfully gzip and CPIO are included with most Linux distributions. As you can see here, we've extracted it. It's a typical Linux file system structure.
We're going to pick a script which runs on boot. You could pick any script you want. I just picked one in etsyinit.d, and we're going to go ahead and add our shell here right up at the top. Now, one concern is when this is run, the network interface might not be up, so we're going to put this in a loop, wait a few seconds, in this case 10 seconds,
then we're going to give ourselves an IP address with ifconfig, and then we're going to send ourselves a shell back with netcap. And the IP of this system, this backtrack system that we're running off of, is 101,
and so it'll connect back. And then we'll finish that in a loop and put an ampersand at the end. That's very important, because if you don't do this, then the init scripts will never run, and your system will never boot, and you'll be stuck. So, we go ahead and save that out. Now we've modified our ramdisk.
We're going to pack it back up, or we'll use find to send a list of files to CPIL, which will go ahead and compress the, or package up the initrd, gzip it, and send it back over our file. At this point, we have all our files ready for the connect back.
I started in RPC, so I can just fire up the GUI, and that will connect for us. And when that loads, my computer's not very fast. Metasploit comes up. So what we use is the pixisploit auxiliary server,
and there are lots of options we could give it. Most of those will be automatically figured out. It'll figure out your IP, pick a range to start from. The only thing we're going to change is the TFTP route, so that it serves up our files,
and then that'll start the TFTP and DHCP servers. So at this point, we are almost ready to go. What we're going to do is we're going to set up a handler. We could do this in Metasploit, but I just did it in Netcat for the connect back shell. And wait for our target system to boot. If you have the MAC address, you could send a wake online packet now and get it to boot.
So it boots, searches for a PXE server. That goes ahead and boots. I'm going to queue up a command to be executed when I get a shell back. It loads the kernel. It loads the initrd, and when that happens in just a second,
the system will start booting. It starts detecting the hardware. It'll be a few seconds until it is able to access the network card. As you can see, Tinycore has started, and we are waiting for the connect back. And the shell comes back, and we've just popped it.
As you can see, we're running as root online control live. You can see our file system. At this point, what we'll probably want to do is look at the hard drives which are available, go ahead and mount them. In this case, there are a couple of partitions. And let's see what's in this system that we just compromised.
Sure enough, this is a fully patched Windows 7 64-bit system, and we have full control over it, and that only took five minutes from start to finish making the entire task.
All right, that was fun. So there are some good advantages of online control. First of all, any operating system. We ran entirely from memory. This could have been a Linux system. This could have been a Mac system. It could have been, I don't know, does Mac have network boot? But it could have been any system, and we have the flexibility to put whatever we want on it,
decide what we want to do with it, and we don't have to go ahead and code the whole attack beforehand. Now this does have some serious problems, and the first and biggest problem is in drivers. When I tried this before, what I found was only about half the systems I tried,
the drivers would work out of the box. What happens is even if in Linux somewhere there's a driver for your card, and you might be thinking, well, Linux has drivers for just about everything, and it does, but that may not be packaged into this tiny initrd that we're sending over to the client. What I found was the connect back was not very reliable,
and if you don't get the connect back, this gets you absolutely nothing. The other big problem with this is the fact that when a system is booting, chances are someone just pushed the power button, and they're waiting for it to boot up. While you can disable the X server and make the screen blank, or show whatever you want to show, the fact is the system is not booting,
and eventually they're gonna get tired, and they're gonna push the power button, and you're gonna lose your shell, and you're gonna be stuck. Also with visual indications, in this case a tiny core screen came up, and they're gonna know something's bad, and that's when they go ahead and call the security guys, and we fail.
There's another way. That would be with offline code injection. The fact is we might as well go ahead and code it up, because really we're gonna do it anyway without offline code injection that is dropping our code to be run on boot so that we can run as admin or root inside the system
as opposed to root outside the system. We're gonna need to do that because say we want to listen for key logs. We're gonna have to watch somebody log into something, maybe take a domain admin's hash, or something like that. There's all kinds of stuff that we're gonna want to do that we can't do from outside the system. We'll want to be running inside.
On Linux this is not difficult. What we can do is we can take our shell code, we can write it to one of those scripts in etsyinit.d, or drop it in a bashrc, or any of the other million bashrc files, or we could add a user. Let's say the system has SSH enabled. We can just drop something in etsy password
or even add an entry to the authorized SSH keys, and we will be ready to roll. In Windows we have some difficulties which I'll talk about later, but I came up with a list of seven different ways that you can go ahead and do code injection offline. That's with bootkits. We can do it with binary planting, with binary swapping,
with binary embedding or modification, dll preloading, registry edits, or a combination of the above. At this point maybe you're thinking, oh, but I have BitLocker, TrueCrypt, whatever. You can't get me. You could use bootkit techniques,
might be able to bypass some of that stuff, but that's not the research direction that I went in, and it seemed like a lot of work, so we're lazy hackers. Moving on, bootkits. There's a lot of different bootkits which are available. PXE is kind of an ideal way to deliver bootkits because even if you can't read-write
certain hard disk sectors from within, let's say, Vista 764, with a bootkit you don't have any issue with that with PXE. There's lots of different bootkits which have been released or have been made available or out in the wild or they're on your laptops right now because they may just put them on there.
And so Cinewall is one of them. Stoned is another one that was released at Black Hat a couple of years ago. Whistler is one. TDL, also known as Allureon, also known as TDSS, also known as Just Stop Giving It Names. EIBootroot is one that was deployed.
This is kind of the motivation here. They deployed it with a virus they called the pixie virus. This is, as far as I can tell, one of the only instances where PXE was used as an attack vector. So they are available. And they have some cool features, they have some cool advantages. So first of all you get extra points for skills because it's pretty cool to be able to run a bootkit
and get yourself bootkit privileges. You can also end up running stealthily inside this system and it gives you full access. So those are all awesome, awesome things. There are some disadvantages with that, however. Bootkits are very operating system specific.
And if you don't have the right architecture, the right operating system support, this isn't gonna work. So it's gonna take a lot of effort to try to maintain that. Also, if you're spawning a rootkit with this, what happens a lot of times is Microsoft will update PatchGuard,
which will then crash your system and that's happened to a lot of the bootkits here. So it takes a lot of work. And like I said, we're all lazy hackers, so that seems like some difficulty. One illustration for this, the stone bootkit was presented, like I said, a couple years ago in 2009 with great fanfare. I don't know if the author's here, but he said he expected this to be
the number one bootkit used in 2010. And yet by February 2011, he had released a statement on his website saying, stone is out of date, go find other projects. It's not gonna work. Awesome, awesome projects, but not what we're gonna run with here.
Now an easy way would be with binary planting. So you might be thinking, just drop a file in the startup folder. And that's right, here are the startup folders for various versions of Windows. So we can just drop our executable in there. And that will go ahead and run when somebody logs in. The issue with that is, whoever's logging in might not be privileged
and we might be stuck with where we likely started, which is just another user level shell and that doesn't give us the privileges to do what we want, dump our hashes, go on, do whatever else. So we could use the wbem.mof method, which was used by Stuxnet.
The problem with that is, and Metasploit does have a mixin to do this. It's implemented, you can use this as an option in psexec Metasploit. But it's not compatible with Vista and later, so that's probably not your best bet. Another option would be swapping out binaries.
So you take a core system process, which you know is gonna run on boot, like services, service host, wininit, CSRSS, LSASS, any of the core Windows processes which you know are gonna run on boot. And you put your own executable there, move it to a .bac.exe file or something,
and then when Windows boots, it will run your executable, your executable spawns off the real executable and runs whatever payload you have, and then you go ahead and exit out and use a DLL or other processor or something to swap the executable back. I've tried this, it works awesome,
at least on my XP system. It's guaranteed remote code execution, you don't have to wait for a login, it runs you with full privileges, and it's portable, it runs on different versions of Windows, it's awesome, there's one problem with that. It's kind of a big problem. A lot of these early boot processes
are monitored by the operating system or other boot processes, and if one of them exits, it's going to cause a blue screen, because it knows, oh no, the core component of the system crashed, even if the equivalent process is still running, it's still going to throw a blue screen. However, to clean up after yourself
and swap the original executable back where it belongs, you will need to exit your running executable. So there's not really any good way you can get around blue screen in the system unless you leave the system in a perpetually broken state. Well, it's not really broken, but it's not going to do what you want it to.
So you could move to one of the later boot services, like the principal or spoolsv.exe. Now, these are useful because they're non-critical, so the principal doesn't have to run. It won't blue screen if it exits, but the problem with that is it doesn't have to be enabled.
They might have the principal disabled if this is maybe a core server or something like that. So it's not as reliable as I would like, but it's still definitely an option for attacking workstations. So that brings us to binary embedding or modification. So one thing you can do is you can take your shell code and add a new section to the exe,
embed it into one of these core boot processes, and then it will run. So I wrote some code on my display. You can go ahead and do that with MSF encode or MSF venom now, which is the new version. There are some problems with that. You can't straight up do this,
because if you have your x86 shell code and you go ahead and drop that into your x64 process, you will get a crash, which will then give you a blue screen, which will then get you sued. The other problem is you might not have Slack space. The executable might not be in the format that you want, so that is one issue. And the big issue is, of course, cleanup. If you still want to clean up after yourself,
you still have all the same problems with trying to clean up. So then you might say, okay, well, I'll just use DLL preloading, so I'll just take a system DLL, which I know is gonna be loaded up, swap it with my own. That'll have my shell code in it. That'll do whatever I want it to. Or maybe I could load it higher in the search path. Once again, you will have to watch for the architecture,
but you can make x86 and x64 versions, so that is still an option. Another problem is with the imports. This DLL's probably going to be loaded because it's probably going to be used, and you will have to emulate or somehow proxy the DLL calls, which are made to that DLL.
So this, because this changes in different versions of Windows, I didn't want to go ahead and mess with the difficulties inherent with that, but this is still an option, and it is still available. So you might be thinking, okay, well, I'll just put myself in the registry. Well, there's the run keys in Microsoft Windows current version
in HKLM or CU, and that's reliable. Your executable will get executed. Problem is this is basically the equivalent of a startup folder. It's going to be running as the user. Or you might say, okay, I know I can add a service. Just add something in current control set services. Now you're running privileged.
You're guaranteed. You don't have to wait for a login. There are some differences in the sub-keys, which you have to implement, or the values which you have to implement, but that's a great option. Or another thing that you could do to work around that difficulty is to edit a service.
So you change the bin path to a service that you know is running. You change the start and type to make sure that it runs, and then your executable will guaranteed be executed. This will work on different architectures, all different Windows versions, and it is a really, really great idea. Or you could add it to a list of known DLLs,
and it will also get run privileged. So there are a number of different items that you can use to make this modification. There is one problem with this, however. We are running a Linux image from a Linux and an RD. In order to make registry edits, I'm going to have to use the ntreg library, which if you add a string
and it causes Hive expansion, will give you a warning that this could lead to Hive corruption. Now, if you know about corruption, and you can ask my buddy Blagojevich here, corruption is not something you want to be caught doing. It will land you in jail or sued, which like we've explained,
is not a place you want to be in. So this is probably reliable. It'll probably work just fine, but on the off chance that it does cause some serious problems, it's not something that maybe you want to do as a pentester. So instead, what I did was a combination of binary swapping
and registry editing. So what I did was I swapped a non-essential service, in this case I picked the print spooler, swapped out spoolsv for another executable, and then edited the D-word start key in the registry, which doesn't change the registry size. It's a very simple edit, will not give you angry warnings, and will make sure that this thing
gets run on boot, privileged reliably, in any version of Windows. So now, we are cooking with gas. And one last part of this is the pivoting part. Prior to a couple days ago, the only thing that was available was you still had to install Metasploit
or install TFTP and DHCP servers. What I was able to do was enable this for pivoting. So what this lets you do is attack other systems on the landlord, you have one system, and this will be run in memory via the interpreter. So there's a couple different ways you could do this. One would be writing script using API calls,
or the Railgun is one way of doing that. Lets you make arbitrary Windows API calls from the interpreter. Or you could do it as a compiled extension. Communication over an interpreter happens over packets called TLV packets, have type length value. I used an extension,
so what it was was an embedded DLL, which then pulls up a reflective loader, basically loads itself in memory without touching the hard disk, and then goes ahead and makes the method calls necessary. The reason that I didn't do this via a script or a Railgun, which would have been easier,
was the race condition. So you can do this without a custom extension, wait for a DHCP request. The problem is the interpreter would have to then encrypt that, send that to your controlling system, which could be on the other side of the country, which would generate a response, encrypt that, send it, the interpreter would get it, decrypt it, send out the response. But at that point, you've probably lost the race.
So I rewrote it in C++, it's now compiled and happens all on the interpreter, and the controlling system will just load that all in memory, and it'll be ready to go. So once again, here's our attack recap. We're gonna go ahead and dynamically generate our payload if we want.
The system boots, we could trigger that with awaycon LAN. As for DHCP, DHCP acts, sends it to a TFTP server, which goes ahead, downloads the pixie Linux image, that pulls down the configuration file, kernel initrd loads it, it reads the hard disk,
swaps the binary, edits the registry and makes sure it'll be run, then it'll reboot to the operating system. At this point, the pixie, the attack pixie server will not re-serve that client because it wants it to time out and boot from the hard disk, rather than try to re-infect it continually. So then, when that boots, the swap DXE will be running inside the system, it'll spawn a real payload,
and then clean up after itself. So, let's see how this works. So, what I'm gonna do is I'm just gonna start with Metasploit. I started a handler, in this case on the foreign LAN, I have a Windows 7 system, I left a thumb drive lying around with a shortcut in it.
Shortcuts can run whatever command you want. This particular one will run a VBScript download eval, which will drop a Metasploit binary, and in comes our interpreter shell. So, I now have a shell running in the interpreter, as you can see, I'm alive here on the system,
from the foreign network. What I'm gonna do is I'm gonna run the pixie sploit extension. It's going to load up the extension, load up the four files necessary to serve, then it's gonna issue the commands to start the TFTP and DHCP servers. And we can go ahead and see this in that stat, make sure, so you can see they're running on this system.
We can set advanced options for which IP to serve back, file names, stuff like that, but we don't really need to. At this point, we have our target system, which is a server, Ubuntu server, which has desktop load because it's nice. As you can see, there are only a couple of counts there. It's going to reboot.
It's on the same LAN as the Windows 7 server. It's going to pull off the pixie sploit attack, real fast, and that's gonna give a short message and reboot. That was the dropped attack, so if you blinked for those two seconds, very easy to miss. Now it's going to reboot.
Again, request a pixie server, which is not going to be served, so it'll have to fall back boot to the hard disk. And at this point, we wait for Ubuntu to load. At least we're not waiting for Windows to load. And in a few minutes here,
that will start up. So we could do this over SSH, but just for the good. What we're gonna do is we're gonna put in metasploit. If you remember, there was no username metasploit. We're gonna put in a password of metasploit, and sure enough, we are going to log in. Open up terminal, and sure enough,
that's a pound sign. We are running as root, so we added a new UID0 user, and we have now taken full root control of our fully patched Ubuntu system.
So at this point, there's probably some of you who are sysads or working on the other side of the fence, and you're thinking, great, just great. Look what you did to me. But don't worry yet, because there is plenty of advice out there,
lots of people willing to help. I'm sure there's lots of people at Symantec who are very intelligent. Whoever wrote this article, maybe not one of them. So there's lots of bad advice out there on how to secure PXE. So some of the suggestions which are put forth in the mitigating risks of PXE
are IP reservations, which is a change on the server side. To be honest, most of these are just changes on the server side. If you remember our typical attack scenario, I'm beating your server, so it really doesn't matter what your server's configuration settings are. Any change on the server side
is not gonna make a difference. IP reservations, what that does is that makes sure specific machines are always given specific IP addresses. This probably won't help at all. NAC is another option. Well, NAC will probably prevent you from accidentally plugging in something that you didn't want to,
but I really haven't seen that as a big difficulty to a pentester who's got physical access to your switch to plug into. From the remote attack scenario, where I have a shell running on one of your existing systems, this doesn't do anything. So NAC is also probably unlikely
to get you to any success here. PXE force mode is another curious suggestion. This is a change on the server as well. Assign specific clients to specific PXE servers. Won't do anything against our attack. BIOS passwords, again, won't do anything to our attack. That would only affect someone
who's trying to use PXE to compromise a system they have physical access to. They're trying to manually enable PXE to boot from. I'm curious as to what attack model has somebody who has a computer in their possession and thinks,
wow, I'm going to take an ethernet cable, plug it in the back, take my computer, set up a DHCP and TFTP server, configure those to serve PXE, and use that to compromise the system, which I'm right here, except, oh no, there's a BIOS password. I'm hosed. So,
anyway, those are advice there. So that's one way to fail. Now, you can fail less by at least having something available out there to detect rogue DHCP servers. So you could have software monitoring scanning for them or listening for duplicate replies to
requests which are sent out there. There is a possibility someone could use art poisoning to pull off this attack. That would be difficult because you can't art poison them beforehand. You'd have to do it right as they were booting. That is something, another thing that you could check for on the detection side. And unregistered clients,
if somebody was using the plug-in to the switch style attack, that's one thing. So at least, hopefully you have some mechanism of detecting anomalies on your network like this. A good idea would be with firewalls or, for example, access control lists on your Cisco
switch to only allow DHCP traffic to and from your server. So not allowing DHCP servers somewhere else. That will be a very good idea for protecting this. Now if you do it based on IP you might have to watch for art poisoning, but you'll be in a
pretty good shape. So that's a good idea. A very good idea would be VLAN isolation. If you can go ahead and isolate all your systems or as many as possible on individual VLANs, so one system can't go ahead and pull off you know, this isn't the only layer two attack. Of course there's art poison routing and all the other kind of stuff that could be done.
So VLAN isolation would also stop this attack. Then you'd forward DHCP traffic somewhere else. A very good idea and part of the spec that was actually made for security, if I can talk today,
was the boot integrity services. So this is an extension to PXE which only runs signed code. So what you'll have to do is you'll have to run around to all of your motherboards and put in a certificate into their boot integrity services and then you can use PXE and nobody else will be able to
will be able to have their network bootstrap program executed unless they have signed it with your private key. So that is a very good and effective way. The problem is it's not necessarily available in a lot of firmware and it's a lot of work to run around and go ahead and pull this out. But if you can pull that off that is a
probably the best idea to have PXE running. And the overall best idea goes to turn it off. And with that we might
have a couple minutes for questions but in a second I will let the next speaker start getting set up. If you want to come to the Q&A room for track number one I will be over there for the next probably hour until people stop asking questions. So you can go ahead and
find me there.