The Windows Flaw That Cracks Amazon Web Services 114
Posted
by
Unknown Lamer
from the you're-doing-it-wrong dept.
from the you're-doing-it-wrong dept.
Nerval's Lobster writes "Developer and editor Jeff Cogswell decided to poke around the security of Amazon Web Services, and found a potential loophole that could theoretically allow anyone — a developer, an unscrupulous Amazon employee, the NSA — to access and copy data volumes stored on the system, using a slightly modified version of the popular 'chntwp' password tool. In this article, he breaks down how he did it, and suggests some ways for those who use cloud-hosting services to keep their data a little more secure in the future. 'The key here, of course, is that an unscrupulous employee might be able to make a copy of any existing Windows volume, and go to work on it without the customer ever knowing that it happened,' he writes. 'Now let's be clear: I'm not accusing anyone of having done this; in fact, I doubt anybody has, considering I was unable to find a working copy of chntpw until I modified it.' It's a security concern, and one that's particularly insidious to patch."
Vulnerable? (Score:5, Funny)
Re:Vulnerable? (Score:5, Insightful)
Re: (Score:2)
How does active directory prevent you from changing offline passwords for local users?
I assume this is similar to ntpasswd, which our helpdesk folks use from time to time to reset local admin passwords on machines that are connected to the domain. Why they choose to do it that way vs just resetting the password from another account I am not sure.
Re: (Score:1)
How does active directory prevent you from changing offline passwords for local users?
I assume this is similar to ntpasswd, which our helpdesk folks use from time to time to reset local admin passwords on machines that are connected to the domain. Why they choose to do it that way vs just resetting the password from another account I am not sure.
Offline machines, expired computer accounts (which require them to be offline) and to teach the user to rmemeber their password. Write it on a post it with a couple extra characters for obfuscation (e.g. password123 written as password12345) and leave that in your wallet. Is it so hard? Not NSA safe, but how often will you lose your wallet and laptop at once? Only when mugged at the airport, and that mugger isn't go to crypto-analyze your password for the extra characters before pawning it...
Re: (Score:2)
Re: (Score:1)
The program is capable reverse-wiring the local Administrator account so that active directory restrictions are bypassed. This sticks until the next domain login.
Re: (Score:1)
Yep, I've experience with chntpw, used it tons of times to recover people's Windows systems when they locked themselves out. it's pretty brutal, and bypasses most everything. I've changed one of my buddy's home network admin accounts with it remotely, just to mess with him, and he was baffled that his network could be breached so easily. And yet he still uses Windows server!
Just a note, he is extremely security minded as well (well, as security minded as you can be while still relying on Windows). He ha
Re: (Score:3)
what the fuck does any of this matter though if you have a copy(and potential to change the original as well) of the system volume?
the "newsflash" is really that hosted services are accessible to people hosting it...
Re: (Score:2)
Well the way I understand it, and for the record its been half a decade or so since i worked with AD, is that with AD there really isn't a "local password" to speak of, so there really wouldn't be any "offline password" to use.
Now that said I would NOT call this a "vulnerability" as it is there FOR A REASON and that is to allow both home users as well as SMBs that don't use AD to recover a system that has been locked and the password lost without having to do a full system wipe. You'd be surprised how often
Re: (Score:2)
and if you have access to a linux installation drive(unencrypted) then surprise surprise you can change the password to whatever you want as well..
Re: (Score:2)
Didn't say you couldn't and in fact have had long essays here about how Linux doesn't magically give you security for being FOSS and how the many eyes myth is just that.
But one advantage Linux DOES have over the legal versions of Windows is the fact you can download prebuilt images designed around all kinds of jobs including secure web servers with full disc encryption already set up and configured, you just add your own password. This is one thing that has pissed me off about MSFT for years, you get a "one
Re: (Score:2)
Too bad it applies just as equally to Linux and every other OS.
They have 'physical access' to the machine. You've lost already, regardless of OS. They don't need your passwords.
Re:Vulnerable? (Score:5, Insightful)
And this isn't even a vulnerability.
The ability to share disks by copying or moving them from one machine to another is an AWS feature.
It's common that you'd launch a high-CPU compute node (which might be windows) to prepare a set of data on a disk; and then kill that expensive high-CPU node when the data's ready; and move the disk to another machine (which might be running Linux).
Isn't that exactly what the author described?
Re: (Score:1)
The issue isn't that this is new, the issue is that this matters to certain security requirements, specifically PCI compliance.
One of the rules of the highest levels of PCI compliance level 1 is that any access to Card Holder Data be logged. If you can make these copies and access the data out of system, then your system can not be PCI compliant.
This means any company storing CC info on a cloud instance is now Ipso facto not compliant.
This has huge implications, even if it's been a well known quality for
Re: (Score:1)
Re: (Score:1)
Sounds like something Windows XP was explicitly designed for.
Re: (Score:2)
You lost me at http://slashdot.org/topic/bi [slashdot.org]
Dear Slashdot, stop creating your own content. You suck at it.
And security goes on (Score:4, Funny)
Cloud=magic (Score:2)
No, really, if you ignore all the practical problems with hosting data by letting someone else do it, those practical problems disappear. It's magic!
Re: (Score:2)
No, really, if you ignore all the practical problems with hosting data by letting someone else do it, those practical problems disappear. It's magic!
Sounds suspiciously socialist
Comrade!
Re: (Score:3)
Only a commie-mutant-traitor would know a word like "comerade". What's your clearance citizen?
Windows volumes... (Score:1)
Don't use them, problem solved. Better even, don't use windows at all, more problems solved.
Re:Windows volumes... (Score:5, Informative)
Too bad the author of TFA is a flaming idiot, and this has nothing to do with Windows at all. It's a total non-story.
He just "discovered" that if you download a cloud machine disk volume - which is completely OS-agnostic, you could do it BeOS if you wanted to - you can mount it on your own machine and go to town on the data. Unix-like OS? Cool, go read /etc/shadow and get the password hashes (or change/add your own password and re-mount it, as he suggests doing with Windows). There's absolutely nothing here Windows-specific at all except that the idiot only *just* discovered that password resetting by modifying the user login data is possible.
This just in (Score:5, Informative)
People with access to your data are able to access your data.
Re: (Score:2)
Re:This just in (Score:4, Funny)
Including you!
I consider that a major security hole that needs to be fixed!
So stupid. (Score:5, Insightful)
If you mount your Windows harddrive in Linux without using Encryption you can access all your Data?
Not news at all. You can do this on any operating system of any type assuming your not using an encrypted system.
Re:So stupid. (Score:5, Insightful)
If you mount your Windows harddrive in Linux without using Encryption you can access all your Data?
Not news at all. You can do this on any operating system of any type assuming your not using an encrypted system.
Or dupe your Linux virtual harddrive in Linux... or Windows ... or OSX... and do the same thing.
Its a stupid flamebait article. Shame after all this time we still can't moderate the articles themselves on /.
Not actually a problem with AWS. (Score:5, Informative)
Re: (Score:3)
To be fair no different than changing the password on a linux machine by booting a linux live cd either.
Yeah, does not look like anything really surprising to me either.
Re: (Score:2)
or make a copy and then brute force the password.
Not a new problem (Score:5, Insightful)
Re: (Score:3)
Not sure what the surprise here is. I had a Server 2003 guest go nuts on my KVM server and become pretty much unbootable. I mounted the raw image file via loop back and ntfs3g and happily copied all the data off of the virtual hd. I've done the same thing with Linux and BSD raw images, partitions and physical drives.
If I wanted real security I would use disk encryption like TrueCrypt on the vm volume, so that even if someone could gain access to the VM host, they would be confronted with an encrypted volume
Why make it complicated? (Score:5, Insightful)
If you can do this, the system is already compromised in a dozen different, less-interesting, ways.
The question is whether you can do this without already having the passwords, with EC2's existing security. I see no evidence from the article he can.
Without that, the claim is half gratuitous cleverness, half FUD of an attention-grabbing vendor name, to my eyes.
Re: (Score:1)
You looked at the linked article: it's a "slashdot bi" article. Dice, WTF? Get your act together. It's more like "slashdot b(usiness) s(tupidity)" or just bullshit.
Re: (Score:1)
Keep in mind that the claim is that an AWS employee is the one who can access your Windows volume (or any other unencrypted volume for that matter) without your knowledge. He is NOT talking about somebody from outside accessing your volumes.
dom
Re: (Score:2)
Keep in mind that the claim is that an AWS employee is the one who can access your Windows volume (or any other unencrypted volume for that matter) without your knowledge. He is NOT talking about somebody from outside accessing your volumes.
dom
But there's no reason to make that claim - since it's well known that anyone with access to your unencrypted data has access to your data -- in a locally hosted machine, that means everyone that could pull a drive and make a copy of it. In a cloud environment, that means everyone that has access to your unencrypted volumes.
That's not news, it's common sense.
Re: (Score:2)
Still, since I have been a customer of Amazon EC2 for several years and know something about it, and have had such security discussions
Use TrueCrypt (Score:3, Interesting)
Going to need a copy of the VM's memory and some skill at finding the crypto keys in there in addition to the volume if you use TrueCrypt.
I use AWS and I truecrypt my source code database that I store there.
I lose automatic full reboot (I have to log in and manually mount that volume), but that's worth the additional privacy/security.
Re: (Score:2)
Or use native Bitlocker encryption, the only wrinkle there is without TPM you'd need to enter your password at boot time and AFAIK AWS doesn't give you a console session to do that. TrueCrypt would have the same problem with if you wanted to encrypt the boot volume.
Re: (Score:2)
If AWS gave you a console session, I'm presuming someone (like, say, the NSA) already has a backdoor and can happily grab your password.
Re: (Score:1)
There's no passwords on my AWS linux VM. All the accounts (root and my own) are passwordless, no password works. You have to have the ssh key to log in. So even if some joker had console on my VM, it's rather worthless. *I* can't even login if I had console.
And na, who cares about crypting the boot volume.. its just a linux distro, nothing sensitive there. Only crypt sensitive volumes. (like /home for example)
I'm not fond of any solution that is 'automatic', cuz if it's automatically set to decrypt my
Re: (Score:2)
A slightly better option would be to use Encrypting File System (EFS) plus a *really* strong password (something you can't break with a rainbow table, since they can dump the password hashes). That doesn't require any boot-time stuff, and if the attacker resets the accounts password, all those files are gone forever (unless you can crack AES).
Of course, a clever attacker could instead insert spyware that catches the login credentials and/or the decrypted files and sends you those instead, at which point you
Re: (Score:2)
Going to need a copy of the VM's memory and some skill at finding the crypto keys in there in addition to the volume if you use TrueCrypt.
If the key was ever written to your hard drive, the fine folks at Elcomsoft will find it for you
http://www.elcomsoft.com/efdd.html [elcomsoft.com]
Re: (Score:2)
It's not. On Linux/BSD/whatever I'd just go hit /etc/shadow for the equivalent of the Windows SAM; it's easier to get at, in fact. This whole "article" is bullshit aside from providing yet more evidence that "the cloud" is a bad idea for anything sensitive.
Mr Mackey says (Score:1)
Cloud is bad.
Don't do cloud.
New definition of "Accessibility" (Score:5, Interesting)
Re: (Score:2)
Does using Explorer.exe instead of command.exe log get you in with a full shell and start menu?
Re: (Score:2)
Re: (Score:2)
Why are you asking me?
Because you may have tried it before. You had started the online discussion on the topic.
I don't think any app requires authentication, but a lot require HKEY_CURRENT_USER - which isn't populated until you actually log in. So maybe this is what prevents explorer.exe from bringing up a full shell. I don't know. Thought maybe you had tried it.
Re: (Score:1)
You do realize that when you started copying files around on the volume that you already have full access right?
Why would you bother with replacing magnify.exe when when you have complete access to the system without needing any passwords at all?
When someone has direct physical access to your 'hardware' (virtual or otherwise), you can't stop them from getting at it.
Doesn't matter if its a machine at your colocation datacenter or a VM 'in the cloud'.
Re: (Score:2)
He did not 'miss the point', because you have no point. All you did was show that if you have unrestricted access to a disk you can make a system insecure. Well no shit Sherlock. You can do that on ANY OS. If you want to do it on a Unix system replace getty or xdm with a version that has a backdoor in it.
There is nothing special about what you did, and it is not a vulnerability, and there is nothing to 'get smart' about.
Re: (Score:1)
Re: (Score:2)
Nowhere did I say those were the same things. All you did was take the system down, install a vulnerability, and bring the system back up. No magic. Of course you now have full access to the running system, but the ONLY reason you have that is because FIRST you had full access to the disk, and YOU created a vulnerability.
And again, you can do that on ANY OS. Take down Linux, replace (for example) /etc/init.d/firstboot (or any other automatically started service) with a simple script that starts vncserv
Re: (Score:1)
No shit Sherlock. The alternative is you have access to the data, but can't bring the system back up and log in. Once you can do that a whole new world of opportunities become available that were not readily available previously. For example, before I did "all I did" I couldn't log in a user "Joe" and access his bank account over the internet, for example. The OP d
Re: (Score:2)
Yes. It is exactly like having legs. You can get around in a wheelchair and do everything you do every day; legs are merely a matter of convenience.
Re: (Score:1)
Re: (Score:2)
You do realize that when you started copying files around on the volume that you already have full access right?
Most people who think they've found some sort of vulnerability in systems seem to lack an understanding of security barriers and what it means when you're on one side of one or the other.
Can't tell you how many times I've seen people start a security report of a vulnerability in one application or another with "if the user is root / administrator or can use an root / administrator exploit of some kind"... and completely missing the fact that the vulnerability doesn't matter one bit if that's the case.
Mod up, please (Score:2)
Too true. Sadly, most people - even on /. these days, it seems - don't know a damn thing about OS security. If the idiot of an article author had pulled a Linux volume and gone fucking about in /etc/shadow to do exactly the same thing, though, then it wouldn't have appealed to the general /. groupthink nearly so well...
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
That is not correct. When you add the drive to a system you already have administrator access to, then you can change data on the drive. You cannot, however, easily make modifications to SQL Server setups, password information, etc. for example. Once you replace Magnify.exe and then power down and change the setup so that it boots of the modified drive you have admin access to the ru
Re: (Score:1)
You cannot, however, easily make modifications to SQL Server setups, password information, etc. for example.
Umm, yes, you can. Just because you don't know how to do so (or don't have the toolset to do so) does not make your statement true. With access to the hard drive, it's trivial to reconfigure windows for autologin as the local Administrator account for example (this is actually true of any OS). You also can extract any domain account credentials for which services have been configured to run as, just from the HDD.
Re: (Score:1)
Re: (Score:2)
Everybody understands your intent. Nobody understands why you think there is anything special about what you did, or why you think it is some sort of vulnerability. It is obvious to EVERYONE that an administrator (which you were as soon as you mounted the disk on your own system) can do ANYTHING, including making the system vulnerable.
Re: (Score:1)
Earth-shattering (Score:4, Insightful)
Re: (Score:1)
About Jeff (Score:2)
Good job, Jeff! Welcome to
Re: (Score:2)
Yes, but did he try JavaScript?
Re:About Jeff (Score:4, Insightful)
Really? You "enjoyed" a reading the "discoveries" of somebody who didn't even realize that psexec requires Admin, at which point the whole thing is completely moot? You want to know how else I can replace the password on the Administrator account? Computer Management (mmc.exe, as Admin please), Local Users and Groups, Users, Administrator, right-click, Reset password.
But that doesn't let him talk about how 1337 he is for tweaking an outdated program to work on a modern Windows version... Seriously, the guy is a bit of an idiot. Calling it a Windows vuln was icing on the cake; if anything, this kind of "exploit" is actually easier on Linux.
There's "out-of-the-box thinking and problem solving" and then there's "I don't know what the fuck I'm talking about but have you heard of this cool program that lets you totally break Windows security guys?!?" I hang out a lot in the security community, and I see this sort of shit all the time. I've never seen anybody who started out spewing this kind of idiocy ever actually amount to anything even years later, though. They never actually learn. That garbage he posted in the article? that's probably as smart as he will ever get with regard to security, because he doesn't even understand the basic concept of what user accounts or access permissions *are*. Not doesn't understand them - hell, at least on Windows, that's hardly anything unusual - he doesn't even know what they are. For example, you can access the SAM just fine without using SYSTEM at all; just use Admin privileges to modify the ACLs on the SAM registry key. He's not even aware that there *are* such things as ACLs; he just thinks it's "magic" that SYSTEM can do some things that everybody else (because he runs as Admin, because he doesn't have any idea why you wouldn't) can't do.
Re: (Score:1)
Yes, I did enjoy it. So you didn't. To each his own.
p.s. Vitriol is no way to go through life, son.
Re: (Score:2)
Eh... developers who are semi-aware of security are the kind of people who write the most insecure code, in my (professional) opinion and experience. Well, second most insecure I guess, the ones who copy-paste something off the web are worse. But at least their bugs are easy to spot. The people who are semi-aware of security are the ones who do things like TLS with certificate validation turned off (because it's still encrypted, right?) or store salted and hashed passwords (possibly even using a decent key
Uhhh, sure, nice Cloud FUD (Score:2)
Newsflash: If you run servers in Amazon's cloud, you have to trust Amazon.
There's no flaw in AWS that enables this hack by untrusted parties. You have to have access to the AWS account in order to clone a volume, just like you'd have to have physical access to a physical server to clone a volume.
The only interesting point here is that an Amazon employee could do this without you knowing it. But come on, how obvious is that? Their sysadmins could do a lot more than just clone your hard drive and change the p
News flash (Score:2)
Attacker with full access to an unencrypted system volume has full access to the data stored on it.
Fail article... (Score:2)
The commentary on resetting passwords in windows is useful/interesting, but this article really doesn't have any special relevance the cloud. Whether or not the storage is a local physical volume or "floating around on dem internets" doesn't make a difference.
This is simply risible. (Score:1)
Wow, you mean if someone can get a copy of your unencrypted hard drive they can get your data? And this even includes _system administrators_ (who can get your data anyway)?
What in the world is this person going on about, and why is this posted as an article? It's infantile.
Why is this news? (Score:2)