My name is Darryl 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 used in API call vulnerabilities.
This is kind of an old issue that just won't die.
So 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 in depth 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?
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 the 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.
They're cutting 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 get to go back and patch 20,000 systems because of some lame vulnerability that should have never been in the product when it went to 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 viewers kicked off, it's running at system level also.
And of course, since we spawned 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 Novell's NetWare XenWorks 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 contacted NetWare and they quickly released a patch.
But of course, how many people are running the unsecured version of it out there?
The third one in here, McAfee AV4051.
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.
And in the class, at lunch time, I decided to have a little fun.
So I started playing around with their desktop systems in the security class.
And 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?
So, if you drill down in this thing and go to...
If 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 is 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, antispyware, remote management tools, auditing tools or 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.
A lot of these 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 deploy them.
Better yet, test them before you purchase them.
Save yourself some money and 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, subverting Windows logon.
This year's research project and what we learned.
I'd 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.
I'm not a coder. I'm in the process of trying to learn it, but I'm not a coder.
So they assisted me in this part here, as part of this project, in their research.
I'd 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.
There's nothing worse than trying to do a proof of concept that somebody's came out with
when you've 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 login 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 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 sysadmin in the process.
Now you ask how. Well, this exploit has two pieces.
There's a methodology, the attack process behind it.
And a programmatic attack, a simple program that we're going to use and deploy onto a system
that gives us the ability to bypass the Windows logon.
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 1, 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 at the 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 help 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. Pretty simple.
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 are 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 are not logged on to the system, it runs as local system.
So, we can start and stop applications prior to ever logging on to Windows and we can get them to run at 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 an error?
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, we'll take it offline 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 two, 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 when 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 screen saver is also defined as a separate desktop.
Haven't really played with that yet, but we probably will.
The win log 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 launch interactive mode and we need to get it to launch interactive mode on the win log on desktop.
So, basically we put together a simple program that would spawn command EXE under win stay zero win log on desktop.
So, let's move in that direction.
Exploit part three of 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 win log on desktop.
The security breakdown is how we use it. It's the methodology.
Basically, we've discovered an 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.
And 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 define the win stay zero, the interactive desktop, and the win log on as the desktop that we want to run this at.
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 most of the applications I've seen define default instead of win log 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 started this project and we got around to this point, 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.
And 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, so 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 of 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 the 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 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 re-venting the wheel.
Let me go out on Google and see if anyone's already doing this.
Well, I searched 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.
And his competitor is 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 is he gets Bob and the competitor happens to be looking for a janitor.
So they send Bob down there to apply for this janitorial job.
And Bob gets the janitorial job.
So Bob shows up to work the 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 accomplished 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, as a 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 on to 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 9 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 to Utility Manager.
He brings up 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 a command.exe versus the entire desktop is
we found out the resources on the WinLogin desktop are limited.
If you get Explorer up, 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.
As a 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 he 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 TinyHexer,
run this against all the running processes.
Scan all the running processes for the words password, passwd, pwd.
And I successfully and many times have been able to strip
the user's 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 want to go to the network.
So if he looks to see what drives are mapped,
he can see there's nothing mapped.
But if we run netstat...
Oh, that stinks. Okay.
He can see that there's no mapped drives.
Apparently disconnected, but we can probably get that connected up
and then we'll see.
We found out that since we were 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 him,
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 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 am 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,
it 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 as system.
The next time I typed in a command, it would run as John.
For some reason on this screen,
it would keep switching back and forth.
So to get away from that issue,
we'll exit out of the one running as system.
Now we are purely running as John
and now we can see his network drives.
We have full access to all of John's resources on the network.
It shows that it is disconnected.
Let's see if we can get it to reconnect.
There we go.
So they are reconnected.
We also found out if John has access to another system
that he is not mapped to,
we can actually make mappings to that system
and Windows would authenticate us as John to that system.
Now there is one thing I wanted to show you.
There is a couple of other things I wanted to show you.
There is one I wanted to show you.
Just to show you it is true.
There we go.
We can get a full desktop up.
Now if we log in as John,
let's go ahead and do that.
Hopefully it won't flake out on me.
It will switch over to his desktop
and then we can control-alt-delete
and switch back to the other desktop.
So you can see there are multiple desktops.
The one thing we did find out,
I did run this against a 2003 server,
there doesn't seem to be any resource issues
on the Windows logon 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
without ever logging on to the system.
Okay, let me go ahead and shut these down.
There is one other thing I wanted to show you.
This can be used in kind of a different way.
Let's go ahead and log off here.
And we are going to log on as Mary.
Mary's system administrator doesn't like her doing anything
so he has her kind of running in restricted mode.
And we thought, you know,
if we set this application up to run on the WinLogon desktop,
what if we wrote the code to run on the default desktop
but executed it from the WinLogon 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 WinLogon screen.
Windows U.
And she can use the magnifier,
which is where she wrote her code.
She can go start, cancel, cancel.
Now she has a command prompt at system level.
She can bring up task manager,
kill her 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 the 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 into your system
and overwrote some of the files.
So how do you prevent backdoor exploits by employees?
Someone like Mary.
Policies, that's always a solution.
If you catch it, you can always fire.
Separation of duties.
Application system verification and testing before deployment.
And 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 that actually builds your base images,
sets it all up?
He may keep it on his own hard drive.
I don't know.
He might keep it on a network server.
Do you secure those things?
Separation of duties.
Somebody who sets something up,
you don't want them doing the verification
and the 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.
We hire an outsourcer to write code for us.
We don't let him test and verify it for us.
All at 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.
If we would have concerned ourselves
with physical access or policies
and 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.
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 at each layer.
If one layer is compromised,
your organization is not compromised.
Running early.
Questions, and hopefully I can answer them.
If I can't, I've got business cards here.
I've 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.
In red.
No, I do not believe so.
So, from a 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 Citrix system
with multiple users?
We did find out that
that function will not work
unless the exploiter is running at system level.
But if he's at system level,
gain system level on a Citrix box,
could he take over the identity
of the other users?
This is one of the things
we're going to be testing real soon.