• General

  • Exploit of device after first unlock to obtain data that isn't at rest

Apps like Wasted perform the factory reset via recovery - they aren't the best way to perform a factory reset, nor are they useful in duress situations. More than likely performing a factory reset like this doesn't clear data the way a typical power off should do.

GrapheneOS developers appear aware of that, as the upcoming duress PIN feature will reset in a different, unique method of factory resetting without recovery so it will actually work against duress.

This shows once again that turning the phone off completely, having an extremely strong passphrase and/or having a low auto-reboot time is the best way to overcome it. Apps like Wasted are just easily bypassed security theater. Judging by how MSAB made a whole video just about the app itself, then the app must have been making traction somewhere, which is quite surprising.

    final

    Yes, apps like wasted are easy to bypass but if you've seen the video what I'm more concerned about is that MSAB has been able to exploit fastboot mode to run RAM dumps + performing bruteforce attacks. I wish there was a way for the fastboot mode to allow for some RAM clearance. Also the wasted app got traction since in Europe most criminals use it as a anti-forensic measure against the cops. Also a known cryptophone company active in Europe was using the wasted app on their devices, so a lot of law enforcement came in touch with the wasted app which resulted in forensic companies to find measurements againt this app.

        Interesting. If this attack is indeed a threat in real world situations, not just controlled lab conditions, this would certainty be something worth following / looking into.

        This may be a stupid, or too specific, question - but does anyone know if this kind of attack would be able to brute force other profiles/users? - if the main profile has a password with extremely high entropy (assume it would take too long to brute force, even with the best hardware), but the secondary profile/profiles have simple PINs with very low entropy? Assuming the phone was recently turned off / rebooted of course.

        And would it make a difference if the separate profile/user was unlocked and running when the phone was turned off / rebooted?

          There are forms of emergency reboots which don't wipe everything from memory and we're looking into disabling those. Auto-reboot doesn't do one of those emergency reboots, it does a regular reboot which goes through the standard process of tearing stuff down in the OS and triggers and bunch of memory wiping.

            Hathaway_Noa To my knowledge RAM dumps can be performed quite trivially with differing methods per device, some OEM's let you just do it without trouble, like Samsung you type a specific combination in the dialer. Pixels have been RAM dumped. You can find people discussing themselves RAM dumping their pixels on forums to attempt finding the credentials (I also found one trying on a GrapheneOS phone too funnily enough) and other sites with some searches online. This is pretty much MSAB just taking advantage of emergency reboot weaknesses more than any serious exploitation.

            roamer4223 This may be a stupid, or a too specific, question - but does anyone know if this kind of attack would be able to brute force other profiles/users?

            Yes, providing the user authenticated once, which keeps the secrets in memory.

            roamer4223 if the main profile has a password with extremely high entropy (assume it would take too long to brute force, even with the best hardware), but the secondary profile/profiles have simple PINs with very low entropy? Assuming the phone was recently turned off / rebooted of course.

            Realistically they should need to unlock the owner profile first.

            roamer4223 And would it make a difference if the separate profile/user was unlocked and running when the phone was turned off / rebooted?

            If the phone was turned off the right protections should be in place for both the owner and the secondary profile.

                      GrapheneOS That's interesting, I had never considered there are emergency reboots that are different to regular ones. Could things like holding down power + volume be considered as such? I assume they're more along the lines of 'pulling the plug' so to speak, whereas a regular reboot actually does 'clean up after itself'. If those metaphors work anyway.

                      Very good info, thanks as always! Good to know your looking into disabling the emergency reboots as well

                          final Thank you for a very detailed and understandable answer to my questions, really appreciate it. I suspected it would be somewhat similar to how you explained but it's very nice to have it properly answered in a concise and comprehensible way. Thanks again!

                            missing-root
                            Personally, not sure about that. Though on the same lines I do believe GrapheneOS is working on a duress feature that will erase your device after entering a specific pin code, if I am not mistaken.

                            I see that 'Wasted' has more features from a glance at their Github. Though looking at it - I would be extremely hesitant to use it myself, even if that part of it was implemented correctly, as it uses some very dangerous permissions that could end up possibly increasing your attack surface I would imagine. To be fair I did only have a very quick look so I may be wrong.

                                ahh I just saw @final mentioned this duress feature GOS is working on earlier in this thread.

                                Also wasn't saying anything against the devs of 'Wasted', I'm sure they know more than me. Personally though, I will wait for the Graphene team to implement their duress feature

                                roamer4223

                                Could things like holding down power + volume be considered as such.

                                No. There are emergency reboots for situations like overheating. A kernel panic is also a different code path to a clean reboot but not the same as an explicit emergency warm reboot.

                                  missing-root Wasted is using the device management API to trigger a factory reset via rebooting into recovery. This is inherently insecure because you can hold volume down to reboot to fastboot mode instead. It's inherently insecure and we're always told people that these panic/duress apps don't work correctly...

                                    roamer4223 Our experimental duress feature works properly because it wipes data without requiring a reboot to recovery. It could also be exposed as optional a panic button. The existing implementations of these features elsewhere are known to not work properly since they require rebooting to recovery for a normal factory reset which was never intended to be used in this way.

                                      final Being able to RAM dump from fastboot mode is guarded by a check for the device being unlocked. If they're able to do it without being unlocked, that's an exploit, even if it's a trivial one. If the flaw being used in fastboot mode was known, it would be fixed in a firmware update.

                                      There shouldn't be relevant data left in memory after a normal reboot to fastboot mode, but data can persist through reboot from a kernel crash or similar situations. Overheating is also known to trigger an emergency reboot.

                                          @final

                                          Yes, providing the user authenticated once, which keeps the secrets in memory.

                                          Secondary users can be put back at rest. For both the main user and secondary users, encryption keys aren't available to the OS after unlock but they are in non-OS memory.

                                            Hathaway_Noa

                                            bypassing the secure element.

                                            they start bruteforcing the password of the device bypassing the secure element of the pixel device (titan m)

                                            They can bypass secure element by booting into the fastboot mode when the phone has been previously in AFU, after that they dump the RAM since the RAM hasn't been cleared yet and bruteforce the keys giving them a password.

                                            They aren't bypassing or exploiting the secure element. The device wasn't at rest so the keys were usable by the OS. They're brute forcing against what's still in memory to get the password.

                                                GrapheneOS changed the title to Exploit of device after first unlock .
                                                GrapheneOS changed the title to Exploit of device after first unlock to obtain data that isn't at rest .