backtop


Print 71 comment(s) - last by bodar.. on Feb 3 at 10:14 PM


Blogger Long Zheng of Started Something has published a proof-of-concept attack of how to use a script to easily disable the Windows UAC, do to the inherent design flaw that it trusts changes to itself blindly. Microsoft thus far has refused to acknowledge that it needs to fix the problem calling it "by design" and yanking a MSDN blog on the UAC changes.  (Source: Started Something)
Microsoft insists big Windows 7 security hole will not be fixed, is "by design"

When Windows Vista was launched, it brought to the table a new feature that was supposed to safeguard the user:  the User Account Control (UAC).  However, the useful feature, which could be disabled, became the source of a great deal of the OS's early criticism due its warning messages which some users found irritating.

With Windows 7, Microsoft decided to switch gears and is offering a less nosey UAC in the beta version of the OS.  This move was the subject to much early praise.  However, it may have now backfired as a blogger Long Zheng, who runs the blog Start Something, has detailed a proof-of-concept attack against the new Windows 7 UAC.

Mr. Zheng says the attack is a vindication of Windows Vista, and evidence that the new Windows 7 approach, while more pleasing to some, is inherently insecure.  He states, "This is dedicated to every ignorant ‘tech journalist’ who cried wolf about UAC in Windows Vista. A change to User Account Control (UAC) in Windows 7 (beta) to make it ‘less annoying’ inadvertently clears the path for a simple but ingenious override that renders UAC disabled without user interaction. For the security conscious, a workaround is also provided at the end. First and foremost, I want to clear up two things."

The flaw, which he calls "blatantly simple" to fix, was raised to his attention by a "security-minded 'whistleblower.'"  Ignored largely by Microsoft in chatter in its Windows 7 beta feedback, the issue may be present in the retail version of Windows 7 and has been known to many for some time.

Normally Windows 7 is set with the options "Notify me only when programs try to make changes to my computer" and "Don’t notify me when I make changes to Windows settings".  It uses a security certificate to determine if a program is part of Windows -- in other words, changes in the control panel don't raise warnings as they have a trusted certificate.

The "Achilles heel" as Mr. Zheng describes is that the UAC is a certified program and thus changes to it are also trusted -- even if that change is to disable it.  While he admits that he had to "think bad thoughts" to come up with a way of disabling the UAC without directly tricking the user into doing it, he says it wasn't tough.  He has posted a proof-of-concept VBScript, which uses keyboard shortcuts to select the UAC and then disable it.  The attack works against any user who has administrative permissions (as standard users are prompted for an administrative password when changing the UAC settings).

He elaborates, "We soon realized the implications are even worse than originally thought. You could automate a restart after UAC has been changed, add a program to the user’s startup folder and because UAC is now off, run with full administrative privileges ready to wreak havoc."

He adds, "This is the part where one would usually demand a large sum of money but since I’m feeling generous, there is a simple fix to this problem Microsoft can implement without sacrificing any of the benefits the new UAC model provides."

The fix, he says is to force the UAC into a secure desktop mode, whenever the UAC is changed, regardless of its state.  This, he says, while by no means foolproof, will prevent basic attempts.  He suggests Microsoft adopt the fix as soon as possible.

Microsoft, however, appears to be relaxed about the topic, as it responded to Mr. Zheng that the flaw is "by design", indicating it will not be changed before release.  Furthermore, as of this morning it has pulled a MSDN post about the topic which Mr. Zheng linked. 



Comments     Threshold


This article is over a month old, voting and posting comments is disabled

RE: ?
By dgingeri on 2/2/2009 11:24:02 AM , Rating: 5
Citation:

I've been working in IT for 13 years (Well, it will be 13 years in a couple weeks) and nearly every place I've worked that used anything from Windows NT to Windows XP, the users were generally set up as admins.

Believe me, if I could do it any other way, I would. Unfortunately, we have to run our remote users as admins so they can install local printers, (HP is too stupid to write printer drivers that can install with only power user membership) our helpdesk (for users of our products, not internally, and by far our biggest infection rate of trojans) must run as admins so that they can run the ticketing software and the phone center software, and our development department must run their own domain, that we can't lock down, so that they can test their newly developed software on their test servers.

If I could lock down users, I definitely would. The problem is that programmers don't seem to want to put in the time to make a program that can be run without being local admins. There are also far too many programmers out there who think they can change system files with impunity, which has always been the biggest source of instability in the Windows OS. I actually had one programmer in my last company contact me and ask me to deploy out a single file update (mfc42.dll) to the entire company so he could make his new program work right. (That dufus actually believed I wouldn't protest it!)

