Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The Windows Flaw That Cracks Amazon Web Services

Unknown Lamer posted about 10 months ago | from the you're-doing-it-wrong dept.

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

cancel ×

114 comments

Vulnerable? (5, Funny)

cyberpocalypse (2845685) | about 10 months ago | (#44821317)

You had me at Windows

Re:Vulnerable? (5, Insightful)

chuckinator (2409512) | about 10 months ago | (#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.

Re:Vulnerable? (1)

h4rr4r (612664) | about 10 months ago | (#44821547)

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:Vulnerable? (1)

Anonymous Coward | about 10 months ago | (#44821877)

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:Vulnerable? (1)

chuckinator (2409512) | about 10 months ago | (#44821899)

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

Re:Vulnerable? (1)

Anonymous Coward | about 10 months ago | (#44822025)

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:Vulnerable? (1)

Anonymous Coward | about 10 months ago | (#44825677)

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 has designed networks for a living for a long time, and consulted on many massive enterprise networks. He has no idea how to mitigate this, and is still vulnerable, just as all Windows systems are.

Re:Vulnerable? (2)

gl4ss (559668) | about 10 months ago | (#44823305)

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:Vulnerable? (1)

hairyfeet (841228) | about 10 months ago | (#44824377)

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 this is a real problem in the field and without this all those folks would lose all their data. I had a case not too long ago where a little old lady volunteer at one of the local churches saw a broadcast about how "complex passwords protect systems" and promptly changed the password on the main system and forgot what she changed it to, since they had never come to me they had NO backups and a good 4 years worth of data, a real nightmare if I wouldn't had been able to reset the password thanks to chntpw.

The moral of the story IMHO would be don't use an OS not made for the cloud IN the cloud. Anyone who has followed my postings knows I'm a BIG believer in "right tool for the job" and in the case of the cloud Windows Server, BSD or Linux should be used, you shouldn't be using Windows Home and Pro as a cloud based OS in the first place. And if you use the cloud for backups? Encrypt the backup. I personally use and recommend the Paragon backup products, they support AES encryption as well as image splitting, which would probably be handy if you are doing cloud based backups.

Re:Vulnerable? (2)

BitZtream (692029) | about 10 months ago | (#44821623)

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? (4, Insightful)

ron_ivi (607351) | about 10 months ago | (#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?

Re:Vulnerable? (1)

Anonymous Coward | about 10 months ago | (#44823377)

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

Re:Vulnerable? (1)

Gr8Apes (679165) | about 10 months ago | (#44824569)

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.

You've had me with Linux/ANDROID (0)

Anonymous Coward | about 10 months ago | (#44821815)

For years via Swiss-cheese Java/Dalvik front ends & infected faster than Win9x was in the same timeframe. So much for Linux security. Wait until you find out what I already know: SeLinux is NOT your friend (courtesy of the NSA).

Re:You've had me with Linux/ANDROID (0)

Anonymous Coward | about 10 months ago | (#44824541)

Right, because malware on Android can actually do anything without root access. And if you've rooted your phone, you either know damn well not to install random shit or are a fucking moron who shouldn't be allowed within 100 meters of technological devices in the first place.

Argue with the numbers (0)

Anonymous Coward | about 10 months ago | (#44825149)

I've seen the 100's of news articles involving ANDROID exploited, 1 way or another, faster than Windows 9x was in the same timeframe. Wait till you find out how "NSA Secure" SeLinux really is too (soon enough).

Re:Vulnerable? (1)

spatley (191233) | about 10 months ago | (#44822483)

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 (3, Funny)

minstrelmike (1602771) | about 10 months ago | (#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.

Cloud=magic (1)

i kan reed (749298) | about 10 months ago | (#44821321)

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:Cloud=magic (1)

ackthpt (218170) | about 10 months ago | (#44821751)

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:Cloud=magic (2)

i kan reed (749298) | about 10 months ago | (#44821885)

Only a commie-mutant-traitor would know a word like "comerade". What's your clearance citizen?

Windows volumes... (1)

Anonymous Coward | about 10 months ago | (#44821339)

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

Re:Windows volumes... (0)

Anonymous Coward | about 10 months ago | (#44821531)

but it's so easy to use, no wonder it's number 1!!1

Re:Windows volumes... (5, Informative)

cbhacking (979169) | about 10 months ago | (#44821945)

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 (5, Informative)

Anonymous Coward | about 10 months ago | (#44821353)

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

Re:This just in (1)

0racle (667029) | about 10 months ago | (#44821549)

Including you!

Re:This just in (3, Funny)

Cro Magnon (467622) | about 10 months ago | (#44821791)

Including you!

I consider that a major security hole that needs to be fixed!

Re:This just in (0)

Anonymous Coward | about 10 months ago | (#44822205)

/dev/nul is uncrackable.
And has all the space you'll ever need.

Re:This just in (0)

Anonymous Coward | about 10 months ago | (#44822393)

Simple - Don't be a lemming and head for the cloud.

first (-1)

Anonymous Coward | about 10 months ago | (#44821355)

first

So stupid. (4, Insightful)

MindStalker (22827) | about 10 months ago | (#44821357)

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. (4, Insightful)

tgd (2822) | about 10 months ago | (#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 /.

Not actually a problem with AWS. (5, Informative)

solafide (845228) | about 10 months ago | (#44821369)

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.

Re:Not actually a problem with AWS. (2)

h4rr4r (612664) | about 10 months ago | (#44821567)

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:Not actually a problem with AWS. (0)

Anonymous Coward | about 10 months ago | (#44821701)

You can also have control over it even if it is encrypted, you just need to be able to intercept the password.

Re:Not actually a problem with AWS. (1)

Sir_Sri (199544) | about 10 months ago | (#44821955)

or make a copy and then brute force the password.

How is this different from (0)

Anonymous Coward | about 10 months ago | (#44821377)

The janitor at your company comes late night to clean. Using some bootcd copies the volume and takes it home and does the same thing. I am sure offline volume cracking can be done for all oses even linux and os x

Not a new problem (4, Insightful)

Imagix (695350) | about 10 months ago | (#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!".

Re:Not a new problem (2)

MightyMartian (840721) | about 10 months ago | (#44821893)

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, and without the pass code or key, they're hooped. Mind you, because I'm using some cloud service, if they are nefarious (or the NSA has backdoor access), they've already got my key and/or password, in which case whether or not the volume on the cloud VM is encrypted or not, they've been happily vacuuming up my data anyways.

The moral here is that unless you have custody of your data, you ought to presume the worst.

Jeff Cogswell - Editor... (0)

Anonymous Coward | about 10 months ago | (#44821403)

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

Cause he's the only one who can edit code or what?

Oh, wait... Is that what he means when he says he's an editor?

Why make it complicated? (4, Insightful)

Empiric (675968) | about 10 months ago | (#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.

Re:Why make it complicated? (1)

Anonymous Coward | about 10 months ago | (#44821607)

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:Why make it complicated? (1)

Anonymous Coward | about 10 months ago | (#44821631)

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:Why make it complicated? (1)

hawguy (1600213) | about 10 months ago | (#44822007)

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:Why make it complicated? (1)

Empiric (675968) | about 10 months ago | (#44822079)

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 with my clients' CEO in originally selecting them--the article, to address its claims credibly, should at least address the actual security context as Amazon asserts it is, say, here:

http://awsmedia.s3.amazonaws.com/pdf/AWS_Security_Whitepaper.pdf [amazonaws.com]

Amazon Corporate Segregation
Logically,the AWS Production network is segregated from the Amazon Corporate network by means of a complex set of network security segregation devices. AWS developers and administrators on the corporate network who need to access AWS cloud components in order to maintain them must explicitly request access through the AWS ticketing system. All requests are reviewed and approved by the applicable service owner. Approved AWS personnel then connect to the AWS network through a bastion host that restricts access to network devices and other cloud components, logging all activity for security review. Access to bastion hosts require SSH public- key authentication for all user accounts on the host. For more information on AWS developer and administrator logical access,see AWS Access below.

AWS Access
AWS developers and administrators on the Amazon Corporate network who need to access AWS cloud components must explicitly request access through the AWS ticketing system. All requests are reviewed and approved by the appropriate owner or manager.

Account Review and Audit
Accounts are reviewed every 90 days; explicit re-approval is required or access to the resource is automatically revoked. Access is also automatically revoked when an employee's record is terminated in Amazon's Human Resources system. Windows and UNIX accounts are disabled and Amazon's permission management system removes the user from all systems. Requests for changes in access are captured in the Amazon permissions management tool audit log. When changes in an employee's job function occur, continued access must be explicitly approved to the resource or it will be automatically revoked.


Certainly, this claim could be contended with or otherwise discussed as to the degree of risk posed by the "crack". Handwaving "an Amazon employee could" is rather... light, though.

Use TrueCrypt (3, Interesting)

duke_cheetah2003 (862933) | about 10 months ago | (#44821439)

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:Use TrueCrypt (1)

afidel (530433) | about 10 months ago | (#44821583)

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:Use TrueCrypt (1)

MightyMartian (840721) | about 10 months ago | (#44821901)

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:Use TrueCrypt (1)

duke_cheetah2003 (862933) | about 10 months ago | (#44824007)

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 volumes, then its a lot easier to tinker with and eventually break in. If you only have ONE CHANCE, and if the VM reboots the keys are gone until I put them back in...yeah. Not getting in to that easily.

Re:Use TrueCrypt (1)

cbhacking (979169) | about 10 months ago | (#44822017)

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 are, once again, fucked.

Oh, and none of this is Windows-specific in the lest except for the specific tool this idiot (or, perhaps, "tool") used.

Re:Use TrueCrypt (0)

Anonymous Coward | about 10 months ago | (#44821971)

I have to log in and manually mount that volume

Soooooo.... if someone uses this technique and, instead of modifying a password file, replaces sshd (or bash or the truecrypt binary or...) on your unencrypted volume with a version that logs your keystrokes, they just have to wait for you to log in and mount the truecrypted volume, and then they have your password and therefore everything in your database, right? The point you should be getting from this article is that no cloud-hosted system can be trusted because other people have physical access to the machine.

I'm not saying you have been or will be hacked, but the only protection you've gained is against people who only have read access to your VMs (which, to be fair, is still pretty good protection). Anyone with write access (and the time and knowledge and desire...) can get at your data.

And Slashdot has become clickbait... (0)

Anonymous Coward | about 10 months ago | (#44821443)

Seriously? If you have the drive or an image thereof of ANY computer/computing device out there, consider your data compromised. Most things don't encrypt by default (thankfully, as it makes disaster recovery near impossible), and those that do have a stupidly weak 4 digit PIN number and not a password.

Windows flaw? (0)

Anonymous Coward | about 10 months ago | (#44821477)

How is that in any way specific to Windows? I'd say Windows actually makes it a lot more painful (but not more difficult) whereas against Linux it's just straightfoward. As other mentioned, having raw access to a volume is just the same as physical access. The evil Amazon employee has just as much power over your systems as the tech at your local datacenter.

Re:Windows flaw? (1)

cbhacking (979169) | about 10 months ago | (#44822033)

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 (1)

Anonymous Coward | about 10 months ago | (#44821503)

Cloud is bad.
Don't do cloud.

New definition of "Accessibility" (4, Interesting)

Zero__Kelvin (151819) | about 10 months ago | (#44821517)

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.

Re:New definition of "Accessibility" (1)

omnichad (1198475) | about 10 months ago | (#44821637)

Does using Explorer.exe instead of command.exe log get you in with a full shell and start menu?

Re:New definition of "Accessibility" (1)

Zero__Kelvin (151819) | about 10 months ago | (#44821807)

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.

Re:New definition of "Accessibility" (1)

omnichad (1198475) | about 10 months ago | (#44821891)

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:New definition of "Accessibility" (1)

BitZtream (692029) | about 10 months ago | (#44821659)

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:New definition of "Accessibility" (-1)

Zero__Kelvin (151819) | about 10 months ago | (#44821767)

"You do realize that when you started copying files around on the volume that you already have full access right?"

Really? You mean having local disk access allows me to authenticate as a user on the running system and access all the settings through a GUI interface?

"Why would you bother with replacing magnify.exe when when you have complete access to the system without needing any passwords at all?"

Because I wanted to boot into the system and look at all the settings using all the tools available. There is a huge difference between complete access to a drives data and complete access to a running server instance.

"When someone has direct physical access to your 'hardware' (virtual or otherwise), you can't stop them from getting at it."

Again, you miss the point completely.

Re:New definition of "Accessibility" (1)

bws111 (1216812) | about 10 months ago | (#44822409)

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:New definition of "Accessibility" (0)

Zero__Kelvin (151819) | about 10 months ago | (#44822643)

You are apparently unable to understand what I wrote. I'll try to make it more simple. Access to bytes on a disk is not the same as access to a running system. If it was, then there would be no use for chntpw. As an exercise, go ahead and change the admin password on a drive by editing a file with the editor of your choice. Please get back to me when you have successfully done that, and not before. Thanks. (In case that was too subtle, I just asked you to go away forever.)

Re:New definition of "Accessibility" (1)

bws111 (1216812) | about 10 months ago | (#44823285)

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 vncserver, reboot Linux. Now you can magically connect to the system through vnc, and you will be logged in AS ROOT, without a password (or using a vnc password that you set). Don't want to use vncserver? Replace a pam module with one that doesn't actually do anything. Presto magico! You now have full access to the running system. Amazing!

You have not demonstrated any vulnerability, other than the vulnerability of letting an idiot have full access to your drive.

Re:New definition of "Accessibility" (0)

Zero__Kelvin (151819) | about 10 months ago | (#44823633)

"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 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 didn't get that, and I'm not 100% certain you did either until I pointed it out, frankly.

"There is nothing special about what you did, and it is not a vulnerability, and there is nothing to 'get smart' about."

Are you some kind of idiot? The OP said that there was no advantage to hacking into the system because you could access the data on the drive. He missed the point that logging in to a hacked system avails you of numerous capabilities that mere access to the data on the drive does not. Now you are coming in at the end and saying that the guy didn't miss anything because all hacking into the system gets you is access to the running system.

"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 vncserver, reboot Linux. "

Evidently you need to improve your knowledge quite a bit. You can't do it with an SELinux enabled system, for example. And you especially cant do it on a system that has an encrypted boot partition.

"Presto magico! You now have full access to the running system. Amazing!

Yes. It is so easy I can't believe everyone isn't doing it! (you are an idiot, and you know far less than you think) You didn't tell me anything I didn't know but that plenty of people don't know it, and you apparently can't read, or follow simple conversation flow. This whole article is about a guy who hacked into a system. He did it with Linux and a modified chntpw. I pointed out that you can do it easily without any special tools using Windows stock, out of the box.. Now you come along and say "all you did by hacking into the system is hack into the system." Priceless stupidity, a basic lack of understanding of OS security, and completely unjustified arrogance. Congratulations on the Trifecta!

Re:New definition of "Accessibility" (0)

Anonymous Coward | about 10 months ago | (#44825729)

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.

Sure you could. Pull his Firefox profile directory (or equivalent files/database for other browsers, drop it into a fresh user account on your own machine, and you can do that.

"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 vncserver, reboot Linux. "

Evidently you need to improve your knowledge quite a bit. You can't do it with an SELinux enabled system, for example. And you especially cant do it on a system that has an encrypted boot partition.

Correct, but in order to do any action that system can do, you don't NEED to do that tomfoolery; you can copy all the data needed for that action to a similar system, and do it there. SSH host keys + SSH user keys, browser stored passwords, etc,; practically none of it is encrypted by an encryption co-processor with embedded, non-readable key, to prevent it from being usable on another system, so it's either not usable at all without entering a decryption key (e.g. KeePass and similar programs) or the data can be extracted, dropped into another system, and used to impersonate that system with no need to get the original system back up.

I agree there are benefits to full privileges on a running system, vs. local disk access only, but they're mostly matters of convenience only; things you can do with a running system but can't with disk access only are really pretty slim in practice. You're really overstating the distinction at least as much as GP was overstating the similarity.

Re:New definition of "Accessibility" (0)

Anonymous Coward | about 10 months ago | (#44822529)

Having local disk access means having local disk access, means you can modify anything and everything... Any security violation, real or immagined, happened here:

add the drive to a system you own

[H]aving local disk access allows me to authenticate as a user on the running system... ?

Yes.

There is a huge difference between complete access to a drives data and complete access to a running server instance.

Nope. There isn't.

Physical Access == Game Over

If you have physical access to the hard drive, you could replace any file. You could add a VNC server running as root. You could install any bot, malware, script or backdoor you please to the system.

Again, you miss the point completely.

No, you did.

Re:New definition of "Accessibility" (0)

Zero__Kelvin (151819) | about 10 months ago | (#44822859)

Oh really? Allow me to show you where you missed the boat completely. Suppose I had two partitions on the drive. One is encrypted and the other isn't. The tools for mounting the encrypted partition are on the drive in the unencrypted partition. The passwords are stored in a file that is not a standard text file, as is standard practice. Now what is easier. Figuring out how to get the program to run, accessing the drive mapped as another drive letter on a differently configured system (if possible, it would likely take months of effort if done right) or replacing Magnify.exe?

Re:New definition of "Accessibility" (1)

tgd (2822) | about 10 months ago | (#44821811)

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 (1)

cbhacking (979169) | about 10 months ago | (#44822075)

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:New definition of "Accessibility" (1)

glavenoid (636808) | about 10 months ago | (#44821769)

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.

Re:New definition of "Accessibility" (0)

Zero__Kelvin (151819) | about 10 months ago | (#44822569)

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.

Re:New definition of "Accessibility" (1)

The MAZZTer (911996) | about 10 months ago | (#44821773)

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]

Blank pwd SAM can do the same (0)

Anonymous Coward | about 10 months ago | (#44822539)

Replacing the SAM with one that has a BLANK (or predefined) password does the job too... it's how SysInternals' "ERD Commander" works in fact.

This is NOT "genius level" stuff @ all, easy in fact... here's how:

In other words - once you have the harddrive in question, you mount it on another booting NT based OS of the same build as a secondary harddisk if needed, on another system (putting the hdd into another IDE/EIDE/SATA type slot), & even minus SysInternals tools, reassign yourself as an NTFS FULL Admin rights level user to the disk you want to get to, & boom - you can replace the ORIGINAL password bearing SAM as noted above with 1 of your own (blank pwd), & in you go, once you make THAT disk you wanted "in" to, the bootable one (& if diff. hardware were on the original system it was in, no biggie - "Plug-N-Play" will make up for it)!

APK

P.S.=> Of course, you CAN do the Linux route if you wish, but it's more work imo... apk

Re:New definition of "Accessibility" (0)

Zero__Kelvin (151819) | about 10 months ago | (#44822541)

" 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 running system. Access to data and access to a running system with the ability to view and change settings using software tools are two different things.

Re:New definition of "Accessibility" (1)

Anonymous Coward | about 10 months ago | (#44822869)

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:New definition of "Accessibility" (0)

Zero__Kelvin (151819) | about 10 months ago | (#44822961)

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 :-(

Re:New definition of "Accessibility" (1)

bws111 (1216812) | about 10 months ago | (#44823539)

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:New definition of "Accessibility" (0)

Zero__Kelvin (151819) | about 10 months ago | (#44823765)

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.

If you're worried about the NSA... (0)

Anonymous Coward | about 10 months ago | (#44821565)

don't put your stuff on AWS.

I doubt anybody has...until I modified it (0)

Anonymous Coward | about 10 months ago | (#44821595)

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

Because you're the only person that could possesses the skill to modify a program....

Earth-shattering (3, Insightful)

davidbrit2 (775091) | about 10 months ago | (#44821647)

Unencrypted volumes can be easily modified when mounted on a different system; film at 11.

Re:Earth-shattering (1)

RightSaidFred99 (874576) | about 10 months ago | (#44822633)

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.

About Jeff (2)

PetiePooo (606423) | about 10 months ago | (#44821665)

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 the exciting world of security research!

I applaud you for (re)discovering these techniques on your own. Your out-of-box thinking and problem solving are to be commended, but your research skills could use some polish. Please don't let the negative comments above discourage you from exploring this rewarding field of knowledge, however I would recommend you run your findings by some existing security folks before announcing your next big discovery, lest you find you're just rehashing something else that has long been known.

Seriously; good job! I enjoyed reading how you worked your way up to your conclusions, even though I knew from the start how it would end...

Re:About Jeff (1)

shutdown -p now (807394) | about 10 months ago | (#44821681)

Yes, but did he try JavaScript?

Re:About Jeff (3, Insightful)

cbhacking (979169) | about 10 months ago | (#44822211)

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.

Styx (0)

Anonymous Coward | about 10 months ago | (#44823287)

You see the world through your cynical eyes
You're a troubled young man I can tell
You've got it all in the palm of your hand
But your hand's wet with sweat and your head needs a rest

And he's fooling himself if he doesn't believe it
He's kidding himself if he doesn't believe it
How can you be such an angry young man
When your future looks quite bright to me
How can there be such a sinister plan
That could hide such a lamb, such a caring young man

He's fooling himself if he doesn't believe it
He's kidding himself if he doesn't believe it
Get up, get back on your feet
You're the one they can't beat and you know it
Come on, let's see what you've got
Just take your best shot and don't blow it

Fooling Yourself - Styx [youtube.com]

NSA joy (0)

Anonymous Coward | about 10 months ago | (#44821691)

NSA: There's no such things as *flaws*. We, the NSA, and btw, any other illegal (lawful) organizations consider all security-flaws as features.

So basically they modified the VM image file (0)

Anonymous Coward | about 10 months ago | (#44821711)

In short, this guy just figured out that VM image files can be modified directly. He also just figured out that you can modify VM images too and do nasty things to them. My question is, why is something so fucking basic a /. story. This is no different than pulling out the hard drive of a machine, changing the admin password in another server and booting back up. You could do this with Windows, Linux, FreeBSD etc, but this is certainly not new, or news for that matter.

Uhhh, sure, nice Cloud FUD (1)

psydeshow (154300) | about 10 months ago | (#44821851)

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 password, you know.

Thanks for updating chntwp, though.

News flash (1)

viperidaenz (2515578) | about 10 months ago | (#44822045)

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

Fail article... (1)

steppin_razor_LA (236684) | about 10 months ago | (#44822243)

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.

How the hell is this a Windows flaw? (0)

Anonymous Coward | about 10 months ago | (#44822369)

That you can "own" the system when you have complete access to overwrite te storage volume and program code ?? No fucking shit.

This is simply risible. (1)

RightSaidFred99 (874576) | about 10 months ago | (#44822611)

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.

Embarrassing (0)

Anonymous Coward | about 10 months ago | (#44822685)

The author should remove the article ASAP, for its own benefit.

This guy is a tool (0)

Anonymous Coward | about 10 months ago | (#44823559)

There is no a vulnerability nor is it a flaw in Windows, nor is this in any way news to anyone.
If you want your volumes encrypted.... do so, otherwise of course who ever has physical ( or in this case virtual) access to them can get at them.
   

Seriously (0)

Anonymous Coward | about 10 months ago | (#44823995)

What kind of BS is this?

go home (0)

Anonymous Coward | about 10 months ago | (#44824009)

slashdot go home, You are drunk

Jeff Cogswell is a moron. (0)

Anonymous Coward | about 10 months ago | (#44824607)

s/$TFS/Jeff Cogswell doesn't know shit.
s/$TFA/Jeff Cogswell is a fucking clueless moron./

Misleading title, invalid statements (0)

Anonymous Coward | about 10 months ago | (#44825475)

I expected better on stack overflow. This is incorrect and misleading, and is in no part a valid security concern.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...