Score:1

Can attacker steal data from AES encrypted table without knowing the key?

in flag

I think of a situation that attacker can steal data from AES encrypted table without knowing the key. I tried to search on internet but found nothing about this(may be I were not using the correct keyword), really appreciate if any one can shed some light on it.

Assuming that the table is encrypted with same key but different IV:

  1. Attacker signs up for a new account in an application normally.
  2. Application creates the account and inserts a new row (2nd row in table below)
  3. Somehow attacker found a vulnerability in application to run SQL injection
  4. By SQL injection, attacker replaces cipher of his row with Victim's value e.g. aes_cipher_2 -> aes_cipher_1 and iv_2 -> iv_1
  5. Attacker signs in his own account
  6. Attacker goes to the profile page, then application decrypts Victim's data (aes_cipher_1) and shows the plaintext to him.
ID Username Address IV
1 Victim aes_cipher_1 iv_1
2 Attacker aes_cipher_2 iv_2
DannyNiu avatar
vu flag
Good for thinking experiment, but some best practices should be advised to readers: Use prepared statements and bind variables in SQL queries to avoid injection; Encrypt database at filesystem level, data table level encryption are too subtle to be effective.
DannyNiu avatar
vu flag
Now back to the question. Are you looking for mitigations (which I've given some in the 1st comment)? Or do you want something practical, like an attack demonstration?
fgrieu avatar
ng flag
DannyNiu's advice is good. Yet be aware that «Encrypt database at filesystem level» does not help solve the question's issue. Authenticated encryption (AES-GCM of the like), and including fields _ID_ and _Username_ in the authenticated data, goes some way in that direction. But at the end of the day, if the attacker gets enough foot in your system to read, much more alter the database, or you need file-system level encryption, then you are in huge trouble. The primary objective should be to avoid that. Database or file-system (authenticated) encryption should be an _extra_ security measure.
in flag
@DannyNiu Agree that prepared statements can prevent the injection attack. However I assume this measure fails in this scenario. Could you advise some mitigations?
in flag
@fgrieu Do you mean including ID/Username in the encryption key?
kelalaka avatar
in flag
Yes, [this is proposed against CryptDB encrypted database](https://ieeexplore.ieee.org/abstract/document/7034869/), you may even find the SQL script there. You need integrity and authentication to mitigate...
Score:3
ng flag

Yes the attack in the question could work, under the stated assumptions. AES-CTR encryption of database fields is ill-advised, for this reason, and others.

One possible partial mitigation is using authenticated encryption, for example AES-GCM, and including the ID and Username field in the authenticated data. The net effect is that encrypted data (in an Address field) altered in any way, including dissociated from the original ID or Username or IV, will fail decryption with cryptographic certainty.

Authentication will increase the size of the cryptogram (the data in an Address field) by the like of 12 bytes (that's a parameter), regardless of the size of the ID and Username field. The slight size increase can be mitigated by making the IV part of the cryptogram, which is advisable anyway if only because it makes it less likely that the link between cryptogram and it's IV gets lost. Putting the IV at the beginning of data encrypted by a block cipher is the standard practice anyway.

Authenticated encryption gives much better protection than deriving the AES-CTR key from a master key and Id or/and Username: if adversaries can manage to change CTR-encrypted data and observe the behavior of some IT system on the deciphered data, then it's to fear they can learn something about the data. For example, if the byte '<' in the deciphered data causes some recognizable behavior, then it takes like 30 attempts per characters to decipher; just like in movies. Authenticated encryption protects against this, derived keys do not.

I'm far from stating authenticated encryption of confidential database entries is foolproof. It does not give protection from many insiders. It does not even provide good protection for backups, because all too often the key will be in the backup (for this reason I advocate encrypting database backups with public key and hybrid encryption). And authenticated encryption can often be circumvented. For example, with read access to a database that includes a hashed password, attackers would often be able to mount a password search that would find the passwords of some users, then log in as one of these users. And with write access, attackers could change password hashes to that of a password they know, and log in as any user of their choice.

Again: cryptography should not be the first line of defense for a database. It should not be read-accessible, much less write-accessible by attackers. And it the database uses a text language for queries (a design mistake entrenched in current IT practices, that allowed and still allows countless attacks, and causes huge wastes of computing resources in query generation and parsing), then at least a carefully designed and reviewed query-generation software layer must enforce separation of data from the query language.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.