Two glaring problems with this (superficial) article:
(1) No modern OS gives up the password hash without a vulnerability that can probably be used for things worse than reading password hashes.
(2) No modern OS uses a hashing scheme that gives up "good" passwords, and no hashing scheme can protect you from horrible passwords.
In penetration testing, password cracking is something you do after your first game-over vulnerability, to make the report a lot scarier. The game was over when you got the hashes, though.
The article assumes that you have physical access to computer and the target does have encrypted disk. So getting password hash is trivial. What is remarkable is that on Windows the article recommends bruteforce attack, while on other OS it recommends changing the password. While bruteforce could take more time, its less noticeable, as the real user can log in normally afterwards.
But the real point is that physical access == security fail.
I'd say they're overcomplicating the problem. Simply install a keylogger in the guts of the keyboard and come back a week later.
If you feel like doing something fancy install a small fsk modulator in the FM band in the keyboard and monitor the typed in stuff remotely, use that to access an image you made of the drive.
In Unixes that uses the shadow system you just mount the partition and simply delete the string between the first and second colon to clean the password (in the /etc/shadow file), the string before the first colon is the username, but this only works for the users that do not use another authentication system (such as NIS or Kerberos). Mac OS X (>= 10.5) uses a different system (10.4 uses the netinfo database), the user information (And I guess that the password, as well) are in /var/db/dslocal/nodes/default/users/ in separate .plist files, I could not check if the password hash are included there since my Mac is at home, if I remember about this later I'll try to come with a password cleaning to OS X in this article later.
In lilo there is a way to not let the user log in in the single user mode without providing the password, I think that grub could be configured to do the same. So I believe the method that the article describes will not work for every linux installation.
By the way, what about some others operating systems, *BSDs, and some that are more exotic (if they use shadow, the method described above works), such as OpenVMS? I do not use windows since forever, so I cannot say much about how the system handles passwords.
Thanks, as you demonstrated, it does not includes the password hash, searching on google I found that the password is stored in /var/db/shadow/hash/, a file for each user, I'm reading these:
Article -> You can reset the passwords on Windows using Ophcrack. And you can reset the passwords on Linux, and OSX by using single-user mode. You can't get the original password or access to encrypted files.
Actually, the article says that Ophcrack does deliver the original password:
> The computer will restart and Ophcrack will be loaded. Sit back and watch as it does all the work for your. Write down the password it gives you, remove the disc, restart the computer, and log in as if it were you own machine.
Ophcrack hasn't worked in years.
It relied on a feature of W2k/XP that stored a copy of the password in an older less secure hash for compatibility with Lanman shares.
XP(updated) and newer dropped this and use a secure hash - there are services that will brute force it on a cluster for $$$ but it isn't going to take 5mins with an ophcrack boot cd anymore.
> Starting with version 2.3, Ophcrack also cracks NTLM hashes. This is necessary if the generation of the LM hash is disabled (this is default for Windows Vista), or if the password is longer than 14 characters (in which case the LM hash is not stored).
> To change the password, turn on the computer and press the ESC key when GRUB appears. Scroll down and highlight ‘Recovery Mode’ and press the ‘B’ key; this will cause you to enter ‘Single User Mode’.
I wonder what Linux distributions have this menu entry. Also, some distributions (e.g. Fedora) allow you to use a GRUB password and you can't edit menu entries without it.
I think this "Linux" is deadrat rather than anything else; every other Linux I know of requires your root password before you are given the shell in "recovery mode".
But of course, you can just boot from a flash drive and do whatever you want to the target system; add accounts, change passwords, whatever. This is why you use full-disk encryption.
You cannot carry out any of those if you set the on-boot password and don't keep your harddrive in plain. TPM adds some additional protection for bootloader itself. Even if they mention it at the end of the article - the title is really misleading. It's not "any system".
As we already know that physical access = game over so design your systems accordingly.
Plan 9 does this by having a central auth server. You lock the it a cupboard and add some armed guards if you need. In fact, booting a Plan9 terminal doesn't even need a password. However if you want to connect to the other systems you're going to need an auth ticket.
Other systems should be using something like Kerberos or a domain controller or whatever schemes are available.
If it is likely someone will have access to your terminal and they might steal from you, storing passwords there is d u m b.
18 comments
[ 204 ms ] story [ 1562 ms ] thread(1) No modern OS gives up the password hash without a vulnerability that can probably be used for things worse than reading password hashes.
(2) No modern OS uses a hashing scheme that gives up "good" passwords, and no hashing scheme can protect you from horrible passwords.
In penetration testing, password cracking is something you do after your first game-over vulnerability, to make the report a lot scarier. The game was over when you got the hashes, though.
But the real point is that physical access == security fail.
If you feel like doing something fancy install a small fsk modulator in the FM band in the keyboard and monitor the typed in stuff remotely, use that to access an image you made of the drive.
In lilo there is a way to not let the user log in in the single user mode without providing the password, I think that grub could be configured to do the same. So I believe the method that the article describes will not work for every linux installation.
By the way, what about some others operating systems, *BSDs, and some that are more exotic (if they use shadow, the method described above works), such as OpenVMS? I do not use windows since forever, so I cannot say much about how the system handles passwords.
http://www.openwall.com/lists/john-users/2008/06/24/2
http://www.dribin.org/dave/blog/archives/2006/04/28/os_x_pas...
I will do some experiments at home, but I have no clue how to clean an OS X user's password.
Article -> You can reset the passwords on Windows using Ophcrack. And you can reset the passwords on Linux, and OSX by using single-user mode. You can't get the original password or access to encrypted files.
> The computer will restart and Ophcrack will be loaded. Sit back and watch as it does all the work for your. Write down the password it gives you, remove the disc, restart the computer, and log in as if it were you own machine.
XP(updated) and newer dropped this and use a secure hash - there are services that will brute force it on a cluster for $$$ but it isn't going to take 5mins with an ophcrack boot cd anymore.
> Starting with version 2.3, Ophcrack also cracks NTLM hashes. This is necessary if the generation of the LM hash is disabled (this is default for Windows Vista), or if the password is longer than 14 characters (in which case the LM hash is not stored).
I wonder what Linux distributions have this menu entry. Also, some distributions (e.g. Fedora) allow you to use a GRUB password and you can't edit menu entries without it.
But of course, you can just boot from a flash drive and do whatever you want to the target system; add accounts, change passwords, whatever. This is why you use full-disk encryption.
That'll give you a root prompt. You may need to mount filesystems by hand, etc., since init scripts have not run.
1. Lack of BIOS protection.
2. Lack of HD encryption.
You cannot carry out any of those if you set the on-boot password and don't keep your harddrive in plain. TPM adds some additional protection for bootloader itself. Even if they mention it at the end of the article - the title is really misleading. It's not "any system".
Plan 9 does this by having a central auth server. You lock the it a cupboard and add some armed guards if you need. In fact, booting a Plan9 terminal doesn't even need a password. However if you want to connect to the other systems you're going to need an auth ticket.
Other systems should be using something like Kerberos or a domain controller or whatever schemes are available.
If it is likely someone will have access to your terminal and they might steal from you, storing passwords there is d u m b.