 My name is Daryl Highland. Today's presentation is the Insecure Workstation. I had a lot of fun putting this together and I hope everyone enjoys it. The Insecure Workstation, Bob Reloaded. The information provided in this presentation is for educational purposes only. Just use good judgment. Today's presentation has two parts. Rights escalation use and API call vulnerabilities. This is kind of an old issue. They just won't die. I thought it was important just to bring it out. Maybe we can put it to bed eventually. The second part of this is subverting Windows logon. A few key takeaways in today's presentation. A better understanding of desktop security, simple desktop console vulnerabilities, and protecting information assets with layer defense or defense and death principles. And of course, since this is DEF CON, subverting desktop security for fun and entertainment. What is a help API vulnerability? It's a vulnerability that is exposed when an application running with system level rights makes an API call to the help viewer. And does not drop any of those privileges before invoking that help viewer. A user then, using the help viewer, can access other applications which will execute at system level, of course. And as you can see with the bug track on this, 2003, this is nearly two years old. So why is it still an issue? And the other question is how widespread is this vulnerability? To tell the truth, I'm really not sure how widespread this is. But I do know one thing. Over the last eight months, I've discovered one application during product testing that still had to help API vulnerability on it. Two, I found another vulnerable application running on my company's network that had never been reported yet. And third, I actually found an application that had been reported in bug track, but it was running on someone else's network, unpatched. So this is a reality, and this is an extremely simple vulnerability. Now, why do vendors continue down this path? Of course, the issue is money. They want to beat the competitors to market in any corners and not properly security testing their applications prior to going to market. Vendors also may presume that users are not abusing their products. Obviously, they've never been to DEF CON. Sell first, fix later, make you pay for it. I don't know about you, but when I got to go back and patch 20,000 systems because of some lame vulnerability that should have never been in the product with the market, I'm upset. Now for a quick demonstration. The first one on this list, Spy Sweeper, anti-spyware enterprise version. This was version 1.5. Since I discovered this, the vendor did release version, I believe, 2.0, that fixed the vulnerability. But of course, how many people are running 1.5 out there? So let's take a quick look at how simple this is. A user just needs to open up the standard Spy Sweeper GUI, launch the help, the help viewer. Within help viewer, there's many paths that he can take, but we'll take the simplest one. Now let's take a look at Task Manager to see how this is running. So if we look at Task Manager and look at Spy Sweeper, the main application, we can see it's running at system level. Obviously, when the viewer is kicked off, it's running at system level also. And of course, since we spawn Command-DXE from there, it's running at system level. This is basically a textbook help API vulnerability to the T. So after I found this during product testing, we didn't buy the product. I started looking at our network and taking a look at Novel's Networks and Works Remote Desktop. It puts a little icon in the lower right-hand corner of your screen. Right here it is. I'm not going to run it because it's a textbook help API vulnerability. I called, tacked it, Network and they quickly released a patch. But of course, how many people are running the unsecure version of it out there? The third one in here, McAfee AV-4051. As you can see, the bug track was actually reported on this in September 15, 2004 and McAfee quickly released a fix for this. It's a fairly old version, but you run into many companies you typically run older versions. You can't afford to constantly upgrade every time the vendor comes out with something. This one is a little different. I want to show it to you because it doesn't have the help API vulnerability. That was actually fixed in it. If you go to the help viewer from here, it's going to be fine. But interesting thing about this product, I was actually taking a security class, a security class. In the class, at lunchtime, I decided to have a little fun. I started playing around with their desktop systems in the security class. I found this vulnerability. Of course, it had already been reported, but I didn't know it. How many of us are capable of reading all bug tracks and remembering them all? If you drill down in this thing and go to... We go to reports, we get a nice little browser button. These are always fun. Of course, right-click on it, go open, and there it is. Now, if we look at Task Manager, this is going to be running at system level also. So how do you tell if your systems are vulnerable? Just like I did there. Just take a look at them. Look at Task Manager. Take a close look at all the services running in Task Manager with system level. Do any of those interact with the desktop? If they interact with the desktop, there's always a possibility that a vulnerability could exist in there. Take a close look. What icons are running in the system tray? Do they launch applications that are running at system level also? And of course, what applications need higher rights to function properly? Antivirus, anti-spireware, remote management tools, auditing tools, auditing applications may need to run at higher rights. So scrutinize those applications a little closer. How do I protect myself from help API vulnerability? Group policies. If you sat through my presentation last year, you may not think group policies is a good solution. But I think it works in this scenario right here and has features that you can use to shut down some of these holes. Remove the icon from the system tray. What applications have the ability to go ahead and remove the icons from the system tray so the viewer can't do it? Also, a lot of those features can be locked down. If you install your applications right out of the box, a lot of times, that's how these vulnerabilities get brought into your systems. And of course, testing all new applications, you need to go out there, look at all your applications and test them before you purchase them. Save yourself some money in headache because you're going to have to go back and patch them. Okay, let's have a little bit of fun now. This year's project, Severity and Windows Log On. This year's research project and what we learned. I like to give credit to some friends of mine that played a big part in helping me with this. They did some of the coding, helped me with the coding. In this part here, as part of this project and their research. I like to give them credit for that. Three rules that drove this research project. It must be simple. I like simple exploits. Simple hacks. I like something I could actually go teach my grandmother how to do and she would understand it. It needs to fit in my pocket if not in my head. I like things that, you know, it'll easily fit in a CD or a USB if not fit in my head. It's worse than trying to do a proof of concept that somebody's came out with when you got to put in a 400 megabyte footprint onto a box to actually make it work. And last, it must be easy to protect against. If I'm going to go through this trouble to figure out these exploits and these issues and teach people, I want to be able to teach them how to protect themselves also. That's very important to me. So let's get started. Can Windows Log In be subverted? Yes, it can. You'll see. Curiosity, just because it's there? No, I didn't do this just for curiosity. Of course, I did it to get a better understanding of the security vulnerabilities that exist in the company's environment where I work and be able to protect them. That's what I'm being paid to do. Where? On XP, Windows 2003, this is where we've tested this at. Of course, it's so simplistic as you'll see. It'll easily be carried out on a Windows NT or a Windows 2000 box. When? Bob is back on the job. If anyone's seen my presentation last year, I introduced Bob as a character. Bob works for his uncle and he is a hacker and he likes to subvert desktop security for fun and entertainment and torment his sys admin in the process. Now you ask how? Well, this exploit has two pieces. There's a methodology, the attack and a programmatic attack. It's a simple program that we're going to use and deploy onto a system that gives us the ability to bypass the Windows log on. Neither one of them can do anything by themselves but when we bring these two concepts together we accomplish this goal. Okay, let's start. Exploit part one, utility manager. What is utility manager? Well, let's take a close look at what Windows has to say about utility manager. Utility manager enables users to check an accessibility program status and start or stop an accessibility program. So basically, utility manager is an application that you can use to start and stop other applications. Let's read a little more. Users can also start accessibility programs before logging onto the computer by pressing the Windows logo key and the plus welcome screen. So basically, utility manager is an application that I can use to start and stop other applications before I ever log onto the system. How does it work and how do we access it? Well, what Windows helped said, you hold down the Windows logo key and you hit the U key and up comes utility manager. From within there, you can start and stop accessibility programs. There you go. Why is it such a problem? Well, obviously, as I mentioned, a user can start and stop applications before he ever logs on. Once you're logged on and you use the accessibility program, it runs under your user ID and runs under your credentials, not an issue, but if you're not logged onto the system, it runs as local system. So, we can start and stop applications prior to ever logging on the Windows and we can get them to local system level rights. So, when we started this, we thought, okay, well, does that mean if I can take example, let's say command EXE, CMD EXE and rename it OSK.EXE, which is the on-screen keyboard, would Windows let me launch this or would it give me a security error to prevent me from running it? So, we went ahead and we overwrote the OSK.EXE and we executed it and at first, before we logged on, and nothing seemed to happen. Well, further investigation, we found out that it did execute with no errors, but it was running in a non-interactive mode. It was in the background. We did not have access to it. But, if you could hold some questions to the end, because we're going to be really tight to get through this presentation, I apologize, and if I can't answer them at the end because we don't have time, I'm off-line and I will try to answer your questions and if I don't have the answers, I will try to get those answers for you. How's that sound? So, we went ahead and did that and it didn't seem to work, but when we looked at it, we found out it was running at system level, but in the background in a non-interactive mode. So, over the next couple of slides, we'll explain what we did. Exploit Part 2, the log-on screen. User interface objects are managed using Windows Stations and desktops. Windows Stations come in two flavors, interactive and non-interactive. The only interactive Windows Station that can be defined in an application is Windows Stay Zero. Also, Windows has what's known as multiple desktops. The default desktop is the desktop after you log in where you do your work on a day-to-day basis on a Windows system. The screensaver is also defined as a separate desktop. Haven't really played with it yet, but we probably will. The WinLog-on screen also is a completely separate functioning desktop. So, basically what we decided we needed to do, we need to get the program that we replaced the OSK EXE with. We need to get it to interact or launch interactive mode and we need to get it to launch interactive mode on the WinLog-on desktop. So, basically we put together a simple program that would spawn command EXE under WinStayZero WinLog-on desktop. So, let's move in that direction. Exploit part three, the code. This code we put together poses no security issues by itself. Basically, we're just setting the create process thread to run under the WinLog-on desktop. The security breakdown is how we use it. It's the methodology. We basically, we've discovered a architectural issue with the way utility managers run on the system and the ability to run it prior to ever logging on and get it to launch at system level. The code is extremely simple. So, let's look at the entire code. That's it. And as you can see, if you go down through there, right above where it says create process, see Windows System 32 right above that line, is where we have the WinStayZero, the interactive desktop and the WinLog-on as the desktop, but we want to run this that. If you go out and look at, I know there's plenty of coders in the room. I mean, this is just a simple code snippet. I've seen this in a hundred different applications. The only thing is we're different is mostly applications I've seen define default instead of WinLog-on. That's the only thing different with this code. So, we come to the final part of this, the delivery. Now, when I first start this project, we got around to this point and I said, oh my gosh, how am I going to deliver this code to the system? This has to be the most difficult part. Well, it turned out to be the most trivial part. We're going to cover some high level concepts here. Admin access. Well, you can overwrite it with admin access. That's when we did our first test. We did that. But we already have admin access to the system, and that really accomplishes nothing. We can use some of the help API vulnerabilities I showed you to overwrite the file. But, you know, if I'm already system level and logged in, you know, what's the point? Bit level modification to the hard drive. We actually took a DOS boot disk and some old DOS utilities and identified the track sector where OSK was and overwrite first part of the application and got that to work. But somewhat complex and it goes against my theory moving forward of keeping it simple. The one thing is maintenance boot disk. This is a fairly broad category. Linux is a possible solution moving forward. There's a lot of work going on in writing to NTFS file systems. Another solution an attacker could actually have a stolen or pirated copy of Windows PE, Windows pre-installation disk is a possible solution. But also if you go out and Google you'll find out there are other PE or pre-installation is available, which is basically an open source solution maintenance disk type things. And I did find a couple other solutions out there that look very viable. So I'm going to say just kind of pick your own poison. Go out to Google. Google for writing NTFS. Google Linux NTFS. Google Windows PE or pre-installation. And you will find a multiple of solutions. I sat down to try to figure this thing out. I said, well, there's no sense in reinventing the wheel. Let me go out on the Google and see if anyone's already doing this. Well, I search for maintenance disk, maintenance boot disk. And probably within 15 minutes I had a bunch of solutions. I downloaded a couple of them. Within an hour I had a fully functional solution. So this is a no-brainer here. So we're going to move on a little further from here. Okay. Bob reloaded. So now we're going to go ahead and look at this actual exploit and see how it works. A little history on Bob. As I mentioned, Bob works for his uncle and he is a hacker and he likes to subvert security. Well, it turns out Bob's uncle has a competitor against his company. His competitors getting ready to release some new products out there. And Bob's uncle thinks, you know what? It would be really good if I could steal that information off him. So what he does, he gets Bob and the competitor happens to be looking for a janitor. So he sent Bob down there to apply for this janitorial job and Bob gets the janitorial job. So Bob shows up to work first night and he brings his cleaning tools just to let you know I did pre-stage the exploit on here because the disk would obviously whirl for three minutes and you would just see a black screen. So you really accomplish nothing. If anyone actually wants to see me own a system that hasn't been owned yet just get with me after this and I will run the disk through there so you can see it happen. So Bob goes through and he scopes out all the offices and he finds an office. He finds John's office matter of fact and what he does is he throws his disk in, he boots John's system, it spins for a few minutes and he pulls the disk out and he reboots it and he goes about his way. The next day John comes in he logs onto the computer and of course he's not going to see anything there because he doesn't know about utility manager, he doesn't use utility manager. There's no applications running in memory, they have to be executed from somebody at the console. So there's nothing to be detected there. So John comes in, of course he logs in, he does his thing that day and when John's finished what he does is he does what a lot of us do, he doesn't log out, he locks his screen and he goes his merry way or he lets his screensaver kick on which locks his screen. So about nine o'clock Bob comes rolling and let's see what Bob's going to do. Of course the system's already been staged so set up by Bob, so Bob comes in, he goes utility manager he brings up the utility manager he goes to the on-screen keyboard and he launches it. After we did this we started playing around with this and the reason why I'm just running the CommandDXE versus the entire desktop is we found out the resources on the WinLogin desktop are limited. If you get ExploreUp which is a real hog, the thing will start flaking out and applications won't run properly. But from here Bob can pretty much do what he wants. One of the good things to run is task manager from task manager you can pretty much stop and start processes. You can matter of fact you can see John's processes in there and we're running at system level. Bob could go ahead and several things he could do he could use his USB make his job easier he could just dump the hashes out take them offline and crack the passwords on the system if you wanted to that's not a problem. Another thing Bob could do and I've had a lot of success testing it, he could take a small memory tool like Tiny Hexer run this against all the running processes. Scan all the running processes for the words password pass WD, PWD and I successfully in many times have been able to strip the users password plain text out of the running processes memory on many occasions for multiple applications specifically if the application requires authentication and it's written in Java. Now at this point the reality is that he's trying to steal stuff from this company the chances are that information is probably not going to be on this local computer he's going to go to the network so if you look to see what drives are mapped you can see there's nothing mapped but if we run netstat oh that stinks ok he can see that there's no map drives apparently disconnected but we can probably get that connected up in your mind we'll see we found out that since we are running in a completely separate desktop running at system level we're not John we don't have John's network resources and can't get to them we found out so me and my friends started talking about this and what was the possibility of getting the user John's security token so we we did some research on this and using standard Windows API calls we devised a way that we could actually impersonate John and get all of his network resources and the way that would work was we wrote a small simple program which I'm not going to release because I think it could be misused but if we run this called impersonate and we point at John's running processes and we'll pick the one for Explorer 532 comes up as a success and if you see it switched over to John now one of the quirky things from here though that if I typed in a command it would run a system the next time I typed in a command it was run as John for some reason on the screen it would keep switching back and forth so to get away from that issue we'll exit out of the one running a system now we are purely running as John and now we can see his network drives we have full access to all John's resources on the network it shows it as disconnect let's see if we can get it to reconnect there we go so they're reconnected we also found out if John has access to another system that he's not mapped to we could actually make mappings to that system and windows would authenticate us as John to that system now there's one thing I wanted to show you there's a couple of other things I want to show you there's one I wanted to show you just to show you it is true there we go we can get a full desktop up we can do that hopefully it won't flake out on me it'll switch over his desktop and then we can control or delete switch back to the other desktop so you can see there's multiple desktops the one thing we did find out I did run this against the 2003 server there doesn't seem to be any resource issues on the windows log on screen so you can run full explorer desktop from there and run all the applications you want I think I had about a dozen up running without any resource issues we're logging on to the system okay let me go ahead and shut these down there's one other thing I wanted to show you we this can be used in a kind of a different way let's go ahead and log off here and we're going to log on as Mary Mary's system administrator doesn't like her doing anything so he has her kind of running in a restricted mode and if we thought you know if we set this application up to run on the win log on desktop we wrote the code to run on the default desktop but executed it from the win log on desktop would it spawn a shell on the user's desktop and run it at system level so Mary tries to open up the clock he comes up and says you don't have privileges to do that so Mary staged the system she wants to break out of that so she switches over here without logging out it just switches to the win log on screen windows you and she can use the magnifier which is where she wrote her code she can go start, cancel cancel boom there you go now she has a command prompt at system level she can bring up task manager killer windows explorer run another windows explorer now she can do what she wants so how do I protect myself from this exploit obviously group policies maybe you could remove or disable utility manager just take it off the system but bob could probably put it back on there disable booting from cd rom disable booting from floppy lock to bios that would obviously slow him down if you're worried about attack against a service system you can run a host ids on that system that would detect if bob went in your system and overwrote some of the files so how do you prevent back door exploits by employees someone like mary policies that's always a solution you catch you can always fire separation of duties application system verification and testing before deployment the reason why I say that I want you to think about something I don't know how many people in here work for fairly large companies do you have base images of your desktops how do you control those where are they at who does it do you have one person who has base images sets it all up he may keep it on his own hard drive I don't know he might keep it on the network server do you secure those things separation of duties somebody who sets something up you don't want them doing the verification and testing of it obviously of course these are things you need to consider how do you prevent non-employee access bob got into this company who is that maintenance man and what do you really know about the night janitor using social engineering to gain physical access do you do security awareness training to your employees dealing with people gaining physical access to your company another big one contractual agreements with contractors and outsourcers whether it's janitorial or application development when I was doing this project these are the things I started thinking about and started asking these questions at work we're real big on application development outsourcer to write code for us we don't let him test and verify it for us and all the once we just put it into the system we don't do that we have these contractual agreements to protect your company's assets and hold that company liable but yet we turn around and hire janitorial service that basically has full access to every office in your building and we have nothing to protect us from them defense in depth is the only effective method to defending your network it's a combination of people, processes and technologies they're applied at each layer if one layer is compromised your entire organization is not compromised this consists of policies training physical access parameter security internal networks host application and data so let's think about this we would have concerned ourselves with physical access or policies and it required a background investigation of bob we would have found out he was the nephew of our competitor and probably wouldn't have hired him okay so that breaks down that layer fails we let bob through the door the next phase is let's say the host machines if we had set our host machines up so they couldn't be booted from a floppy or booted from a cd and we had set other restrictions on there with group policies we would have caught bob there or at least slowed him down slow enough that we may have caught him with defense in depth so let's say that layer fails bob gets through bob gets access to a host system bob puts his code on there now obviously the stuff he came in there to steal was research and development stuff john had access to research and development if this was the heart and soul of that company how come two factor authentication wasn't required or the data stored in an encrypted manner because if it had been bob would have failed so this is the concepts of defense in depth combination of people processes and technologies applied in each layer if one layer is compromised your organization is not compromised questions and hopefully I can answer them if I can't I got business cards here you got my email address up there shoot me the question I'd be more than glad to try to answer it for you and remember as you're asking these questions I'm not a coder if it's a coding question send it to me in the email and I will answer it no I do not believe so so from remote desktop you cannot pass that key combination or will not recognize it or run the one thing we haven't tested though the impersonation function is one of the things I want to test what if I was on a citric system with multiple users we did find out that that function will not work unless the exploiter is running at system level gain system level on a citric box could he take over the identity of the other users this is the one of the things we're going to be testing real soon