1

Generally what happens when an user registers to a web app is that their passwords get hashed well, so even if a DB leak happens, getting the original password is not feasible.

But what happens if an attacker (or a malicious sysadmin) gets access to the DB and APP server and instead of dumping the data, he/she seeks out the code doing the hashing/salting, with that knowledge forges a new hash, and simply drops it inside the appropriate field in the DB?

I know this is a very unlikely scenario, but is there an industry standard way to protect the user accounts against this?

Clarification: The attacker would only have read-only access to the APP server, and read-write permissions to the DB.

Improve this question
3
  • 2
    If the app and db server are compromised, there's nothing left to protect...
    – Neil McGuigan
    Aug 31, 2017 at 18:41
  • 1
    If the attacker already has access to the whole db, he already can access all the data that a user password was meant to protect. There's no point in altering passwords, it only prevents users from logging in which would lead to an investigation of the cause.
    – Bergi
    Aug 31, 2017 at 23:04
  • This really is a non-question. If your database has been compromised there's nothing you can protect against.
    – James Hyde
    Sep 1, 2017 at 7:13

7 Answers 7

Reset to default
16

Effectively, all the attacker is doing is changing users' passwords. This would enable the attacker to login to those users' accounts. As for how you protect against this, I'm not sure you should bother. If someone has read/write access to your DB you're pretty much sunk. You need to protect from someone obtaining read/write access to the DB in the first place, not try to prevent someone who has write access from just changing someone's password.

This is sort of like wondering, if someone breaks into your home, how could you stop them from opening the fridge and stealing your beer?

Improve this answer
5
  • 2
    Isn't that what safes are for though? "If someone breaks into my home, I don't want them to steal my valuables."
    – Nate Diamond
    Aug 31, 2017 at 20:45
  • 6
    @NateDiamond - Right, and my point is you probably wouldn't store beer in your safe. (i.e. you have bigger things to worry about than someone changing user passwords.)
    – TTT
    Aug 31, 2017 at 21:03
  • @TTT I think the safe brings up a good point. A good safe can make it prohibitively difficult to access the contents, even if the thief has physical access/ownership of it. As an example, look at the Apple vs the FBI situation that made headlines a while back.
    – Amani Kilumanga
    Sep 1, 2017 at 4:33
  • This makes sense, I was just wondering if there is some kind of an elegant way to protect against this situation, but as you've pointed out, this just does not worth it, and I should really focus my research on fortifying "outer layers" of defenses. Thank you!
    – Sevron
    Sep 1, 2017 at 16:19
  • 1
    I think the main point is, the DB should be the safe. Once they're in, they can do basically what they please.
    – Nate Diamond
    Sep 1, 2017 at 16:47
4

Your question can be paraphrased as:

How do you stop someone with access to change data from changing data?

The first step is to ensure that only the people expected to have access do have access. This is about good password management practices and account auditing (for those who are expected at some point to have access) while to prevent people who are never intended to have access, regular patching, code inspections and pen testing.

But you can't prevent your sysadmin from going crazy (apart from good salaries and working conditions etc) and you can never prove your system is completely secure. But there are still things you can do to prevent or contain such activity.

The classic 3-tier web app has a service account on the application tier which connects to the database. I've frequently seen (and in the past written) apps where this account has read/write access to all the tables containing the data to be manipulated. Restricting the read and write operations to specific records by using stored procedures provides some mitigation.

A complementary approach is to make the authentication from the application tier to the database dependent on the credentials supplied by the end user rather than simply treating the validation of the user credentials as a gateway test. At its simplest - the end users would be created as database users and the application would store their credentials each time it needs to connect. However this does approach has scalability issues - notably with Oracle which has a rather chatty authentication process resulting in most apps on Oracle re-using persistent connections. In the absence of additional controls it also means that the end user passwords are being stored in clear text rather than just the service password in cleartext (but there are solutions to this).

The other important piece of the puzzle, after you've done all you can to prevent an incident, is detection: Capturing identifiers of the client (IP address) when important data is changed: capturing the queries and DML being sent to that database and auditing it : deploying honeypot/canary data

Improve this answer
3

I think you can't - if they have control of the App server, they can patch it to bypass password checking entirely.

The point of hashing is to make it harder to go from a leaked database to access to the online accounts. Also that any passwords users have shared between services are harder to extract.

If they have the ability to alter the live database only (and not the app server), then a 'pepper' added to the hash might prevent them replacing the hash with their own.

Improve this answer
4
  • That's really all there is to it. If the app server is compromised then everything is compromised. Which is not to say that such a possibility should just be ignored, but you definitely can't fix it at the authentication-level.
    – Conor Mancone
    Aug 31, 2017 at 15:15
  • Yes in that case there is nothing to do, but I described a situation where the app and db server would be on a different machine, and the APP code could not be changed.
    – Sevron
    Aug 31, 2017 at 15:17
  • @Sevron In your question you said the attacker had access to both the App and Db servers?
    – Douglas Leeder
    Aug 31, 2017 at 15:31
  • @DouglasLeeder Yes sorry about that, it's my mistake.
    – Sevron
    Aug 31, 2017 at 15:45
2

The scenario you describe is much worse than the attacker simply being able to replace users' passwords with their own, if they can modify your application code they can do anything they want. With password reuse I'd also be concerned about plaintext passwords being exposed.

