Reasons to limit computer admin rights.

July 2nd, 2009

When I started at UMW, as Director of IT Security in 2007, I had planned to remove computer administrative rights from staff, because they are more likely to access sensitive data, but continue with faculty having full control of their computers. My viewpoint aligned with VITA’s policy as well. Since that time both VITA and I have changed our minds. VITA explicitly removed the faculty exemption in June of 2008. At first I didn’t agree with their decision to limit a professor’s computer access, but now I do.

The Conficker/Downadup worm did a number on UMW, and it is probably still doing damage. Infections spread through departments across sections of  the network. There were over 100 known infections and it took DoIT, myself included, over 3,000 staff hours from mid November 2008 through April 2009 to attempt to clean some of these machines. I used to be very confident in my ability to remove viruses, but this worm is very insidious and it installs various other pieces of malware. Part of Conficker’s business model is to get a fee for each instance of malware it installs for clients. Machines of which I was certain were clean would then be reported by REN-ISAC as still containing malicious code.

Viruses have become more sophisticated. In fact, there is malware that can infect the BIOS which means wiping the drive has no effect. What is the best defense against such an attack? Don’t give it the ability to install in the first place. Anti-virus software alone is not enough because the code writers will just tweak the software until the latest definitions can be bypassed. Not surfing the ‘net or reading e-mail with administrative rights is the best protection, and if only everyone would color within the lines of that limitation.

That being said, I completely agree with UMW’s mission and I do not want to stifle academic freedom, especially being an adjunct for three semesters. I worked on several ways to attempt an alignment between security and convenience. You may have seen this page which allows the Help Desk to remotely do administrative tasks, avoiding the need for someone to make a trip to, or from, George Washington Hall.

Another option that I recommended was virtualization. One could have a virtual machine to use as a sandbox and have complete admin rights to it. An argument against that was “Couldn’t that still allow an infected machine on the network?”, and the answer is “Yes”. However, a virtual machine would not be a ‘member’ of the network and should not have the same access to sensitive resources, such as Banner, as a domain machine, and passwords on the VM should not match production passwords. VMs don’t usually run all the time and are often shut down reducing the spread of infection. Infected VMs are easier to replace than infected hardware and the non-physical BIOS can easily be cleaned.

Virtual machine snapshots allow one to return the VM to a known state. I use this technique when research, as a certified ethical hacker, is likely to take me to malicious sites. When done I revert to the previous point and all changes in the VM, including malware, are completely removed. If teaching a class, and encountering an obstacle requiring admin rights, a professor could install the needed application into a virtual machine, that is if assistance from DoIT was not readily available. Faculty at CGPS do not have local admin rights on any of the lab/classroom machines and virtualzation is used often by both students and professors.

The ‘admin rights for faculty compromise’ that DoIT came up with was to create local admin accounts for those requesting such access and demonstrating a need for this capability. This compromise is still a violation of VITA policy, but an exception could be made.  However, my experience has seen little understanding from that organization. Anyway, a local admin account could be used with RunAs to launch programs in the context of a computer administrator. A technique I used for years at the State Dept. was to run a CMD prompt as an admin and programs launched from that window would inherit the needed privileges. I was able to work around every perceived need to ‘log in’ as that account and only used the credentials within the context of my ‘regular user’ login. Web browsers can be launched temporarily solely for the purposes of installing plugins and extensions, for example.

Members of the UMW community have had personal credit card numbers stolen by ‘web browser hijackers’ and fraudulent purchases have been made, even as far away as Mexico. If UMW continues to follow the pre-2008 local admin policy then it is only a matter of time before significant quantities of personal information are compromised.

The decision to remove local admin rights is not a ‘control’ issue, it is a safety precaution.  There was once a time when many of us didn’t have anti-lock brakes, air bags, or even seat belts in our cars, but now we want them, expect them, for our safety and the protection of those riding in our vehicles.  Not using a computer as a local administrator helps protect not only our own computer and data, but also those using the network along with us.


Accessing the Internet with lower privileges. (Subtitled: Surfing Safer)

July 5th, 2007

By default XP creates all users as full administrators on the PC. Now I know that everyone creates another account for day-to-day use that has fewer privileges, right? No?

After patching and having a firewall, including a home router, the main ways that machines are compromised are through malicious web sites or e-mail. Using one’s web browser as a full administrator makes it much easier for a computer to get ‘owned’. Where I used to work the vast majority of the users were not local administrators. Scans would be done to look for malware and occasionally there would be machines that had lots of spyware installed. In every case the user’s account would have elevated privileges.

That being said, it can definitely be a pain to have two different accounts (though there are techniques that help quite a bit. RunAs.exe, for example). Since most attacks come through web browsers or e-mail, there is a way to run them in a safer way.

One way to surf safer is to use Firefox, Opera or some other web browser besides Internet Explorer. I’m not saying IE is poorly coded but it has three things working against it:

  1. It is the most commonly used browser so it is the biggest target
  2. It is closed source which prevents thousands of security experts looking over the code
  3. It has Active-X which is basically a way to install a program over the Internet.  Actve-X is not as ‘contained’ as Java and can do more damage.

Many pages don’t work properly in non-IE browsers. There is great plugin that allows pages to opened inside of Firefox being rendered by IE. This plugin is set to always open Microsoft or MSN sites in IE. Other pages can be opened in IE with a right-click.

Instead of Outlook or Outlook Express for e-mail use Thunderbird or Eudora (which will be open source soon). Regardless of the e-mail client, attachments should be considered unsafe by default. Gmail is a great way to protect one’s computer from malware via e-mail as they have quite a few layers of protection.

Another option, which may not be for everyone, is to launch programs with fewer privileges. There is a tool that was recently purchased by Microsoft called PsExec which can, among other things, launch processes but it “strips the Administrators group and allows only privileges assigned to the Users group.” What is handy about this method is that all bookmarks (excuse me, Favorites) are still the same and it is possible to run the program as an admin if necessary. Here is sample syntax for launching IE with PsExec.

psexec -l -d “c:\program files\internet explorer\iexplore.exe”

I’ve changed most of my IE shorcuts to use the above syntax. I’ve been using it for about a year now and most sites work just fine. Ironically, the Windows Update site does not work unless it is running as an admin. No problem, I just launch IE from an unmodified shortcut.

Once again, none of the above techniques help with saving attachment or downloading malware and then launching it separately. Don’t trust attachments. Gmail won’t even let you download a .EXE file.

Oh yeah, some of you are wondering about Vista. Well Vista, by default, runs account with reduced privileges and then asks “Are you sure”, if the program wants to do something normally requiring admin rights.


Using “PGP” in Gmail

May 18th, 2007

Yesterday, someone asked me if I use PGP, and at the time I wasn’t, but I am using it now. The methods I used are likely to be applicable to UMW students, because I set this up in Gmail. Next year, hopefully, Gmail will be the standard e-mail for students.

I initially set this up on a Mac and used these instructions to get started. Things didn’t seem to be working at first, but after opening a new terminal all was well. This link helped with some of the syntax, and finally, here is the link to FireGPG to install the extension that hooks into Gmail running in Firefox.

FireGPG example

The above is a screenshot showing the new buttons, context menu, and an example of encryption in Gmail.

At home on my Windows machine I installed the GnuPGP for that OS and imported the keys I had created on the Mac. I’ll probably use this software for key management on Windows.

Also for a Mac you may want to use GPG Keychain Access for managing keys. Here is an option for Gnome users.

Happy Crypting!


css.php