As soon as we get some smart programmers in the world, then we'll be able to get rid of things like this.

Oh, right, programmers are human. We aren't going to be able to get rid of the lazy, stupid ones.


RE: ?
By dgingeri on 2/2/2009 11:27:58 AM , Rating: 2
Oh, I forgot to mention. the stupid programmers of our help desk ticketing system actually require the users have admin rights to the SQL server in order to run the software! Can you imagine the idiocy??

And our help desk management at the time actually went with this garbage system and paid $2000 per license, and $5000 per management license for this POS software. I'm glad that manager is gone. I just wish the systems admin that approved this move wasn't my boss now.


RE: ?
By DrKlahn on 2/2/2009 1:21:39 PM , Rating: 2
None of our users run as administrators. I do agree that programmers need to be beat over the head with the need for their programs to function as a user. However we have been able through the use of utilities like Process Monitor from SysInternals to open up only the files and keys needed for the various programs to function. Some programs only require their initial launch as an administrator to setup the necessary files. As a result viruses and malware that get downloaded very rarely do any actual damage (I can't think of one incident in the last 6 months).

Remote sites are taken care of by remote control applications which allow the IT staff to install software and manage them. However painful the connection speed, it is a small price when compared with the labor needed to actually diagnose and repair an infected system. Laptops that absolutely have to have the ability to install devices on the road log in locally and then into AD when returning. The AD account of course does not have admin rights.

The users complained at first but looking at the statistics it is irrefutable that this has been a huge benefit. It takes a lot of testing and effort to get programs to function as a user, but it is well worth the investment. It's a shame that more programmers don't take this issue to heart as this single biggest reason Windows has the security issues it does.


RE: ?
By gstrickler on 2/2/2009 4:20:47 PM , Rating: 2
The way to encourage programmers to write software that doesn't require admin rights is to make your programmers run with the same privileges you expect users to have (e.g "power users" or "users").

Yes, developers may need to be able to install software on their machines. For that I give them a second login that gives them local admin rights (but very limited network access, so they can't normally run under that account to do their job). Be sure you're logging changes to permissions, group memberships, etc. If they use the local admin account to upgrade their domain user permissions (e.g. to a local administrator), they can be terminated.

Then, have a QA person or network tech try to install and run any updates from the developers while logged in as a "typical" user in your environment. If it doesn't install or doesn't work, send it back and work with the developers to come up with a solution that doesn't compromise your security.

I'm a developer, and a network admin, and network designer, and security consultant. I've had great success getting management backing to implement the above policies at my clients, regardless of company size. Generally, the most challenging users are executives/owners who are moderately technical, they often want to run as admin for convenience. Most of the time, I can convince them to be a power user (and possibly give them a separate local admin account with restricted network access).

There are challenges:
Some third party software requires operating as a local administrator. In this case, we typically set up a shortcut to run that application using "run as" using an account with local administrator privileges. With W2k/XP, there is a third party tool named TQCrunas that you can use to setup a shortcut where the shortcut is a script with an encrypted password so the user doesn't even need to know the account name or password for that local admin account.

TQCrunas can also be used to allow remote users to install their own print drivers and/or printers.

Programs that attempt to update themselves:
You can push updates via WSUS, and/or the Windows login script, and or from a script on the server, and/or use run as/tqcrunas for the installer/updater, and/or allow write permissions on that specific program directory (but not a Windows system directory), and/or install an updater service on the workstation.

I've encountered very few situations that actually require the user to run as an administrator. It's not hard to set up, but it does require some research, planning, and testing.


RE: ?
By bodar on 2/2/2009 6:22:21 PM , Rating: 2
We use a similar program from FullArmor called Intellipolicy, that is configured with AD Group Policy to promote apps to admin for any user. They discontinued the program though, because this can be done natively in Vista.


“And I don't know why [Apple is] acting like it’s superior. I don't even get it. What are they trying to say?” -- Bill Gates on the Mac ads

Related Articles
Windows 7 Beta Gets Official
January 8, 2009, 10:21 AM
Windows 7 Features Revealed
October 28, 2008, 4:50 PM













botimage
Copyright 2014 DailyTech LLC. - RSS Feed | Advertise | About Us | Ethics | FAQ | Terms, Conditions & Privacy Information | Kristopher Kubicki