Gaining System-Level Access To Vista
An anonymous reader writes "This video shows a method by which a user can use a Linux distro called BackTrack to gain system access to Windows Vista without logging into Windows or knowing the username or password for any accounts. To accomplish this, the user renames cmd.exe to Utilman.exe — this is the program that brings up the Accessibility options for users without sight or with limited vision. The attack takes advantage of the fact that the Utility Manager can be invoked before the user logs into the system. The user gains System access, which is a level higher than Administrator. The person who discovered this security hole claims that XP, 2000, 2003 and NT are not vulnerable to it; only Windows Vista is."
Light travels faster than sound. This is why some people appear bright until you hear them speak.........
No kidding. I once "hacked" into a Linux machine that had an unknown root password by booting off a live CD, sudo bashing to become root, and then it's just mount, chroot and passwd to reset the root password. (I could have also manually edited /etc/shadow but this was easier.)
Linux is horribly insecure! I was able to reset the root password with just a live CD and complete access to the machine!
Now of course if the hard drive had been encrypted, this "attack" wouldn't have worked. (Although in this case at least, a different attack would have worked: reinstalling the OS. Resetting the root password was faster. The data on the machine wasn't important. We just needed a working Linux installation with a known root password.)
You are in a maze of twisty little relative jumps, all alike.
You're not very good at puzzles, are you? First you get one piece, here it is the ability rename an executable to execute a privilege escalation. The next piece is for anybody to find... a way to remotely rename an executable while it is being used, or during reboot, or something else more clever than one minute of my thinking during this reply.
Your questioning follows the "who cares if water expands when it freezes?" line of thinking. You're missing the second part, the idea that you have to pour it into something before it freezes in order to break that something without effort.
And what do you suppose is going to stop the attacker from overwriting whatever program performs this validation, absent full-disk encryption coupled with a hardware security module? (And even then, what if they take a soldering iron to the TPM?)
Face it, if an attacker already has physical access to a system -- to the extent that he can run his own Linux OS on it and mess with the contents of its disks -- then that computer is already, entirely owned. This is true for Linux, it's true for OS X, it's true for BSD, and it's true for Windows. That's just the way computers work.
The only iceberg here is the massive crashing reality that a physically unsecured computer system is, well, insecure. Surprise.
One is, of course, because it's Windows and Slashdot has this pathological need to post anything and everything they can find that makes Windows look bad, even if it is completely made up/false.
However the other is that it seems that many geeks misunderstand security. They think that perfect security is something you can actually have, that a system can actually be invulnerable from attack. So any attack is news in their minds since they've never thought it through. This is quite evident from the comments any time a site gets hacked and there is the attitude of "It is your fault if you are stupid enough to get hacked." I always like to ask if they'd take the same view if I broke in to their house, which would be extremely easy (almost nobody has good home security).
As you noted: When there's physical access to the system, all bets are off. Any OS level security isn't any good since the drive can just be removed and accessed directly. Heck, that's how we do data recovery at work. We don't even try to figure out if the problem is OS configuration or an actual disk error. The disk comes out, goes in to our recover system, and we get the necessary data off. Data first, diagnosis later. Once the data is safely off, then I worry about what actually went wrong.
All security is just a matter of trying to be secure enough that anyone who wants at what you are securing can't or won't spend the effort to defeat it. There's no perfection. Even something like full disk encryption. Yes, this will defeat something like this, and also defeat someone grabbing the drive and reading it. However if they really want it, they just grab you too and force you to hand over your password. If the data was important enough that you had to plan for that contingency, you get some body guards to keep you safe. However then they simply kill your guards and get you... etc.
Basically there isn't a be-all, end-all of security, where you are safe against everything. There is only being secure to the point that anyone who wants what you have, doesn't have the ability to get it.
That's not the point
Linux doesn't try to be secure against physical access, just add init=/bin/sh to the kernel command line.
OTOH: Windows has always had this weird naivety that passwords will protect the OS from the guy sitting infront of the PC.
Nope. Know how most worms don't actually care about the data on the machine? They just want enough control to make the machine join a bot-net and start spamming.
In this scenario I don't care about the data on the machine. All I want to do is run programs on the machine. Sadly, the OS is password protected and I don't know the password. So I can't run programs. But if I were to replace the existing OS with a new one that I do have access to, I've done a successful attack: I now have the access I desired. I've started with no access and ended with full access.
Yes, all encrypted data would remain unknown. But for this "attack" I don't actually care about the data. I just want to be able to run programs on the machine. (Specifically in this case, it was a lab machine that had been moved from one project to another. Whoever originally set up the machine either couldn't be contacted or had forgotten the password, I don't remember which. There's no useful data on the machine, but the machine is still useful - if only we could access it.)
The entire point is that this is a somewhat lame attack - just like the attack in the article. It starts by assuming you manage to gain full read/write access to the drive. Amazingly enough, if you have full read/write access, gaining root access isn't terribly difficult...
You are in a maze of twisty little relative jumps, all alike.
Consider: someone arrives from 10 years in the future in a time machine. OK, at the time he arrives this is news. However, at the point the individual leaves to go back in time, we have already known about this for 10 years. He may even be reusing the same time machine, if it was never used in the intervening period. How is a 10 year old story news (I am ignoring /. for the purpose of this argument)?
Also with physical access you can backdoor the FDE bootloader, which is of course not encrypted. That may be easier than backdooring the firmware.
That's how all hardware monitoring and similar tools do, to avoid triggering false alarams in UAC.
It's just strange how Windows can't even follow their own recommendations.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Looks alot like this:
http://www.avertlabs.com/research/blog/index.php/2007/03/12/windows-vista-vulnerable-to-stickykeys-backdoor/
Only thing new is using Linux to rename the file.