Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Security

The Windows Flaw That Cracks Amazon Web Services 114

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."
This discussion has been archived. No new comments can be posted.

The Windows Flaw That Cracks Amazon Web Services

Comments Filter:
  • Vulnerable? (Score:5, Funny)

    by cyberpocalypse ( 2845685 ) on Wednesday September 11, 2013 @01:08PM (#44821317)
    You had me at Windows
    • Re:Vulnerable? (Score:5, Insightful)

      by chuckinator ( 2409512 ) on Wednesday September 11, 2013 @01:18PM (#44821429)
      chntpw has been in the wild since 1997. It's wonderful that the researcher just realized that it works on cloud volumes just as well as physical volumes, but this it flat out not news. It's also mitigated by deploying an Active Directory domain controller if you want to stick with windows or rolling one yourself with krb5/ldap/samba/etc. if you want your backend servers running unix of whatever variant you like.
      • by h4rr4r ( 612664 )

        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.

        • by Anonymous Coward

          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...

        • Active directory (or some alternative) will allow you to assign admin rights to a domain user and disable local user accounts.
          • by Anonymous Coward

            The program is capable reverse-wiring the local Administrator account so that active directory restrictions are bypassed. This sticks until the next domain login.

            • by Anonymous Coward

              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

          • by gl4ss ( 559668 )

            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...

        • Comment removed based on user account deletion
    • 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)

      by ron_ivi ( 607351 ) <sdotno@NOSpAM.cheapcomplexdevices.com> on Wednesday September 11, 2013 @01:40PM (#44821671)

      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?

      • by Anonymous Coward

        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

        • by Gr8Apes ( 679165 )
          If you're storing PCI data on anything but a highly controlled hardware in a secure network, you will not be PCI compliant. I personally don't even want to process PCI data, preferring to offload that onto systems explicitly configured for that task.
    • by spatley ( 191233 )

      You lost me at http://slashdot.org/topic/bi [slashdot.org]
      Dear Slashdot, stop creating your own content. You suck at it.

  • by minstrelmike ( 1602771 ) on Wednesday September 11, 2013 @01:08PM (#44821319)
    The cloud just gets more and more secure all the time. Maybe this is how Dilbert broke into the NSA servers and got all his company's data back.
  • 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!

    • by ackthpt ( 218170 )

      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!

  • by Anonymous Coward

    Don't use them, problem solved. Better even, don't use windows at all, more problems solved.

  • This just in (Score:5, Informative)

    by Anonymous Coward on Wednesday September 11, 2013 @01:12PM (#44821353)

    People with access to your data are able to access your data.

  • So stupid. (Score:5, Insightful)

    by MindStalker ( 22827 ) <mindstalker AT gmail DOT com> on Wednesday September 11, 2013 @01:12PM (#44821357) Journal

    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)

      by tgd ( 2822 ) on Wednesday September 11, 2013 @01:50PM (#44821753)

      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 /.

  • by solafide ( 845228 ) on Wednesday September 11, 2013 @01:13PM (#44821369) Homepage
    This is no different than booting a LiveCD and changing the Windows password from a Linux LiveCD running with access to the same storage device. This is not a flaw in AWS in any fashion, other than illustrating the trust you place in AWS having access to your physical devices. Why is this news? This is a standard if-you-have-access-to-hardware-you-can-have-complete-control-over-everything-on-it-not-encrypted problem.
    • by h4rr4r ( 612664 )

      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.

  • Not a new problem (Score:5, Insightful)

    by Imagix ( 695350 ) on Wednesday September 11, 2013 @01:15PM (#44821389)
    Oh look, it's yet another case of "If you have physical access to the server, all bets are off.". If you can clone the volume, you effectively have physical access to the server. This isn't a new vulnerability. Just another case of "It's on the webz, it must a a completely novel thing!".
    • 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

  • by Empiric ( 675968 ) on Wednesday September 11, 2013 @01:16PM (#44821407)
    1. Take a Windows server on Amazon Web Services, make a copy of the hard drive (which Amazon calls a volume),

    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.
    • by Anonymous Coward

      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.

    • by Anonymous Coward

      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

      • by hawguy ( 1600213 )

        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.

      • by Empiric ( 675968 )
        If the overall point is that an employee of a company that has complete access to your systems, has complete access to your systems, that hardly seems to rise to the specificness of the claim "The Windows Flaw That Cracks Amazon Services". The supposed Windows flaw is irrelevant to the fact all systems are equally vulnerable in such a context, by much more mundane means.

        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)

    by duke_cheetah2003 ( 862933 ) on Wednesday September 11, 2013 @01:19PM (#44821439) Homepage

    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.

    • by afidel ( 530433 )

      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.

      • 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.

        • 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

      • 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

    • 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]

  • by Anonymous Coward

    Cloud is bad.
    Don't do cloud.

  • by Zero__Kelvin ( 151819 ) on Wednesday September 11, 2013 @01:28PM (#44821517) Homepage
    This can all be done simply without Linux using Windows and without chntpw. Simply add the drive to a system you own, move Magnify.exe out of the way (for later restoration), and copy command.exe to Magnify.exe then boot of the modified drive and choose to use the "Accessibility Tool". Instant command shell with full priveledge escalation. I have personally done this on Windows Server 2008. I do not know if they finally got smart and added code to prevent this in Server 2012, but I wouldn't be surprised if it works on every version of Windows that has the "Accessibility Options" on the login screen.
    • Does using Explorer.exe instead of command.exe log get you in with a full shell and start menu?

      • Why are you asking me? I doubt it, though. When you open a shell I don't believe that you authenticate (or it wouldn't work, sans password) The shell assumes you already have if I'm not mistaken.
        • 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.

    • 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'.

      • by tgd ( 2822 )

        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.

        • 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...

    • I don't know if you're trying to be funny by illustrating a needlessly convoluted process,, but in case you're serious, you already won at this step: "Simply add the drive to a system you own," and the rest was just wasting your time.
      • Please read my other posts in this thread. I'm already sick of explaining the obvious to people who haven't thought their comments through.
    • You need Administrator access to replace magnify.exe. If you have Administrator access, you don't need to replace magnify.exe, you already can do anything you want directly. "It rather involved being on the other side of this airtight hatchway." [google.com]
      • " If you have Administrator access, you don't need to replace magnify.exe, you already can do anything you want directly."

        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

        • by Anonymous Coward

          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.

          • It is easy to do everything if you have the tools to do it, the knowledge of how to do it, the time to do it, etc. I have yet to hear any solution that is easier than the one I used though. You certainly haven't offered one yet. At least you are conceding my point that access to data and access to a running system are two different things though. That seems to be a particularly difficult concept for a lot of people to grasp :-(
            • by bws111 ( 1216812 )

              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.

              • Did you read the friggin article? Guy says Hey, look what I can do with Linux and a modified chntpw! Now go back and read my initial post. I accept your apology.
  • Earth-shattering (Score:4, Insightful)

    by davidbrit2 ( 775091 ) on Wednesday September 11, 2013 @01:38PM (#44821647) Homepage
    Unencrypted volumes can be easily modified when mounted on a different system; film at 11.
    • Yeah, I'm amazed this junk article is somehow being posted to Slashdot's front page. It's a joke to anyone even casually familiar with, well, computers at all.
  • Jeff Cogswell is the author of several tech books including “C++ All-In-One Desk Reference For Dummies,” “C++ Cookbook,” and “Designing Highly Useable Software.” A software engineer for over 20 years, Jeff has written extensively on many different development topics. An expert in C++ and JavaScript, he has experience starting from low-level C development on Linux, up through modern Web development in JavaScript and jQuery, PHP, and ASP.NET MVC.

    Good job, Jeff! Welcome to

    • Yes, but did he try JavaScript?

    • Re:About Jeff (Score:4, Insightful)

      by cbhacking ( 979169 ) <been_out_cruisin ... nospAM.yahoo.com> on Wednesday September 11, 2013 @02:27PM (#44822211) Homepage Journal

      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.

      • I did say his research skills could use some polish. And I figure one more developer that is at least semi-aware of security is a good thing. Many don't even consider the security implications of what they write.

        Yes, I did enjoy it. So you didn't. To each his own.

        p.s. Vitriol is no way to go through life, son.
        • 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

  • 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

  • Attacker with full access to an unencrypted system volume has full access to the data stored on it.

  • 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.

  • 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.

  • Any why does it specifically call out AWS? There would be the same vulnerability with any hosting service where someone other than you has access to the hardware. Rule #1 of system security has been all bets are off if someone has physical access to the system for quite a while.

A committee takes root and grows, it flowers, wilts and dies, scattering the seed from which other committees will bloom. -- Parkinson

Working...