If you can no longer trust the code of your application then you've already lost utterly. The only thing left to do is nuke it from orbit.

Edit: Since it turns out the attacker can't change the application code they won't be able to steal plaintext passwords, but since they can probably do most things the app allows by directly editing the database it doesn't seem worth it to prevent them from replacing passwords even if it were possible.

Improve this answer
5
  • You misunderstood. I described a situation where only the DB would be compromised. And the APP code would be made public for example. But the code would not be compromised in any way.
    – Sevron
    Aug 31, 2017 at 15:09
  • 1
    You said "gets access to the DB and APP server", but you didn't specify what type of access. You obviously meant write access to the DB so I assumed write access to the APP as well, you should clarify the question.
    – AndrolGenhald
    Aug 31, 2017 at 15:27
  • Clarified in an edit to the original question. Sorry about the confusion.
    – Sevron
    Aug 31, 2017 at 15:47
  • @Sevron Why are the database and code both accessible with the same credentials, then?
    – JAB
    Aug 31, 2017 at 16:45
  • 1
    @JAB He did say it was unlikely, but if DB and APP are on the same server perhaps they've got a shell as the mysql user and the app is world readable. Or maybe they're able to use LOAD DATA INFILE to get the contents of app files if the database is misconfigured.
    – AndrolGenhald
    Aug 31, 2017 at 16:50
1

Security Monitoring

You can deploy tools that can monitor everything inside a database and create warnings when a user modify information or run scripts inside the database, most of these tools will report the instant than a user logon on the database, and every script and procedure modify/run during his time inside.

Remember that you DB Admin can access the database but the information/tables/scripts should be restricted completly.

How can be protected?

You implement differents approachs or procedures for the access of any employee to your database and the excecute of scripts and procedures.

Your DB Admin has access to your database, but the access that you grant isn't for the full DB, only for specific purpose focused mostly in maintenance.

He can ask to Information Security for the credentials for another user inside the DB with even more options available, but depending in the criticality of those options, you could define more process.

  • Many approvals from different people to allow you that access.
  • Someone from Security will stay with you while you are doing your task.
  • Points of restore from the point where you start to work with the super user.
  • Passwords are one use only and are discarded once used
Improve this answer
2
  • This does not answer the question, he isn't concerted about stolen hashes, but rather an attacker replacing those hashes with his own.
    – AndrolGenhald
    Aug 31, 2017 at 20:22
  • @AndrolGenhald ooh you are rigth, I will edit the answer, thank you.
    – Tridam
    Aug 31, 2017 at 20:46
1

The above answers are correct - if they have access to the DB server and the app server it's largely game over.

However, in terms of the very specific question of them changing a users password, @TTT summed it up well:

Effectively, all the attacker is doing is changing users' passwords. This would enable the attacker to login to those users' accounts.

This is very true

As for how you protect against this, I'm not sure you should bother.

There is one possible protection here: you implement two-factor authentication! It's not protecting the DB in any way, but it does mean that just changing the password isn't enough to be able to log in as that user.

Now, it probably wouldn't help in this situation: if they had full access to the app server and the DB server they could probably disable the 2FA, or change it to something the attacker controlled. But in terms of guarding against someone changing the password hashes (the narrowest reading of the original question) this would protect you to an extent. Note that both the attacker and the real user would end up locked out (one knew the password, the other the could answer the two factor challenge), so it would still be disruptive.

Of course, there are other, better reasons fr implementing 2FA ("better" in the sense that they guard against more likely attack vectors - ones that aren't already "game over")

Improve this answer
1

I did not understand exactly what your intention is behind droping a new hash into the appropriate field. And also i can´t tell you how it is in general as there´re plenty of db-systems that handle password, userdata or encryption differently. The following options are available for the db system i do work with (postgresql):

  • the password is hashed client side and will not be plain on the server
  • the password gets a salt for each connection to prevent capturing the hash and using it for further sessions
  • certificate based encryption
  • the usual data-encryption on column or file system level
  • client-side encryption prevents that any data reaches the server unencrypted

With these precautions it should be well protected. But that depends on the database and the client (the web-app) that you did not specify.

Improve this answer
4
  • By dropping the forged hash into the appropriate field I meant that the attacker would put the hash with a known password into an user's password field that he/she wants to attack. So the user's password would basically change to the one that the attacker knows.
    – Sevron
    Aug 31, 2017 at 15:13
  • Encrypting a column seems good first, but the attacker would know how the code works, so they basically would also know where the decryption key is, so it is not really a protection. This is why I do not get why encryption at rest for data is useful in any way. If the app needs to decrypt it when it needs to use it, then if an attacker compromises the app server then the encryption is useless.
    – Sevron
    Aug 31, 2017 at 15:15
  • "the password is encrypted client side and will not be plain on the server" - Are you confusing encryption with hashing?
    – marcelm
    Aug 31, 2017 at 18:21
  • @Sevron: At rest encryption is to guard against a situation where only the DB server is compromised (e.g. a leak of a back-up or dump of the data somehow). As you say, if both the app machine and the DB are compromised, then it doesn't help much since the app needs (by definition) to be able to decrypt the data.
    – Adam
    Sep 3, 2017 at 8:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .