How does an attacker get access to hashed passwords?

Question

The way that we hash passwords and the strength of password is important because if someone gets access to the hashed passwords, it's possible to try lots and lots of passwords in a surprisingly short amount of time and crack anything that is weak.

The question I have is how is it that the attacker get access to the hashed passwords in the first place. If they have access to the /etc/shadow file, for example, isn't it already game over? Is it simply bad permissions settings? Backups? Other mistakes? Is it that once one system is compromised, the password from there are used to attempt to get into other systems?

I guess ultimately my query boils down to the implication I get from reading about this subject that it's inevitable that the attacker will get access to the hashes. How does that happen in practice?

Answer 1

There are any number of ways:

• SQL injection
• Leaked backups
• Disgruntled employees leaking them
• Any kind of breach of the server that allows code execution.

As you can see there are many, many ways this could happened - as phihag mention in comments, more than half of the OWASP top 10 could lead to leaked hashes - so they can not be easily tabulated in a post.

This does not mean that it is inevitable that hackers gets the hashes, but you should still use a good hashing algorithm to protect yourself and your users just in case. Since a backup may be lost or your server hacked without you ever noticing, having properly hashed passwords should be the only thing that allows you to sleep at night. This strategy is known as "defence in depth", or just simply "plan for the worst".

Answer 2

There are many methods. Here are some I can think of off the top of my head. Now I might be a little wrong with the syntax as I haven't bothered to test it out right now, but in general, these are things you'd do in order to get that data.

Note that, with the below exploits, I am not necessarily providing examples which steal hashes (with the exception of SQLi), but examples of how the exploits can work. The attacker would use exploits below to further compromise a system.

1. SQL injection

   Example:
   a OR 1=1'; exec sp_msforeachtable "SELECT * FROM ?";--

   You could also use sp_msforeachdb, like so:

   a'; exec sp_msforeachdb 'USE ?;exec sp_msforeachTable "SELECT * FROM !","!"';--

   The -- is there to comment out parts of the SQL statement that may interfere with your injection. These are just very basic examples. It really depends on the format of the query.

2. OS Injection. ; cat /etc/passwd; rm -rf /*
3. LDAP Injection. *, (cn = *)(|(password =*))

4. Insecure Direct Object Reference leading to Local / Remote File Inclusion vulnerability.

   /etc/passwd%00 (note: passwords, of course, aren't stored here; finding valid usernames when people reuse passwords is the key here, or using the usernames to aid in escalation of privileges)

   %00 is a "null terminator" used to avoid anything coming after it, so you don't try to include something that doesn't exist, e.g.: /etc/passwd.txt. This could also be \000, \x00, \z, \u0000, \0, or \00 depending on the language you're using.

5. Hacking a developer / user with access to the databases.
6. Exploiting the database server, or web server through some other means.

Answer 3

One addition to Mark Buffalo:
7. Man-in-the-Middle attack. Watching unencrypted traffic can often reveal a password hash. In a pass-the-hash scenario, systems will trust the hash and the password and let an attacker simply copy the hash without cracking it.

Answer 4

The only truly secure computer is one that is isolated from the internet, turned off, unplugged, buried in a bunker 100ft under ground, with armed guards at the only entrance. Even then, I'd check in on it every once in a while.

Hashing the passwords is part of what is known as "security in depth." You are correct that, in an ideal world, you would not make any mistakes which would give attackers access to that data, so in theory it would not matter if they were plaintext passwords or hashes. In a real world, intrusions do occur, and it remarkably hard to predict how and where they will occur. The idea behind security in depth is to make it so that, in theory, even if an attacker compromises your system in some way, you have taken efforts to mitigate the damage.

In the real world, there is a natural need to access hashes on a regular basis. Every time a user logs in, you need the ability to access them. Accordingly, they are almost always accessible to whatever application is doing the authentication. If someone compromises your application, they may be able to read data that they weren't supposed to be able to read.

The ways these attacks occur are endless. You can have SQL injection attacks if you failed to sanitize your inputs. You could have a buffer overrun, giving the attacker the ability to run their own code. You could have a permissions error, accidentally making a file readable by people when you shouldn't have. The attacker may get their hands on one of your backup tapes due to mishandling by your backup service!

All of these attacks give an attacker a foothold on your computer, but they don't always result in a complete break. You may have chrooted your SQL server, so that the SQL server process literally cannot see the entire rest of the computer. However, in such situations, the login information users need must be within the SQL server's reach, or its of no value. Thus, login information is typically compromised before other more nefarious compromises occur.

By hashing the passwords, you decrease their value. A hash isn't useful for login purposes. They need to have the password which hashes to that value. They may or may not be able to afford the cost of breaking the hash. In the best of all worlds, you never needed to worry about this in the first place, but if you subscribe to the security in depth approach, you make sure that even a successful intrusion doesn't compromise all of your data.

Answer 5

Some old-school networked un*x/linux installations will still use the NIS/YP service for centrally managed authentication. NIS effectively publishes the hashed passwords on the network for every workstation to authenticate users against.