Network Nightmare: Ruling the nightlife between shutdown and boot with pxesploit
Weeks, Matt (scriptjunkie)
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.
 So anyway, welcome to Network Nightmare. Um, ruling the nightlife between Shutdown and Boot with Pixysploit. I want to take a few minutes, tell you a little bit about myself because most of you probably haven't heard any of my, uh, talks, the other one that I gave once. Um, or, um, might not be familiar with me. I've done a lot of development with the Metasploit framework. Um, I wrote the new GUI. Um, I wrote some, a bunch of different exploits payloads, um, post exploitation features, stuff like that. I also go by ScriptJunkie, so if you see tools or something like that, uh, that's probably me. Um, I do have a Twitter which I don't use a whole lot, but you know, there's, there's a lot of peer pressure. I might start using that one more. And, um, you can find my website at ScriptJunkie.us. I run a blog, try to keep that, um, dealing with security research, stuff like that. And, um, 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. Um, you got somebody to go click okay 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. Um, they may be different operating systems. They may be, um, harder. Currently, you may do a lot with, uh, abusing legitimate credentials. So, maybe you've gotten credentials from whatever keyloggers or maybe you could escalate privileges and dump hashes. Um, 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 I'm going to, it's going to come down to, I've got to exploit some service on the other system. But that can be really tough. Um, you might be able to pull off a web service exploitation, but, um, you might have to do, you know, real man's hacking and go ahead and start fuzzing, do, or do static analysis to try to identify vulnerabilities in some demon that, you know, they have running and, um, try to come up with an exploit for those. And then you're still stuck because they may have exploit mitigation technologies like that, but 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, uh, session and you're still running as some limited network service and you still have to escalate privileges. So, um, 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, uh, this talk is really for the lazy hackers since I know you guys out there are, 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, um, you know, I'm going to walk up to the system, unplug the hard drive, plug it in my external reader, go read whatever data I want off or drop whatever I want under the disk and it's going to be simple as pie. Um, that's kind of like a very, another variant would be the evil maid attack. If you're not familiar with the evil maid attack, this is basically how it works. Um, I know a lot of you probably have laptops that you left in your hotel room. I actually paid the hotel maid 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. All right, the other, the other type of offline attack would be, um, you could, uh, from the crypto world, they'd say this would be a rubber hose crypt analysis and XKCD has illustrated that beautifully for us here. Um, you go ahead and get credentials via brute force of another kind. So, so there's, 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 know, 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, um, that's not going to work, work out. Also, you're very likely to get caught. And since you're actually there, um, 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. Um, because jail is not a fun place. It's a place with bars, not a charute. It's, it's very bad. You don't want to be stuck there. Having said that, uh, physical access attacks are still common, not the rubber hose crypt analysis 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. But that brings us to, uh, the focal point of this talk, which is the, uh, pre-boot execution environment, which is going to provide us with a way of going ahead and taking over lots of other systems on, on a land that we have access to. Um, couple, couple of things. This is not a, uh, new vulnerability. This is a protocol insecurity and it has been around forever. Um, what I'm presenting here is really, uh, new way of exploiting that. I've not seen a lot of security talk on the subject. Um, so let me tell you a little bit about PXE. Intel and, uh, SystemSoft introduced this a long time ago. Um, it's a protocol. They produce firmware, which is loaded into most BIOS's to boot from, uh, the network interface card if you have network booting enabled. And since this runs from the BIOS, um, it will provide you with full system control. You can go ahead and, um, run code straight on the processor, access a hard drive, access a hardware, do whatever else you want. Totally bypasses anything on the hard drive, um, if you're booting from the network since the hard drive has never touched, you know, 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, uh, really find out a lot about this system. You can just use, uh, the PXE specification itself with, which gives you enough to work with. Um, and best of all, it works over the network. So you do not have to be physically at this system to, to run this attack. So, uh, put it, bring it down to, uh, layman's terms, how it works is you turn off your computer, you know, whatever you do, I know a lot of you have, have a lot of attachment to your computer, so you tuck it in at night and, you know, sing it a lullaby, whatever you do in it. It goes down and then, uh, before, before the operating system boots, when, when that boots up, it notices something, something's a little bit different, some things, a little bit wrong. You might have something that you, uh, didn't really expect there. So, uh, you, you didn't really want this to happen to you. So, makes a good attack though. So the question is, uh, alright, this sounds like a, a, a cool idea. How, how likely am I to see this? And from what I've seen, I, I'm not aware of any widespread, um, 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, um, in this case, uh, what, 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, um, the PXE, 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, um, it's just left on. And like I said, I've seen that. I've also seen it, um, occasionally enabled when admins, they'll go around, enable this and then use it to, let's say, push out an image and, um, then, then turn it off. Or I've seen it just left off all the time. So, it, 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 is admin reasons for why this would be enabled in an environment would be, um, image deployment would be number one. Um, it's, this is where I've seen it most commonly used, um, just to go ahead and push out images. Um, in a similar vein, this could also be used for system restoration. You know, 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, what's that? I don't know. All right, so how does PXE work? Um, it follows, um, 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, um, on port 67, it's going to have an additional field and 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's some PXE specific options saying, yes, um, I've got it. Um, I have a PXE server for you to boot from. Um, and normally it will include a server IP and a file name. So, um, the client will not have to go ahead and do this part, um, although it can make another request to get the file name. And then what happens is it makes a TFTP download, um, from the TFTP server specified, which, uh, with the file name that was specified, downloads that, um, and goes ahead and runs it. That will be the network bootstrap program. It will be, um, loaded up at address 0x7C00 and executed in real mode. So this gives us a couple difficulties. You might be thinking, awesome, I'll just plug my shell code in and let it fire, um, but you'll, you'll run into some problems. First of all, it's passive. So 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 WacomLand packet and make it boot or use a Denial of Service exploit and make it reboot, something like that. So that's not a big issue, but, uh, there might be some waiting involved. Um, the, the main big issue or, or one of the, one of the big issues you're going to have is you're going to have to beat the real DHCP server. So when it sends out its request, you're going to have to send out your request, um, and, and beat it. Now, for some reason DHCP server is 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. So 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, uh, 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. And then you'll be executing code. And this is the biggest difficulty hands down. You're going to be executing code basically on the bare metal in real mode. Um, now, you know, some of you, it's probably, probably like a third of you are thinking, I don't know what real mode is, but it sounds terrible and you're right. And, and the other, the other majority of you or, or most of the rest of you are thinking, I know what real mode is and that sounds terrible and you're right. And so, so 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 heckers. So we'll, we'll get your head examined later. And, and even if you do want to code up one of these, um, the, 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, 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, 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, um, there are, there are those tools and then there's also pixie linux. So first of all, imaging systems. Now, imaging systems, you will need these 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, you know, system and go ahead and pull anything useful off of it, um, if you're trying to, uh, 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, uh, with pixie linux, which is really an awesome tool. Now pixie linux is a linux bootloader kind of like iso linux or sys linux to budoff, a, cd or hard drive. And what it will do for us is it will read in a configuration file. Uh, 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, and, and an id rd, which is an initial RAM disk, um, which will be basically an initial file system in memory. And go ahead and execute whatever program specified there and, um, so, so that, that is convenient. Now, having said that, although it is nice, it does entail some difficulties. So like I said, we're once again, we're going to have to install all these servers, configure DHCP to forward this to us. Um, and this is, this is difficult to deploy. Most likely we're going to be in the case, um, where we're maybe not sitting with physical access to the LAN and maybe we've compromised one system there. This, uh, is difficult in and of itself to deploy remotely. Also, uh, the PXE bootable systems that, um, 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. Um, however, you can go ahead and, uh, use this for online control. So what online control is, is we're going to take a PXE bootable system, um, there are different Linux live CDs which can be PXE booted, um, DSL, Tiny Core and Nopix are one of those. DSL and Tiny Core, um, are really awesome because there are some of the only Linux distributions I know of that can fit entirely within an NNRD. Um, so you won't need anything other than PXE Linux to boot those. Nopix, um, can boot and then connect back via NFS. Um, that will entail some difficulties, uh, which I'll talk about later, but I just stuck with, uh, Tiny Core 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, um, set up some scripts there so that when you boot it via PXE, the scripts will all to run, connect back and you'll get a shell. So, let's try this out. Go ahead and start this. All right, so in this case, uh, what I'm doing is I'm starting with a backtrack image and a Tiny Core 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, um, to serve your PXE files from, this is going to be your TFTP server folder and that's going to have your PXE Linux kernel in it RD and configuration file in it. And then you're going to create a folder in it RD, which you're going to extract the in it RD into, add your scripts, package it back up and it'll be ready to go. So first thing we do is extract the ISO. Um, I'm making this video available so if you want you can see all the steps necessary to go ahead and do this yourself. Um, as you see in the ISO, all we have is ISO Linux, which is a bootloader BZ image, which is a kernel and Tiny Core.GZ, which is the in it RD. And we're going to take the kernel and in it RD, drop it into our PXE folder. And then what we're going to do is we're going to use the Metasploit, PXEploit 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 set up DHCP and TFTP server. And in this case, update one is PXE Linux. Update two is a configuration file. Update three will be the kernel and update four will be the in it RD. So all we have to do is paste those files in here, rename our files to match the Metasploit names of update four and update three. And then we'll just tell Metasploit to use our images instead of the PXEploit attack images that it has with it. So at this point, we have Tiny Core set up to boot from PXE Linux, 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 GZIPP 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 netcat. And the IP of the system, the backtrack system that we're running off of is 101, and so it will 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 RAM disk. We're going to pack it back up. We'll use find to send a list of files to CPIO, which we'll go ahead and compress the, or package up the initrd, gzip it, and send it back over our file. Now, 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 pixysploit 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 root so that it serves up our files and then that will 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 wakeonlamp packet now and get it to boot. So it boots. Searches for a PXC server. That goes ahead and boots. I'm going to QPAC command to be executed when I get a shell back. It loads the kernel. It loads the NNRD. And when that happens in just a second, the system will start booting. It starts detecting the hardware. It will be a few seconds until it is able to access the network card. As you can see, Tiny Core 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, just Mac of 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 car 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, a NITRD that we're sending over to the client. So 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. So while you can disable the X server and make the screen blank or, you know, show whatever you want to show, the fact is the system is not booting and eventually they're going to get tired and they're going to push the power button and you're going to lose your shell and you're going to be stuck. Also, with visual indications, in this case, you know, a tiny course screen came up and they're going to know something's bad and that's when they go ahead and call the security guys and we fail. So there's another way. That would be with offline code injection. And the fact is we might as well go ahead and code it up because really we're going to do it anyway. Without offline code injection that is dropping our code to be run on boots that we can run as admin or root inside the system as opposed to root outside the system. We're going to need to do that because say we have to, you know, we'll want to listen for key logs, we're going to have to watch somebody log into something, maybe take a domain admins hash or something like that. There's all kinds of stuff that we're going to want to do that we can't do from outside the system. We'll want to be running inside. So 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. So that's with boot kits, 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. Now, at this point, maybe you're thinking, oh, but I have BitLocker, TrueCrip, whatever, you can't get me and there, you could use boot kick 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, boot kits, there's a lot of different boot kits which are available. PXE is kind of an ideal way to deliver boot kits because even if you can't read write certain hardest sectors from within, let's say, Vista 764, with a boot kit, you don't have any issue with that with PXE. So there's lots of different boot kits which have been released or 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, Stone is another one that was really stepped black a couple years ago, Whistler is one, TDL, also known as Allureon, also known as TDSS, also known as Just Stop Giving It Names. EI Boot Root is one that was deployed, this is kind of the motivation here. They deployed it with a virus they call the PXE 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 boot kit and get yourself boot kit 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, boot kits are very operating system specific and if you don't have the right architecture, the right operating system support, this isn't going to work so it's going to take a lot of effort to try to maintain that. Also, if you're spawning a root kit with this, what happens a lot of times is Microsoft will update Patch Guard, which will then crash your system and that's happened to a lot of the boot kits here. So it takes a lot of work and like I said, we're all lazy heckers so that seems like some difficulty. One illustration for this, the Stone Boot Kit was presented like I said a couple years ago in 2009 with great fanfare that, I don't know if the author is here, but he said he expected this to be the number one boot kit 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 going to work so awesome, awesome projects but not what we're going to 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 the startup folders for various versions of Windows, you can just drop our executable in there and that will go ahead and run when somebody logs in. The issue with that is whoever is 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, you know, 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 mix in to do this, it's implemented, you can use this as an option in PS exec 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 going to run on boot like services, service host, wininit, CSS, LSAS, any of the core processes which you know are going to run on boot and you put your own executable there, move it to.back.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, you know, some DLL or other process 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, you know, 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 principle or spoolsv.exe. Now, these are useful because they're non-critical, so the principle 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 principle or disabled if this is, you know, 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 in my display, you can go ahead and do that with MSF encoder, 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. Or, and the other problem is you might not have Slack space, the X86 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 going to be loaded up, swap it with my own, that will have my shell code in it, that will 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 version so that is still an option. Another problem is with the imports, this DLL is 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 it's 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. The 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 guarantee to 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 in 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 high expansion will give you a warning that this could lead to high 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 have explained is not a place you want to be in. So this is probably reliable. It will probably work just fine. But on the off chance that it does cause some serious problems, it is not something that maybe you want to do as a pen tester. So instead, what I did was a combination of binary swapping and registry editing. So what I did was I swapped an unessential service. In this case, I picked the print spooler, swapped out spool SV for another executable and then edited the D word start key in the registry which doesn't change the registry size. It is 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 it was able to do was enable this for pivoting. So what this lets you do is tackle the systems on a land where you have one system and this will be run in memory via the interpreter. So there's a couple of different ways you can do this. One would be writing script using API calls or the rail gun is one way of doing that. It lets you make arbitrary Windows API calls from the interpreter or you can do it as a compiled extension. Communication over interpreter happens over packets called TLV packets have type length value. I used an extension so what it 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 I didn't do this via a script or a rail gun which would have been easier was the race condition. So you can do this without a custom extension, you know, 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, 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 going to go ahead and dynamically generate our payload if we want. The system boots, we could trigger that with Awake on 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 and NIDRD loads it, it reads the hard disk, swaps the binary, edits the registry and makes sure it will be run, then it will 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 going to do is I'm just going to 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 line around with a shortcut in it, shortcuts can run whatever command you want, this particular one will run a VBScript downloady valve which will drop a Metasploit binary and in comes our MetaSploit shell. So I don't have a shell running in the interpreters, you can see I'm alive here on the system from the foreign network. What I'm going to do is I'm going to run the PixieSploit extension, it's going to load up the extension, load up the four files necessary to serve, then it's going to 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 name, 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 accounts there, it's going to reboot, it's on the same LAN as the Windows 7 server, it's going to pull off the PixieSploit attack real fast and that's going to give a short message and reboot, that was the dropped attack so if you blink for those two seconds it's very easy to miss. Now it's going to reboot, again request a Pixie server which is not going to be served so it will 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 going to do is put in Metasploit, if you remember there was no username Metasploit, we're going to put in a password of Metasploit and sure enough we are going to log in. Open up Terminal, sure enough that's 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 is 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 risk 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 going to make a difference. IP reservations, what that does is that sets, makes sure specific machines are always given specific IP addresses. This probably won't help at all. NACC is another option. Well, NACC 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 pen tester who's got physical access to your switch to plug into. And from the remote attack scenario where I have a shell running on one of your existing systems, this doesn't do anything. So NACC 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. Assigned specific clients to specific PXE servers won't do anything against our attack. And 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 and 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 hoes. 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. But that is something, you know, another thing that you could check for on the detection side and unregistered clients if somebody was using the plug into 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 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 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 mother boards and put in a certificate into their boot integrity services and then you can use PXE and nobody else 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 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.
 So anyway, welcome to Network Nightmare. Um, ruling the nightlife between Shutdown and  Boot with Pixysploit. I want to take a few minutes, tell you a little bit about myself  because most of you probably haven't heard any of my, uh, talks, the other one that I  gave once. Um, or, um, might not be familiar with me. I've done a lot of development with  the Metasploit framework. Um, I wrote the new GUI. Um, I wrote some, a bunch of different  exploits payloads, um, post exploitation features, stuff like that. I also go by ScriptJunkie,  so if you see tools or something like that, uh, that's probably me. Um, I do have a Twitter  which I don't use a whole lot, but you know, there's, there's a lot of peer pressure. I  might start using that one more. And, um, you can find my website at ScriptJunkie.us.  I run a blog, try to keep that, um, dealing with security research, stuff like that. And,  um, 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. Um, you got somebody to go click okay  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. Um, they may be different operating systems.  They may be, um, harder. Currently, you may do a lot with, uh, abusing legitimate credentials.  So, maybe you've gotten credentials from whatever keyloggers or maybe you could escalate  privileges and dump hashes. Um, 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 I'm going to, it's going  to come down to, I've got to exploit some service on the other system. But that can be really  tough. Um, you might be able to pull off a web service exploitation, but, um, you might  have to do, you know, real man's hacking and go ahead and start fuzzing, do, or do static  analysis to try to identify vulnerabilities in some demon that, you know, they have running  and, um, try to come up with an exploit for those. And then you're still stuck because  they may have exploit mitigation technologies like that, but 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, uh, session  and you're still running as some limited network service and you still have to escalate privileges.  So, um, 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, uh, this  talk is really for the lazy hackers since I know you guys out there are, 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, um, you know, I'm going to walk up to the system, unplug the hard  drive, plug it in my external reader, go read whatever data I want off or drop whatever I  want under the disk and it's going to be simple as pie. Um, that's kind of like a very, another  variant would be the evil maid attack. If you're not familiar with the evil maid attack,  this is basically how it works. Um, I know a lot of you probably have laptops that you  left in your hotel room. I actually paid the hotel maid 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. All right, the other,  the other type of offline attack would be, um, you could, uh, from the crypto world, they'd  say this would be a rubber hose crypt analysis and XKCD has illustrated that beautifully for  us here. Um, you go ahead and get credentials via brute force of another kind. So, so there's,  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  know, 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, um, that's not going to work,  work out. Also, you're very likely to get caught. And since you're actually there, um, 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. Um, because jail is not a fun place. It's a place  with bars, not a charute. It's, it's very bad. You don't want to be stuck there. Having  said that, uh, physical access attacks are still common, not the rubber hose crypt analysis  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. But that brings  us to, uh, the focal point of this talk, which is the, uh, pre-boot execution environment,  which is going to provide us with a way of going ahead and taking over lots of other  systems on, on a land that we have access to. Um, couple, couple of things. This is  not a, uh, new vulnerability. This is a protocol insecurity and it has been around forever.  Um, what I'm presenting here is really, uh, new way of exploiting that. I've not seen  a lot of security talk on the subject. Um, so let me tell you a little bit about PXE.  Intel and, uh, SystemSoft introduced this a long time ago. Um, it's a protocol. They  produce firmware, which is loaded into most BIOS's to boot from, uh, the network interface  card if you have network booting enabled. And since this runs from the BIOS, um, it  will provide you with full system control. You can go ahead and, um, run code straight  on the processor, access a hard drive, access a hardware, do whatever else you want. Totally  bypasses anything on the hard drive, um, if you're booting from the network since the  hard drive has never touched, you know, 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, uh, really find out a lot about this system. You can  just use, uh, the PXE specification itself with, which gives you enough to work with.  Um, and best of all, it works over the network. So you do not have to be physically at this  system to, to run this attack. So, uh, put it, bring it down to, uh, layman's terms,  how it works is you turn off your computer, you know, whatever you do, I know a lot of  you have, have a lot of attachment to your computer, so you tuck it in at night and,  you know, sing it a lullaby, whatever you do in it. It goes down and then, uh, before,  before the operating system boots, when, when that boots up, it notices something, something's  a little bit different, some things, a little bit wrong. You might have something that you,  uh, didn't really expect there. So, uh, you, you didn't really want this to happen to you.  So, makes a good attack though. So the question is, uh, alright, this sounds like a, a, a  cool idea. How, how likely am I to see this? And from what I've seen, I, I'm not aware  of any widespread, um, 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, um, in this case, uh, what, 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, um, the PXE, 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, um, it's just left  on. And like I said, I've seen that. I've also seen it, um, occasionally enabled when  admins, they'll go around, enable this and then use it to, let's say, push out an image  and, um, then, then turn it off. Or I've seen it just left off all the time. So, it, 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 is admin reasons for why this would be enabled in an  environment would be, um, image deployment would be number one. Um, it's, this is where  I've seen it most commonly used, um, just to go ahead and push out images. Um, in a  similar vein, this could also be used for system restoration. You know, 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, what's that? I don't know. All right, so how  does PXE work? Um, it follows, um, 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, um, on port 67,  it's going to have an additional field and 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's some PXE specific options saying, yes, um, I've got it. Um, I have a PXE server  for you to boot from. Um, and normally it will include a server IP and a file name.  So, um, the client will not have to go ahead and do this part, um, although it can make  another request to get the file name. And then what happens is it makes a TFTP download,  um, from the TFTP server specified, which, uh, with the file name that was specified,  downloads that, um, and goes ahead and runs it. That will be the network bootstrap program.  It will be, um, loaded up at address 0x7C00 and executed in real mode. So this gives us a  couple difficulties. You might be thinking, awesome, I'll just plug my shell code in and  let it fire, um, but you'll, you'll run into some problems. First of all, it's passive.  So 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 WacomLand packet and make it boot or use a Denial of Service  exploit and make it reboot, something like that. So that's not a big issue, but, uh,  there might be some waiting involved. Um, the, the main big issue or, or one of the,  one of the big issues you're going to have is you're going to have to beat the real DHCP  server. So when it sends out its request, you're going to have to send out your request,  um, and, and beat it. Now, for some reason DHCP server is 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. So 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, uh, 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. And  then you'll be executing code. And this is the biggest difficulty hands down. You're  going to be executing code basically on the bare metal in real mode. Um, now, you know,  some of you, it's probably, probably like a third of you are thinking, I don't know  what real mode is, but it sounds terrible and you're right. And, and the other, the  other majority of you or, or most of the rest of you are thinking, I know what real mode  is and that sounds terrible and you're right. And so, so 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 heckers. So we'll, we'll get your head examined later. And, and even if you  do want to code up one of these, um, the, 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, 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, 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, um, there are, there are those tools and then there's also pixie linux. So first of  all, imaging systems. Now, imaging systems, you will need these 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, you know, system and go ahead and pull anything useful off of it, um, if you're trying  to, uh, 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, uh, with pixie linux, which is really an awesome tool. Now pixie linux  is a linux bootloader kind of like iso linux or sys linux to budoff, a, cd or hard drive.  And what it will do for us is it will read in a configuration file. Uh, 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, and, and an id rd, which is an initial RAM disk, um, which will be basically an initial  file system in memory. And go ahead and execute whatever program specified there and, um,  so, so that, that is convenient. Now, having said that, although it is nice, it does entail  some difficulties. So like I said, we're once again, we're going to have to install all these  servers, configure DHCP to forward this to us. Um, and this is, this is difficult to  deploy. Most likely we're going to be in the case, um, where we're maybe not sitting with  physical access to the LAN and maybe we've compromised one system there. This, uh, is  difficult in and of itself to deploy remotely. Also, uh, the PXE bootable systems that, um,  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. Um, however, you can go ahead and, uh, use  this for online control. So what online control is, is we're going to take a PXE bootable  system, um, there are different Linux live CDs which can be PXE booted, um, DSL, Tiny  Core and Nopix are one of those. DSL and Tiny Core, um, are really awesome because there  are some of the only Linux distributions I know of that can fit entirely within an NNRD.  Um, so you won't need anything other than PXE Linux to boot those. Nopix, um, can boot  and then connect back via NFS. Um, that will entail some difficulties, uh, which I'll talk  about later, but I just stuck with, uh, Tiny Core 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, um, set up some scripts there so that when you boot it via PXE, the scripts will  all to run, connect back and you'll get a shell. So, let's try this out. Go ahead and  start this. All right, so in this case, uh, what I'm doing is I'm starting with a backtrack  image and a Tiny Core 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, um, to serve your PXE files from,  this is going to be your TFTP server folder and that's going to have your PXE Linux kernel  in it RD and configuration file in it. And then you're going to create a folder in it  RD, which you're going to extract the in it RD into, add your scripts, package it back  up and it'll be ready to go. So first thing we do is extract the ISO. Um, I'm making this  video available so if you want you can see all the steps necessary to go ahead and do  this yourself. Um, as you see in the ISO, all we have is ISO Linux, which is a bootloader  BZ image, which is a kernel and Tiny Core.GZ, which is the in it RD. And we're going to  take the kernel and in it RD, drop it into our PXE folder. And then what we're going  to do is we're going to use the Metasploit, PXEploit 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 set up DHCP and TFTP server. And in this case, update one is PXE Linux. Update  two is a configuration file. Update three will be the kernel and update four will be  the in it RD. So all we have to do is paste those files in here, rename our files to match  the Metasploit names of update four and update three. And then we'll just tell Metasploit  to use our images instead of the PXEploit attack images that it has with it. So at this  point, we have Tiny Core set up to boot from PXE Linux, 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 GZIPP 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 netcat. And the IP of the system, the backtrack system that  we're running off of is 101, and so it will 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 RAM disk. We're going to pack  it back up. We'll use find to send a list of files to CPIO, which we'll go ahead and  compress the, or package up the initrd, gzip it, and send it back over our file. Now,  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 pixysploit 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 root so that it serves up our files and then that will 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 wakeonlamp packet now and get it to boot. So it boots.  Searches for a PXC server. That goes ahead and boots. I'm going to QPAC command to be  executed when I get a shell back. It loads the kernel. It loads the NNRD. And when that  happens in just a second, the system will start booting. It starts detecting the hardware.  It will be a few seconds until it is able to access the network card. As you can see,  Tiny Core 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, just Mac  of 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 car 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, a NITRD that we're sending over to the client. So 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. So while you can disable the X server and make the screen blank or, you know, show  whatever you want to show, the fact is the system is not booting and eventually they're  going to get tired and they're going to push the power button and you're going to lose  your shell and you're going to be stuck. Also, with visual indications, in this case, you  know, a tiny course screen came up and they're going to know something's bad and that's when  they go ahead and call the security guys and we fail. So there's another way. That would  be with offline code injection. And the fact is we might as well go ahead and code it up  because really we're going to do it anyway. Without offline code injection that is dropping  our code to be run on boots that we can run as admin or root inside the system as opposed  to root outside the system. We're going to need to do that because say we have to, you  know, we'll want to listen for key logs, we're going to have to watch somebody log into something,  maybe take a domain admins hash or something like that. There's all kinds of stuff that  we're going to want to do that we can't do from outside the system. We'll want to be  running inside. So 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. So that's with boot kits, 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. Now, at this point, maybe you're thinking, oh, but I have  BitLocker, TrueCrip, whatever, you can't get me and there, you could use boot kick  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, boot  kits, there's a lot of different boot kits which are available. PXE is kind of an ideal  way to deliver boot kits because even if you can't read write certain hardest sectors  from within, let's say, Vista 764, with a boot kit, you don't have any issue with that  with PXE. So there's lots of different boot kits which have been released or 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, Stone is another one that was really  stepped black a couple years ago, Whistler is one, TDL, also known as Allureon, also  known as TDSS, also known as Just Stop Giving It Names. EI Boot Root is one that was deployed,  this is kind of the motivation here. They deployed it with a virus they call the PXE  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 boot kit and get yourself boot kit 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, boot kits  are very operating system specific and if you don't have the right architecture, the  right operating system support, this isn't going to work so it's going to take a lot  of effort to try to maintain that. Also, if you're spawning a root kit with this, what  happens a lot of times is Microsoft will update Patch Guard, which will then crash your system  and that's happened to a lot of the boot kits here. So it takes a lot of work and like I  said, we're all lazy heckers so that seems like some difficulty. One illustration for  this, the Stone Boot Kit was presented like I said a couple years ago in 2009 with great  fanfare that, I don't know if the author is here, but he said he expected this to be the  number one boot kit 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 going to  work so awesome, awesome projects but not what we're going to 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 the startup folders for various versions of Windows, you can just  drop our executable in there and that will go ahead and run when somebody logs in. The  issue with that is whoever is 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, you know, 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 mix in to do this, it's implemented, you can use this as  an option in PS exec 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 going to run on boot like services, service host,  wininit, CSS, LSAS, any of the core processes which you know are going to run on boot and  you put your own executable there, move it to.back.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, you know,  some DLL or other process 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, you know, 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 principle or spoolsv.exe. Now, these are useful  because they're non-critical, so the principle 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 principle or disabled if this is, you know, 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 in my display,  you can go ahead and do that with MSF encoder, 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. Or, and the other problem is  you might not have Slack space, the X86 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 going to be loaded up, swap it with my own, that will have my shell code in it, that will  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 version so that  is still an option. Another problem is with the imports, this DLL is 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 it's 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. The 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 guarantee to 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 in 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 high expansion will give you a warning that this could lead to  high 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 have explained is not a place you want to be in. So this is probably  reliable. It will probably work just fine. But on the off chance that it does cause some  serious problems, it is not something that maybe you want to do as a pen tester. So instead,  what I did was a combination of binary swapping and registry editing. So what I did was I  swapped an unessential service. In this case, I picked the print spooler, swapped out spool  SV for another executable and then edited the D word start key in the registry which  doesn't change the registry size. It is 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 it was able to do was enable  this for pivoting. So what this lets you do is tackle the systems on a land where you  have one system and this will be run in memory via the interpreter. So there's a couple of  different ways you can do this. One would be writing script using API calls or the rail  gun is one way of doing that. It lets you make arbitrary Windows API calls from the  interpreter or you can do it as a compiled extension. Communication over interpreter  happens over packets called TLV packets have type length value. I used an extension so  what it 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 I didn't do this via a script or a rail gun which would have been  easier was the race condition. So you can do this without a custom extension, you know,  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, 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 going to go ahead and dynamically generate our payload if we want. The system  boots, we could trigger that with Awake on 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 and NIDRD loads it, it reads the hard disk, swaps the binary, edits the  registry and makes sure it will be run, then it will 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 going  to do is I'm just going to 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 line around with a shortcut in it, shortcuts  can run whatever command you want, this particular one will run a VBScript downloady valve which  will drop a Metasploit binary and in comes our MetaSploit shell. So I don't have a shell  running in the interpreters, you can see I'm alive here on the system from the foreign  network. What I'm going to do is I'm going to run the PixieSploit extension, it's going  to load up the extension, load up the four files necessary to serve, then it's going  to 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 name, 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 accounts there,  it's going to reboot, it's on the same LAN as the Windows 7 server, it's going to pull  off the PixieSploit attack real fast and that's going to give a short message and reboot, that  was the dropped attack so if you blink for those two seconds it's very easy to miss.  Now it's going to reboot, again request a Pixie server which is not going to be served  so it will 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 going to do  is put in Metasploit, if you remember there was no username Metasploit, we're going to  put in a password of Metasploit and sure enough we are going to log in. Open up Terminal,  sure enough that's 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 is 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 risk 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 going to make a difference. IP reservations, what  that does is that sets, makes sure specific machines are always given specific IP addresses.  This probably won't help at all. NACC is another option. Well, NACC 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 pen tester who's got physical access to your switch to plug  into. And from the remote attack scenario where I have a shell running on one of your  existing systems, this doesn't do anything. So NACC 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. Assigned specific clients to specific PXE servers won't do anything  against our attack. And 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 and 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 hoes. 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.  But that is something, you know, another thing that you could check for on the detection  side and unregistered clients if somebody was using the plug into 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 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 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 mother  boards and put in a certificate into their boot integrity services and then you can use  PXE and nobody else 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 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.
DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_0_215.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_216_1631.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_1632_5471.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_5472_5555.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_5556_6203.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_6204_7547.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_7548_7931.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_7932_9959.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_9960_10907.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_10908_12851.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_12852_14111.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_14112_18923.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_18924_19859.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_19860_20447.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_20448_21587.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_21588_24803.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_24804_24875.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_24876_24947.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_24948_25007.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_25008_32699.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_32700_32819.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_32820_33563.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_33564_33863.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_33864_33923.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_33924_33971.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_33972_36527.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_36528_37871.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_37872_38183.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_38184_38723.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_38724_40823.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_40824_41387.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_41388_42251.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_42252_43043.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_43044_47747.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_47748_51323.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_51324_52223.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_52224_53399.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_53400_55235.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_55236_55283.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_55284_58115.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_58116_58235.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_58236_58355.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_58356_58727.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_58728_58775.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_58776_59291.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_59292_59543.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_59544_59651.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_59652_59843.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_59844_59999.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_60000_60563.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_60564_61091.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_61092_61559.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_61560_61667.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_61668_61883.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_61884_62003.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_62004_62459.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_62460_66107.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_66108_66167.png DEF_CON_19_-_Matt__scriptjunkie__Weeks_-_Network_Nightmare__Ruling_The_Nightlife_tKh4l0jU0U8_1_66168_71169.png
So anyway, welcome to Network Nightmare. Um, ruling the nightlife between Shutdown and Boot with Pixysploit. I want to take a few minutes, tell you a little bit about myself because most of you probably haven't heard any of my, uh, talks, the other one that I gave once. Um, or, um, might not be familiar with me. I've done a lot of development with the Metasploit framework. Um, I wrote the new GUI. Um, I wrote some, a bunch of different exploits payloads, um, post exploitation features, stuff like that. I also go by ScriptJunkie, so if you see tools or something like that, uh, that's probably me. Um, I do have a Twitter which I don't use a whole lot, but you know, there's, there's a lot of peer pressure. I might start using that one more. And, um, you can find my website at ScriptJunkie.us. I run a blog, try to keep that, um, dealing with security research, stuff like that. And, um, 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. Um, you got somebody to go click okay 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. Um, they may be different operating systems. They may be, um, harder. Currently, you may do a lot with, uh, abusing legitimate credentials. So, maybe you've gotten credentials from whatever keyloggers or maybe you could escalate privileges and dump hashes. Um, 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 I'm going to, it's going to come down to, I've got to exploit some service on the other system. But that can be really tough. Um, you might be able to pull off a web service exploitation, but, um, you might have to do, you know, real man's hacking and go ahead and start fuzzing, do, or do static analysis to try to identify vulnerabilities in some demon that, you know, they have running and, um, try to come up with an exploit for those. And then you're still stuck because they may have exploit mitigation technologies like that, but 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, uh, session and you're still running as some limited network service and you still have to escalate privileges. So, um, 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, uh, this talk is really for the lazy hackers since I know you guys out there are, 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, um, you know, I'm going to walk up to the system, unplug the hard drive, plug it in my external reader, go read whatever data I want off or drop whatever I want under the disk and it's going to be simple as pie. Um, that's kind of like a very, another variant would be the evil maid attack. If you're not familiar with the evil maid attack, this is basically how it works. Um, I know a lot of you probably have laptops that you left in your hotel room. I actually paid the hotel maid 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. All right, the other, the other type of offline attack would be, um, you could, uh, from the crypto world, they'd say this would be a rubber hose crypt analysis and XKCD has illustrated that beautifully for us here. Um, you go ahead and get credentials via brute force of another kind. So, so there's, 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 know, 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, um, that's not going to work, work out. Also, you're very likely to get caught. And since you're actually there, um, 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. Um, because jail is not a fun place. It's a place with bars, not a charute. It's, it's very bad. You don't want to be stuck there. Having said that, uh, physical access attacks are still common, not the rubber hose crypt analysis 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. But that brings us to, uh, the focal point of this talk, which is the, uh, pre-boot execution environment, which is going to provide us with a way of going ahead and taking over lots of other systems on, on a land that we have access to. Um, couple, couple of things. This is not a, uh, new vulnerability. This is a protocol insecurity and it has been around forever. Um, what I'm presenting here is really, uh, new way of exploiting that. I've not seen a lot of security talk on the subject. Um, so let me tell you a little bit about PXE. Intel and, uh, SystemSoft introduced this a long time ago. Um, it's a protocol. They produce firmware, which is loaded into most BIOS's to boot from, uh, the network interface card if you have network booting enabled. And since this runs from the BIOS, um, it will provide you with full system control. You can go ahead and, um, run code straight on the processor, access a hard drive, access a hardware, do whatever else you want. Totally bypasses anything on the hard drive, um, if you're booting from the network since the hard drive has never touched, you know, 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, uh, really find out a lot about this system. You can just use, uh, the PXE specification itself with, which gives you enough to work with. Um, and best of all, it works over the network. So you do not have to be physically at this system to, to run this attack. So, uh, put it, bring it down to, uh, layman's terms, how it works is you turn off your computer, you know, whatever you do, I know a lot of you have, have a lot of attachment to your computer, so you tuck it in at night and, you know, sing it a lullaby, whatever you do in it. It goes down and then, uh, before, before the operating system boots, when, when that boots up, it notices something, something's a little bit different, some things, a little bit wrong. You might have something that you, uh, didn't really expect there. So, uh, you, you didn't really want this to happen to you. So, makes a good attack though. So the question is, uh, alright, this sounds like a, a, a cool idea. How, how likely am I to see this? And from what I've seen, I, I'm not aware of any widespread, um, 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, um, in this case, uh, what, 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, um, the PXE, 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, um, it's just left on. And like I said, I've seen that. I've also seen it, um, occasionally enabled when admins, they'll go around, enable this and then use it to, let's say, push out an image and, um, then, then turn it off. Or I've seen it just left off all the time. So, it, 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 is admin reasons for why this would be enabled in an environment would be, um, image deployment would be number one. Um, it's, this is where I've seen it most commonly used, um, just to go ahead and push out images. Um, in a similar vein, this could also be used for system restoration. You know, 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, what's that? I don't know. All right, so how does PXE work? Um, it follows, um, 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, um, on port 67, it's going to have an additional field and 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's some PXE specific options saying, yes, um, I've got it. Um, I have a PXE server for you to boot from. Um, and normally it will include a server IP and a file name. So, um, the client will not have to go ahead and do this part, um, although it can make another request to get the file name. And then what happens is it makes a TFTP download, um, from the TFTP server specified, which, uh, with the file name that was specified, downloads that, um, and goes ahead and runs it. That will be the network bootstrap program. It will be, um, loaded up at address 0x7C00 and executed in real mode. So this gives us a couple difficulties. You might be thinking, awesome, I'll just plug my shell code in and let it fire, um, but you'll, you'll run into some problems. First of all, it's passive. So 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 WacomLand packet and make it boot or use a Denial of Service exploit and make it reboot, something like that. So that's not a big issue, but, uh, there might be some waiting involved. Um, the, the main big issue or, or one of the, one of the big issues you're going to have is you're going to have to beat the real DHCP server. So when it sends out its request, you're going to have to send out your request, um, and, and beat it. Now, for some reason DHCP server is 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. So 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, uh, 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. And then you'll be executing code. And this is the biggest difficulty hands down. You're going to be executing code basically on the bare metal in real mode. Um, now, you know, some of you, it's probably, probably like a third of you are thinking, I don't know what real mode is, but it sounds terrible and you're right. And, and the other, the other majority of you or, or most of the rest of you are thinking, I know what real mode is and that sounds terrible and you're right. And so, so 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 heckers. So we'll, we'll get your head examined later. And, and even if you do want to code up one of these, um, the, 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, 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, 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, um, there are, there are those tools and then there's also pixie linux. So first of all, imaging systems. Now, imaging systems, you will need these 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, you know, system and go ahead and pull anything useful off of it, um, if you're trying to, uh, 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, uh, with pixie linux, which is really an awesome tool. Now pixie linux is a linux bootloader kind of like iso linux or sys linux to budoff, a, cd or hard drive. And what it will do for us is it will read in a configuration file. Uh, 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, and, and an id rd, which is an initial RAM disk, um, which will be basically an initial file system in memory. And go ahead and execute whatever program specified there and, um, so, so that, that is convenient. Now, having said that, although it is nice, it does entail some difficulties. So like I said, we're once again, we're going to have to install all these servers, configure DHCP to forward this to us. Um, and this is, this is difficult to deploy. Most likely we're going to be in the case, um, where we're maybe not sitting with physical access to the LAN and maybe we've compromised one system there. This, uh, is difficult in and of itself to deploy remotely. Also, uh, the PXE bootable systems that, um, 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. Um, however, you can go ahead and, uh, use this for online control. So what online control is, is we're going to take a PXE bootable system, um, there are different Linux live CDs which can be PXE booted, um, DSL, Tiny Core and Nopix are one of those. DSL and Tiny Core, um, are really awesome because there are some of the only Linux distributions I know of that can fit entirely within an NNRD. Um, so you won't need anything other than PXE Linux to boot those. Nopix, um, can boot and then connect back via NFS. Um, that will entail some difficulties, uh, which I'll talk about later, but I just stuck with, uh, Tiny Core 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, um, set up some scripts there so that when you boot it via PXE, the scripts will all to run, connect back and you'll get a shell. So, let's try this out. Go ahead and start this. All right, so in this case, uh, what I'm doing is I'm starting with a backtrack image and a Tiny Core 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, um, to serve your PXE files from, this is going to be your TFTP server folder and that's going to have your PXE Linux kernel in it RD and configuration file in it. And then you're going to create a folder in it RD, which you're going to extract the in it RD into, add your scripts, package it back up and it'll be ready to go. So first thing we do is extract the ISO. Um, I'm making this video available so if you want you can see all the steps necessary to go ahead and do this yourself. Um, as you see in the ISO, all we have is ISO Linux, which is a bootloader BZ image, which is a kernel and Tiny Core.GZ, which is the in it RD. And we're going to take the kernel and in it RD, drop it into our PXE folder. And then what we're going to do is we're going to use the Metasploit, PXEploit 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 set up DHCP and TFTP server. And in this case, update one is PXE Linux. Update two is a configuration file. Update three will be the kernel and update four will be the in it RD. So all we have to do is paste those files in here, rename our files to match the Metasploit names of update four and update three. And then we'll just tell Metasploit to use our images instead of the PXEploit attack images that it has with it. So at this point, we have Tiny Core set up to boot from PXE Linux, 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 GZIPP 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 netcat. And the IP of the system, the backtrack system that we're running off of is 101, and so it will 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 RAM disk. We're going to pack it back up. We'll use find to send a list of files to CPIO, which we'll go ahead and compress the, or package up the initrd, gzip it, and send it back over our file. Now, 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 pixysploit 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 root so that it serves up our files and then that will 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 wakeonlamp packet now and get it to boot. So it boots. Searches for a PXC server. That goes ahead and boots. I'm going to QPAC command to be executed when I get a shell back. It loads the kernel. It loads the NNRD. And when that happens in just a second, the system will start booting. It starts detecting the hardware. It will be a few seconds until it is able to access the network card. As you can see, Tiny Core 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, just Mac of 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 car 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, a NITRD that we're sending over to the client. So 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. So while you can disable the X server and make the screen blank or, you know, show whatever you want to show, the fact is the system is not booting and eventually they're going to get tired and they're going to push the power button and you're going to lose your shell and you're going to be stuck. Also, with visual indications, in this case, you know, a tiny course screen came up and they're going to know something's bad and that's when they go ahead and call the security guys and we fail. So there's another way. That would be with offline code injection. And the fact is we might as well go ahead and code it up because really we're going to do it anyway. Without offline code injection that is dropping our code to be run on boots that we can run as admin or root inside the system as opposed to root outside the system. We're going to need to do that because say we have to, you know, we'll want to listen for key logs, we're going to have to watch somebody log into something, maybe take a domain admins hash or something like that. There's all kinds of stuff that we're going to want to do that we can't do from outside the system. We'll want to be running inside. So 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. So that's with boot kits, 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. Now, at this point, maybe you're thinking, oh, but I have BitLocker, TrueCrip, whatever, you can't get me and there, you could use boot kick 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, boot kits, there's a lot of different boot kits which are available. PXE is kind of an ideal way to deliver boot kits because even if you can't read write certain hardest sectors from within, let's say, Vista 764, with a boot kit, you don't have any issue with that with PXE. So there's lots of different boot kits which have been released or 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, Stone is another one that was really stepped black a couple years ago, Whistler is one, TDL, also known as Allureon, also known as TDSS, also known as Just Stop Giving It Names. EI Boot Root is one that was deployed, this is kind of the motivation here. They deployed it with a virus they call the PXE 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 boot kit and get yourself boot kit 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, boot kits are very operating system specific and if you don't have the right architecture, the right operating system support, this isn't going to work so it's going to take a lot of effort to try to maintain that. Also, if you're spawning a root kit with this, what happens a lot of times is Microsoft will update Patch Guard, which will then crash your system and that's happened to a lot of the boot kits here. So it takes a lot of work and like I said, we're all lazy heckers so that seems like some difficulty. One illustration for this, the Stone Boot Kit was presented like I said a couple years ago in 2009 with great fanfare that, I don't know if the author is here, but he said he expected this to be the number one boot kit 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 going to work so awesome, awesome projects but not what we're going to 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 the startup folders for various versions of Windows, you can just drop our executable in there and that will go ahead and run when somebody logs in. The issue with that is whoever is 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, you know, 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 mix in to do this, it's implemented, you can use this as an option in PS exec 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 going to run on boot like services, service host, wininit, CSS, LSAS, any of the core processes which you know are going to run on boot and you put your own executable there, move it to.back.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, you know, some DLL or other process 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, you know, 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 principle or spoolsv.exe. Now, these are useful because they're non-critical, so the principle 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 principle or disabled if this is, you know, 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 in my display, you can go ahead and do that with MSF encoder, 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. Or, and the other problem is you might not have Slack space, the X86 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 going to be loaded up, swap it with my own, that will have my shell code in it, that will 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 version so that is still an option. Another problem is with the imports, this DLL is 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 it's 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. The 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 guarantee to 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 in 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 high expansion will give you a warning that this could lead to high 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 have explained is not a place you want to be in. So this is probably reliable. It will probably work just fine. But on the off chance that it does cause some serious problems, it is not something that maybe you want to do as a pen tester. So instead, what I did was a combination of binary swapping and registry editing. So what I did was I swapped an unessential service. In this case, I picked the print spooler, swapped out spool SV for another executable and then edited the D word start key in the registry which doesn't change the registry size. It is 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 it was able to do was enable this for pivoting. So what this lets you do is tackle the systems on a land where you have one system and this will be run in memory via the interpreter. So there's a couple of different ways you can do this. One would be writing script using API calls or the rail gun is one way of doing that. It lets you make arbitrary Windows API calls from the interpreter or you can do it as a compiled extension. Communication over interpreter happens over packets called TLV packets have type length value. I used an extension so what it 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 I didn't do this via a script or a rail gun which would have been easier was the race condition. So you can do this without a custom extension, you know, 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, 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 going to go ahead and dynamically generate our payload if we want. The system boots, we could trigger that with Awake on 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 and NIDRD loads it, it reads the hard disk, swaps the binary, edits the registry and makes sure it will be run, then it will 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 going to do is I'm just going to 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 line around with a shortcut in it, shortcuts can run whatever command you want, this particular one will run a VBScript downloady valve which will drop a Metasploit binary and in comes our MetaSploit shell. So I don't have a shell running in the interpreters, you can see I'm alive here on the system from the foreign network. What I'm going to do is I'm going to run the PixieSploit extension, it's going to load up the extension, load up the four files necessary to serve, then it's going to 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 name, 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 accounts there, it's going to reboot, it's on the same LAN as the Windows 7 server, it's going to pull off the PixieSploit attack real fast and that's going to give a short message and reboot, that was the dropped attack so if you blink for those two seconds it's very easy to miss. Now it's going to reboot, again request a Pixie server which is not going to be served so it will 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 going to do is put in Metasploit, if you remember there was no username Metasploit, we're going to put in a password of Metasploit and sure enough we are going to log in. Open up Terminal, sure enough that's 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 is 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 risk 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 going to make a difference. IP reservations, what that does is that sets, makes sure specific machines are always given specific IP addresses. This probably won't help at all. NACC is another option. Well, NACC 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 pen tester who's got physical access to your switch to plug into. And from the remote attack scenario where I have a shell running on one of your existing systems, this doesn't do anything. So NACC 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. Assigned specific clients to specific PXE servers won't do anything against our attack. And 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 and 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 hoes. 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. But that is something, you know, another thing that you could check for on the detection side and unregistered clients if somebody was using the plug into 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 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 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 mother boards and put in a certificate into their boot integrity services and then you can use PXE and nobody else 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 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.
lot of development with the Metasploit framework. Um, I wrote the new GUI. Um, I wrote some, a they may be different operating systems. They may will need physical access to the system. And if uh, pre-boot execution environment, which is field and option which specifies this is a PXE runs it. That will be the network bootstrap love writing bootloaders. I'm going to break out instructions and go ahead and own this thing. PXEploit server. In this case, we're not going to and get it to boot. So it boots. Searches for a control. First of all, any operating system. We injection that is dropping our code to be run on techniques, might be able to bypass some of that known as Allureon, also known as TDSS, also known privileges and it's portable, it runs on, you one system and this will be run in memory via the Pixie Linux image, that pulls down the to plug into. And from the remote attack scenario number one I will be over there for the next