Hacking Poly, Part I: Lockdown and Breakout
LOCKDOWN
The premise is simple. You are the technician in charge of orchestrating secure and private operation of approximately 200 public computers in a library. After painful reasearch, you settle on a Faronics product by the name of "Deep Freeze". This program touts the ability to boot "frozen", allow the user any freedoms they want, and then undo them on a consecutive reboot. Security solved.
Now there's the other half of the equation, privacy. You realize that the average user wouldn't understand how sensitive (and easily accessible) much internet/computer related data is if it smacked them in the face. As a result, part of your job is protecting them from themselves. To do this, you not only enforce maximum privacy rules via Internet Explorer (accept no cookies, 0 day history, no cache, etc), you lock down the settings themselves via group policy. Privacy solved.
By this point you're feeling pretty confident with yourself. It's not even two o'clock and your systems are running beautifully. In fact, in what can only be called a stroke of pure genius, you've eliminated the need (and potential security risk) of having unique and individual user accounts for every open access user in your public areas. You've set your policies to automatically logon as a local administrative account, while using GPO's to lock said accounts down.
This situation exactly describes the current Cal Poly security architecture. Unfortunately, their brutal decision to deny all cookies disables the ability to use any website that has sessions (although some newer sites do use querystring based sessions, it is much less desireable). Favorites among the college crowd, including most notably Facebook, are completely inaccessible from the supposedly "Open" systems at the university.
The disenfranchising this causes creates a huge pool of ambivalence between the IT support staff and the average student. From a network administrators standpoint, thats not a good place to be starting. Unfortunately, again, the IT staff are less concerned with providing a productive work environment than providing a controlled work environment (note that these are not incompatible terms as I will describe in a future installment of this series).
BREAKOUT
So the question students are left with is simple: How do we make the computers work, the way we want them to work? Actually, in spite of themselves, the Poly IT staff have left open the perfect opportunity to do just that, without doing any noticeable, lasting, or relevant harm to the systems. Why is that good you ask? The less harm you cause, the less likely it is an irritable administrator is going to track you down and harass you for it.
A Quick Note on GPO's
The Group Policy Object can be applied to a user in a number of ways. While different ways might accomplish essentially the same task, the inner mechanics of how they do it can have dire consequences. While the numerous interesting and different ways of doing this will provide interesting fodder for a future entry, for now we only care about the basic two.
A policy can be applied to a computer, or to a user. At Poly, they opt for the latter and have created a general "Open Access" user account with a strict set of policies defined. Because as a general rule, deny policies override allow policies, this lets Sys Admins and other priveleged Faculty use the same student systems with elevated (ie, non-restricted) access.
Step 1: Stealing SYSTEM Privelegs
As you may have guessed based on the note, using a user based policy leaves a whole in your security. If a user can somehow change their credentials, or at least change what credentials Windows thinks they have, they can circumvent almost any policy you've put in place. In our case, this means using an old (and relatively well documented) trick to logon to a computer with the builtin SYSTEM account (designed to allow certain NT services to function properly).
To do this, we need to launch a command prompt (Start | Run | "cmd" | Enter). At the prompt we'll use the "at" command (command line version of the Task Scheduler) to launch Windows Task Manager. The exact command we want is "at xx:xx /interactive taskmgr.exe" where xx:xx represent the time (in 24 hour format) approximately 1 minute from now. When that time rolls around, Windows Task Manager will launch itself... on SYSTEM authority!
Now, we could essentially operate the computer from just this Task Manager, but a GUI might be more pleasing. No problem. On the processes tab of our Task Manager, we want to kill the copy of "explorer.exe" opened by our user. This will close the shell, and essentially (as far as Windows cares anyway) "log us off". Returning to the application tab, click "New Task..." and type "explorer". When Windows relaunches the GUI shell it will do so on SYSTEM authority, and you end up logged on with SYSTEM credentials.
Step 2 - Blocking Policies
Only application that we launch either directly from our Task Manager instance, or from the desktop shell we've just opened will acually have SYSTEM authority. Make sure you're aware of this as you continue with these steps. Windows GPO's are stored in the Registry with some put into effect at logon, and some at runtime. The particular ones we care about go into effect at IE's runtime.
Launch regedit (New Task... | "regedit") to start off. The policy we want is in HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Internet Explorer. Right clicking on it and choosing permissions reveals a collection of Microsoft permissions (similar to NTFS permissions). We want to explicitly Deny everyone access to this key, which will have the same effect as disabling the policy.
First, we have to open the advanced permission dialogue and uncheck the "Inherit permissions from parent" box, then choose to Remove current permissions. While this will leave the key with no explicit allows - and thererfore technically a deny - we want to be extra careful and concise with what we do. So, add a permission for "Everyone" and choose Deny for everything. Click OK and close regedit.
Changes made to the registry are "live" in that they don't require a save. However, in general they aren't reprocessed until reboot. With Deep Freeze installed that's obviously not an option. No problem, returning to our "New Task..." button we can run the "gpupdate" command which will requery the registry and refresh our policy.
Step 3 - Accepting Cookies
After the policy is refreshed we're basically ready to be Internet Hooligans (please note, while Deep Freeze will continue to protect the computer, it won't protect you're privacy). The last step is actually telling IE it's ok to accept cookies.
Open the browser, either with the desktop icon, or through the taskname "iexplore" in the "New Task..." button. Click Tools | Internet Options, and lo and behold the "Privacy" tab has appeared! On it, you'll want to change two things. First, you need to set the cookies to low (accept all cookies). Then, in the advanced menu, override automatic cookie handling, set both first and third party cookies to accept all, AND check the "always accept session cookies" box. I know it seems like overkill, but this IS IE we're talking about.
Once you click Okay, you're ready. Browse away in your newly unlocked computer. When you finish, it would probably be prudent to reboot the comptuer, and effectively erase your tracks.
Step 4 - Other Fun Stuff
While logged in with SYSTEM authority, you'll find other options open to you. For example, you're able to edit the security settings in IE, and change your Trusted Sites zone file. This means you can add http://www.aim.com to your Trusted Sites, reset policies for it to low, and suddenly access AIM express (for example). Of course, while in as the SYSTEM account, you can just as easily download and install a full version of AIM.
Basically, once you've got this setup, you are the (local) computer. Anything you could do on your computer you can do on it. Part II of this series: How theses same security principles could be applied in a more effective, AND less intrusive manner.
The premise is simple. You are the technician in charge of orchestrating secure and private operation of approximately 200 public computers in a library. After painful reasearch, you settle on a Faronics product by the name of "Deep Freeze". This program touts the ability to boot "frozen", allow the user any freedoms they want, and then undo them on a consecutive reboot. Security solved.
Now there's the other half of the equation, privacy. You realize that the average user wouldn't understand how sensitive (and easily accessible) much internet/computer related data is if it smacked them in the face. As a result, part of your job is protecting them from themselves. To do this, you not only enforce maximum privacy rules via Internet Explorer (accept no cookies, 0 day history, no cache, etc), you lock down the settings themselves via group policy. Privacy solved.
By this point you're feeling pretty confident with yourself. It's not even two o'clock and your systems are running beautifully. In fact, in what can only be called a stroke of pure genius, you've eliminated the need (and potential security risk) of having unique and individual user accounts for every open access user in your public areas. You've set your policies to automatically logon as a local administrative account, while using GPO's to lock said accounts down.
This situation exactly describes the current Cal Poly security architecture. Unfortunately, their brutal decision to deny all cookies disables the ability to use any website that has sessions (although some newer sites do use querystring based sessions, it is much less desireable). Favorites among the college crowd, including most notably Facebook, are completely inaccessible from the supposedly "Open" systems at the university.
The disenfranchising this causes creates a huge pool of ambivalence between the IT support staff and the average student. From a network administrators standpoint, thats not a good place to be starting. Unfortunately, again, the IT staff are less concerned with providing a productive work environment than providing a controlled work environment (note that these are not incompatible terms as I will describe in a future installment of this series).
BREAKOUT
So the question students are left with is simple: How do we make the computers work, the way we want them to work? Actually, in spite of themselves, the Poly IT staff have left open the perfect opportunity to do just that, without doing any noticeable, lasting, or relevant harm to the systems. Why is that good you ask? The less harm you cause, the less likely it is an irritable administrator is going to track you down and harass you for it.
A Quick Note on GPO's
The Group Policy Object can be applied to a user in a number of ways. While different ways might accomplish essentially the same task, the inner mechanics of how they do it can have dire consequences. While the numerous interesting and different ways of doing this will provide interesting fodder for a future entry, for now we only care about the basic two.
A policy can be applied to a computer, or to a user. At Poly, they opt for the latter and have created a general "Open Access" user account with a strict set of policies defined. Because as a general rule, deny policies override allow policies, this lets Sys Admins and other priveleged Faculty use the same student systems with elevated (ie, non-restricted) access.
Step 1: Stealing SYSTEM Privelegs
As you may have guessed based on the note, using a user based policy leaves a whole in your security. If a user can somehow change their credentials, or at least change what credentials Windows thinks they have, they can circumvent almost any policy you've put in place. In our case, this means using an old (and relatively well documented) trick to logon to a computer with the builtin SYSTEM account (designed to allow certain NT services to function properly).
To do this, we need to launch a command prompt (Start | Run | "cmd" | Enter). At the prompt we'll use the "at" command (command line version of the Task Scheduler) to launch Windows Task Manager. The exact command we want is "at xx:xx /interactive taskmgr.exe" where xx:xx represent the time (in 24 hour format) approximately 1 minute from now. When that time rolls around, Windows Task Manager will launch itself... on SYSTEM authority!
Now, we could essentially operate the computer from just this Task Manager, but a GUI might be more pleasing. No problem. On the processes tab of our Task Manager, we want to kill the copy of "explorer.exe" opened by our user. This will close the shell, and essentially (as far as Windows cares anyway) "log us off". Returning to the application tab, click "New Task..." and type "explorer". When Windows relaunches the GUI shell it will do so on SYSTEM authority, and you end up logged on with SYSTEM credentials.
Step 2 - Blocking Policies
Only application that we launch either directly from our Task Manager instance, or from the desktop shell we've just opened will acually have SYSTEM authority. Make sure you're aware of this as you continue with these steps. Windows GPO's are stored in the Registry with some put into effect at logon, and some at runtime. The particular ones we care about go into effect at IE's runtime.
Launch regedit (New Task... | "regedit") to start off. The policy we want is in HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Internet Explorer. Right clicking on it and choosing permissions reveals a collection of Microsoft permissions (similar to NTFS permissions). We want to explicitly Deny everyone access to this key, which will have the same effect as disabling the policy.
First, we have to open the advanced permission dialogue and uncheck the "Inherit permissions from parent" box, then choose to Remove current permissions. While this will leave the key with no explicit allows - and thererfore technically a deny - we want to be extra careful and concise with what we do. So, add a permission for "Everyone" and choose Deny for everything. Click OK and close regedit.
Changes made to the registry are "live" in that they don't require a save. However, in general they aren't reprocessed until reboot. With Deep Freeze installed that's obviously not an option. No problem, returning to our "New Task..." button we can run the "gpupdate" command which will requery the registry and refresh our policy.
Step 3 - Accepting Cookies
After the policy is refreshed we're basically ready to be Internet Hooligans (please note, while Deep Freeze will continue to protect the computer, it won't protect you're privacy). The last step is actually telling IE it's ok to accept cookies.
Open the browser, either with the desktop icon, or through the taskname "iexplore" in the "New Task..." button. Click Tools | Internet Options, and lo and behold the "Privacy" tab has appeared! On it, you'll want to change two things. First, you need to set the cookies to low (accept all cookies). Then, in the advanced menu, override automatic cookie handling, set both first and third party cookies to accept all, AND check the "always accept session cookies" box. I know it seems like overkill, but this IS IE we're talking about.
Once you click Okay, you're ready. Browse away in your newly unlocked computer. When you finish, it would probably be prudent to reboot the comptuer, and effectively erase your tracks.
Step 4 - Other Fun Stuff
While logged in with SYSTEM authority, you'll find other options open to you. For example, you're able to edit the security settings in IE, and change your Trusted Sites zone file. This means you can add http://www.aim.com to your Trusted Sites, reset policies for it to low, and suddenly access AIM express (for example). Of course, while in as the SYSTEM account, you can just as easily download and install a full version of AIM.
Basically, once you've got this setup, you are the (local) computer. Anything you could do on your computer you can do on it. Part II of this series: How theses same security principles could be applied in a more effective, AND less intrusive manner.
posted by Mike at 10:21 PM
0 Comments:
Post a Comment
<< Home