Are encryption keys are compromised and should they be changed?

[joepagan]

Thanks so much for your efforts in researching and patching this.

On your blog post your say:

The exploit allows a malicious user to see the contents of your config.php and config.dat file. From this they can obtain your encryption keys to log directly into the backend without a user account.

This suggests that encryption keys are compromised, should they also change? They are not mentioned in your post. When looking in the config tool it says:

Important! If there is any encrypted data in the database, changing the encryption key will lead to impossibility to decrypt the data.

What data could potentially be unaccessible here?

Additionally, if your .dat file is outside of the public folder, would they still be able to see the contents of it?

Lastly, should we presume that admin account passwords are compromised too?

[patrickheeney]

@lexbi

This suggests that encryption keys are compromised, should they also change?

This was a challenging issue to try and solve with an easy solution. There are actually multiple encryption keys at play here. There are CONFIG_KEY1 and CONFIG_KEY2 which are encryption keys used to encrypt the dat file. There is the config key which is the real encryption key for all data set inside config.dat.

Previous to this patch all data used that config key. This is a problem because we can't change the config key or the dat file keys as that would invalidate all existing data and make it inaccessible as you noticed.

Since we can't change any keys, the only thing I could do to address this is create a new key COOKIE_SALT that will be use to change the authentication keys since we can safely invalidate them.

In a perfect world all of these keys should change, but unfortunately we can't really do that in this case without a massive engineering effort.

What data could potentially be unaccessible here?

All of your user passwords will no longer work and you won't be able to access encrypted database data like last 4 of the cards, potentially authorize ids, etc.

Additionally, if your .dat file is outside of the public folder, would they still be able to see the contents of it?

Yes, with the hack they can access any file path on the system.

Lastly, should we presume that admin account passwords are compromised too?

Sort of. Basically the salt used to encrypt the passwords is leaked. This opens up the possibility of a brute force attack since they now know the salt used to generate the passwords. As I mentioned above, I don't have an easy way to solve this design flaw.

One idea I may explore is locking down the admin to only certain IPs. Limiting login attempts and locking user accounts. This will help mitigate some of the brute force attack but sadly won't solve it.

[joepagan]

Cheers for getting back to me, they're all fair points.

On your last point you could additionally add an additional http auth login for that url, a bit annoying but you could make the user/pass simple enough (for example user/pass) would probably be enough to stop anyone trying a brute force.

[patrickheeney]

On your last point you could additionally add an additional http auth login for that url, a bit annoying but you could make the user/pass simple enough (for example user/pass) would probably be enough to stop anyone trying a brute force.

Yup, that could work to help deter it as well.

In a perfect world all of these keys should change, but unfortunately we can't really do that in this case without a massive engineering effort.

I will expand on this a bit and provide some insight into some paths to take to be able to change this. In order to change your keys without losing data you will need to decrypt them with old keys, set new keys, and re-encrypt the data. This would likely be easy enough for the database columns.

However the problem is the password as we can't decrypt it. A system would need to be built to authorize the key using the old password, if it matches, create a new hash. Would need an extra db column to hold the state of which encryption method is being used. After some time you should only authenticate with the new method and force a password reset for the rest. Or just force the reset from the start.

Finally you would need to re-encrypt the dat file using new keys and store them in your config.php.

Massive was probably not the right word to use above, but rather a lot more time consuming then I have. It can technically be solved.