1
$\begingroup$

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
$\endgroup$
6
  • 1
    $\begingroup$ 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. $\endgroup$
    – DannyNiu
    Nov 30, 2021 at 5:08
  • $\begingroup$ 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? $\endgroup$
    – DannyNiu
    Nov 30, 2021 at 5:11
  • 1
    $\begingroup$ 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. $\endgroup$
    – fgrieu
    Nov 30, 2021 at 5:26
  • $\begingroup$ @DannyNiu Agree that prepared statements can prevent the injection attack. However I assume this measure fails in this scenario. Could you advise some mitigations? $\endgroup$
    – xqOP
    Nov 30, 2021 at 6:49
  • $\begingroup$ @fgrieu Do you mean including ID/Username in the encryption key? $\endgroup$
    – xqOP
    Nov 30, 2021 at 6:51

1 Answer 1

3
$\begingroup$

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.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.