-
Notifications
You must be signed in to change notification settings - Fork 741
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Vulnerability - boot password removed on data restore with FDE #1323
Comments
If someone gets hold of that TWRP backup, why would they need to restore it to the device to get full access to it? It's just tar backup files. If you're wiping encryption before restoring, then of course your on-boot password will be gone. When the device re-encrypts, it will always be with the default password, until you change that. Storing password information in a backup would be just as vulnerable, wouldn't it? Additionally, if you have a lockscreen password set when you make the backup, typically that will prevent you accessing the device once you restore the backup. I don't think there's anything to be done for this. |
The point is: device should NOT re-encrypt in the absence of the force-encrypt flag, and that's what it does on first boot. Lockscreen password could be easily removed in TWRP. Storing password info in a backup would NOT be as vulnerable, because password is not stored in plain text. But the best solution should be: Not to let TWRP should to cause device re-encryption on restore. |
It's not TWRP that encrypts the device when you boot. That's Android. If the device was encrypted when you made the backup, it will automatically encrypt when you boot the device, even if storage is not currently encrypted, and even if forceencrypt is not set. If you want to prevent this, either don't back up an encrypted device (this isn't really a good option), or, once the restore is complete, navigate to /data/misc/vold and delete the "convert_fde" file. That will prevent the device from re-encrypting on boot. I don't understand how that's more secure than it encrypting with no password though, which appeared to be the topic of this issue. |
That's good to know (about 'convert_fde'). Is the file necessary for TWRP normal operation? In other words, if the file is deleted, would that prevent normal restore on an encrypted device? The difference is: if there is no such file, an attacker (with that backup) wouldn't be able to access data at all. |
That file has nothing to do with TWRP, as I already said. That's how Android knows that the device should be encrypted, and if it's not, it then makes sure that it is. I'm still not understanding how you're saying that data wouldn't be accessible. The backup itself is unencrypted data. So having access to that file means an attacker already has your information/data. Restoring it to an unencrypted or encrypted device doesn't change anything. If that file isn't there, it simply means the device won't be encrypted on boot, and your data is even more easily accessible. If it's encrypted on boot, then the device is still accessible until you set a new password on boot. I'm really having a difficult time understanding your point. P.S. As long as TWRP can decrypt data when you boot into recovery, all data is accessible regardless of the encryption status of the device. |
First, isn't there a TWRP option for encrypted backup? So, when the attacker gets the backup, he would still need to deal with decrypting (backup). My question was: suppose TWRP deletes that file. Would a user be able to normally restore data? |
The TWRP encrypted backup feature is broken and will likely be removed soon. And like I already said, that file has nothing to do with TWRP. Its existence is irrelevant, since anything on /data will be overwritten when the backup is restored. The only things that will prevent data from being restored in TWRP is either 1) an encrypted data partition that TWRP cannot decrypt, 2) an encrypted TWRP backup file where the password is unknown or can't be entered correctly (which is how encrypted backups are broken), or 3) a broken TWRP backup file. If the backup is good, and TWRP has access to the data partition, a backup can always be restored to the device. That's kind of the point of TWRP. |
@CaptainThrowback whoot. But with latest TWRP on my OnePlus2 the TWRP encrypted backup works. |
It's not possible to use several characters on the keyboard when creating an encryption password. There is currently an open issue for it. Apparently it's also relatively easy to decrypt from a PC since the encryption is relatively weak. EDIT: See here: #817 |
Sorry for OT, but it'd be great if you/whoever could expedite that notion - I spent like a week trying to fix encrypted backups a few months back! Even just a theme change to remove the option would be great. |
Boot password removed while doing full device restore after factory reset.
Steps to reproduce: device encrypted via adb with separate boot and lockscreen passwords
It happens on Oneplus 5 and Lenovo Zuk Z2 both running Oreo.
If someone gets a hold of that TWRP backup, they would be able to perform the above steps to get full access to data.
The text was updated successfully, but these errors were encountered: