53

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?

JimmyJames
  • 2,956
  • 2
  • 16
  • 25
  • 28
    You'll also notice that most often, it's not OS passwords (`/etc/shadow`) that are leaked, but passwords for a Web-based app/service. These are normally stored in a database, and thus vulnerable to database breaches. – Angew is no longer proud of SO Aug 23 '16 at 15:15
  • 6
    Some protocols (e.g. NTLM, WPA2-PSK) send password hashes over the network – paj28 Aug 23 '16 at 16:03
  • 1
    @paj28 w/ regard to NTLM, this is the same thing that allows for [pass-the-hash](https://dfir-blog.com/2015/11/08/protecting-windows-networks-defeating-pass-the-hash/) right? – JimmyJames Aug 23 '16 at 16:59
  • 18
    It's *not* inevitable, but that doesn't matter. Good security design *assumes* that every other defense has fallen, and aims to find ways to still save the protected resource. So why do we wish hashing algorithms to be resistant to attack? Because *by assumption*, that algorithm is the last man standing in the defense of the protected resource. – Eric Lippert Aug 23 '16 at 17:35
  • 5
    One important thing to remember that even though many of the issues that reveal password hashes might mean "game over" for the server that got hacked, that's not necessarily where the value lies. The server that got hacked might be nearly worthless to the hacker, but if those hashes can be cracked (or if they were plaintext, etc), then password reuse means that the hacker might have access to email accounts, bank accounts, etc. – Kat Aug 23 '16 at 19:27
  • @EricLippert Your point is taken but I just want to clarify that I am not questioning the need to have a strong hash. I am just trying to better understand the mechanics around such attacks as most literature on the subject seems to start at having the hashes in hand. The responses are helpful as I attempt to articulate why passwords are problematic. – JimmyJames Aug 23 '16 at 19:28
  • Usually, they don't. *If they somehow do*, then the hashing strength can still save you. – user253751 Aug 24 '16 at 04:11
  • @JimmyJames - It's definitely related, although there's two separate issues: 1) Hash transmitted on the network are vulnerable sniffing and brute focing 2) hashes captured on live systems can be used directly, with out needing to brute force the password – paj28 Aug 24 '16 at 09:56
  • For comparison, I think the MySQL login system (without ssl) is vulnerable to 1, but not to 2. – paj28 Aug 24 '16 at 09:57
  • Having access to /etc/shadow may not be game over. You might be able to exploit a file disclosure vulnerability in a web server that is running as root (which it shouldn't, but anyway). How would you proceed if you can read any file, but not more than that? Unless the admin made more mistakes, your only bet is to crack the password in /etc/shadow and hope that SSH with password authentication or similar is even available to the public. That's why it's important to choose a secure password, limit the amount of services your host offers, and disable password-based auth. – Volker Aug 25 '16 at 07:47
  • If read access to `/etc/shadow` meant "game over", there'd be no reason to store in it only hashed passwords in the first place. – Hagen von Eitzen Aug 25 '16 at 11:53
  • @HagenvonEitzen: And even if, if I got somehow permissions as sql user I'd first try (in case my intuitions are causing damage) `SELECT * FROM pw;` and that alike. but this doesn't give me acces to `/etc/shadow` at all. – Zaibis Aug 25 '16 at 12:57

5 Answers5

56

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

Community
  • 1
Anders
  • 64,406
  • 24
  • 178
  • 215
  • 1
    I don't mean to suggest not important, it just seems sometimes like there's this fatalistic attitude around this. I find lots of information about cracking passwords but not that much about how to prevent leaking the hashes. – JimmyJames Aug 23 '16 at 14:46
  • 18
    @JimmyJames The reason you don't find any specific information about preventing leaking passwords is that virtually *every* server-side vulnerability allows that. Out of the [OWASP Top 10 vulnerability classes](https://www.owasp.org/index.php/Top_10_2013-Top_10), classes 1, 2, 4, 5, 6, and 9 could leak password hashes. In other words, more than *half of **all** security efforts* counter password hash disclosure in one way or another. – phihag Aug 23 '16 at 16:42
  • 1
    Comments are not for extended discussion; this conversation has been [moved to chat](http://chat.stackexchange.com/rooms/44500/discussion-on-answer-by-anders-how-does-an-attacker-get-access-to-hashed-passwor). – Rory Alsop Aug 25 '16 at 23:01
29

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.
Mark Buffalo
  • 22,498
  • 8
  • 74
  • 91
  • So in a nutshell, one or more vulnerabilities is used to get access indirectly. OK kind of seems obvious now that you put it like that. – JimmyJames Aug 23 '16 at 14:51
  • Pretty much. All are relatively easy to exploit anyway. – Mark Buffalo Aug 23 '16 at 15:20
  • Modern systems won't have passwords in /etc/passwd, they are in /etc/shadow. – MikeP Aug 23 '16 at 17:27
  • @MikeP You are correct. This is just an example. – Mark Buffalo Aug 23 '16 at 17:30
  • why would cracking a password be a major concern? If they have access to the database, surely they don't need a password to access other valuable information- they could simply view it and likely would be in plain text – james Aug 23 '16 at 19:48
  • 4
    I'm not sure I follow you. The password won't be stored in plain text if it's done right, even if everything else is wrong. It's a major concern because people reuse passwords, and it may allow them to access other websites using the same username/password combo. – Mark Buffalo Aug 23 '16 at 19:50
  • 2
    @binnyb, getting a user's email address and password doesn't just compromise the one system. Due to password reuse, it can compromise many systems. For more info: http://krebsonsecurity.com/2013/06/the-value-of-a-hacked-email-account/ – MikeP Aug 24 '16 at 15:40
  • 1
    @MikeP I should've clarified: `/etc/passwd` allows you to find usernames, which can then be used to log in or escalate privileges. It's a small part of the process, but a fundamental one. When users reuse passwords across multiple systems, you may just need to find a valid username if you have valid passwords. LFI/RFI can also be used to gain code execution, which could provide DB credentials, AWS creds, etc. – Mark Buffalo Apr 04 '19 at 01:51
9

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.

MikeP
  • 1,159
  • 7
  • 12
  • Which connection are you intercepting here? – Bergi Aug 23 '16 at 19:25
  • OP is only asking for cases where the attacker gains access to lots of hashes. – Bergi Aug 23 '16 at 19:26
  • @Bergi This answer is also relevant. – JimmyJames Aug 23 '16 at 19:30
  • @Bergi, OP doesn't state "lots". However, If someone has access to a way of MitM attacking, then they can get "lots". – MikeP Aug 24 '16 at 15:40
  • Yes, if you can listen to the unencrypted traffic between the database and the application server that might reveal some hashes, that's what I wanted you to clarify. But I think a pass-the-hash scenario where you can control the hashes by being a mitm is not relevant for the question. – Bergi Aug 24 '16 at 15:44
6

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.

Cort Ammon
  • 9,206
  • 3
  • 25
  • 26
  • 1
    You'll also salt the hash, so that 2 same passwords won't end up with the same hash. That way hackers can't just create a huge database of hash for passords. – user276648 Aug 24 '16 at 08:42
  • 2
    "I'd check in on it every once in a while" -- and that's probably your downfall. Whatever procedures you put in place to let yourself in to check on it, there's your opportunity to screw something up and allow an attacker in. – Steve Jessop Aug 24 '16 at 09:55
  • @SteveJessop True, the best way to secure a computer has always been to run it through a woodchipper, and then set fire to the remains =) – Cort Ammon Aug 24 '16 at 13:31
  • 1
    @CortAmmon While I don't disagree with the point that you paranoia is important in securing systems, I think this line of reasoning is often misused as an excuse for not trying. I perceive a popular delusion that breaking into a system is like breaking into a safe. Given enough time, effort & equipment you can break in. The reality is that most vulnerabilities are built into systems due to laziness and ignorance. When people fail by writing vulnerable code or failing to use good practices, we often hear about the 'impossibility' of securing systems. – JimmyJames Aug 24 '16 at 14:55
  • @JimmyJames I've actually seen the opposite effect as well. I've seen people who believe that, since they've done everything that they can do to secure a system, and they believe a system can actually be secure, those two assumptions together "prove" that their system is secure. Then they get lazy and don't use security in depth. Only when you admit that your system is insecure does security in depth make sense. I've also seen an unrelenting march towards "perfectly secure" dash usability against the rocks. I find both of those cases are as troublesome as the one you bring up. – Cort Ammon Aug 24 '16 at 17:19
  • 2
    @CortAmmon Good points. If I could coin a phrase around this I'd make it something like "assume you have vulnerabilities and continually strive to eliminate all of them." – JimmyJames Aug 24 '16 at 19:54
  • @JimmyJames I like that phrasing. It reminds me of the famous phrasing "Plans are useless, but planning is indispensable." – Cort Ammon Aug 24 '16 at 20:57
  • A non-powered computer may have good confidentiality, but integrity and availability may be a bit lacking... – Andrew Wolfe Oct 30 '19 at 01:50
2

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.

rackandboneman
  • 975
  • 4
  • 9