Oddbean

#GrapheneOS uncovers leaked documentation for smartphone exploits by Cellebrite. XRY and Cellebrite say they can do consent-based full filesystem extraction with iOS, Android and #GrapheneOS. It means they can extract data from the device once the user provides the lock method, which should always be expected. They unlock, enable developer options and use ADB. Cellebrite's list of capabilities provided to customers in April 2024 shows they can successfully exploit every non-GrapheneOS Android device brand both BFU and AFU, but not GrapheneOS if patch level is past late 2022. It shows only Pixels stop brute force via the secure element. https://image.nostr.build/8e893edfdc5699a979ca586def3e2b20e0179013da3e4cc5b57522870e2982c6.jpg https://image.nostr.build/3ef47e97cddad7dc02cdbf6778e484aac415be896ee86053aa7452db791d2934.jpg Cellebrite has similar capabilities for iOS devices. This is also from April 2024. We can get the same information from newer months. In the future, we'll avoid sharing screenshots and will simply communicate it via text since to prevent easily tracking down the ongoing leaks. https://image.nostr.build/17f7e488f9093601c0dff65bdb1274509a91d26362669decc0b006b39e132e58.jpg https://image.nostr.build/0ef4e9dcfc1063fbb35c516e134c56df8348195810446128a4ffc6219bdd44e8.jpg Pixel 6 and later or the latest iPhones are the only devices where a random 6 digit PIN can't be brute forced in practice due to the secure element. Use a strong passphrase such as 6-8 diceware words for a user profile with data you need secured forever regardless of exploits. Pixels are doing a bit better on the secure element front and iPhones are doing a bit better against OS exploitation, but not by much. As always, this shows the importance of our auto-reboot feature which gets the data back at rest after a timer since the device was locked. Our focus in this area is defending against exploitation long enough for auto-reboot to work. It's set to 18 hours since the device was locked by default, but users can set it as low as 10 minutes. Since around January, we massively improved security against these attacks. By default, our recently added USB-C port control feature disallows new USB connections in AFU mode after the device is locked and fully disables USB data at a hardware level once there aren't active USB connections. Users can set it to also do this in BFU or even when unlocked. Users with a high threat model can fully disable USB including USB-PD/charging while the OS is booted to only allow charging while powered off or booted into the fastboot/fastbootd/recovery/charging modes. GrapheneOS on 8th gen Pixels is ideal due to hardware memory tagging. Consent-based data extraction (FFS) is not in the scope of what we're trying to defend against beyond shipping our secure duress PIN/password implementation to replace insecure approaches via apps. Data users can backup is inherently obtainable with consent, which is nearly all. Within the past 24 hours, there has been an attack on GrapheneOS across social media platforms misrepresenting consent-based data extraction as GrapheneOS being compromised/penetrated. The person doing it is pretending to be multiple people and falsely claiming we covered it up. GrapheneOS is the only OS having success defending against these attacks. We could do more with a successful hardware partnership such as having encrypted memory with a per-boot key instead of relying on our kernel memory zeroing combined with auto-reboot and fastbootd zeroing. New versions of iOS and Pixel OS often invalidate their existing exploits, but devices in AFU are stuck in AFU mode waiting for new exploits. Random 6 digit PIN is only secure on a Pixel/iPhone and only due to secure element throttling. Use a strong passphrase to avoid this. If you wonder why duress PIN/password is taking so long, it's because we aren't doing it for show like existing implementations. It needs to work properly and guarantee data will be unrecoverable with no way to interrupt it. Slowly rebooting to recovery to wipe isn't acceptable. See https://x.com/GrapheneOS/status/1775305179581018286 for our thread covering the firmware improvements we helped get implemented in the April 2024 release for Pixels. It doesn't currently really help the stock Pixel OS because they haven't blocked the OS exploits that are being used yet but it helps us. Our hope is that our upcoming 2-factor fingerprint unlock feature combined with a UI for random passphrase and PIN generation will encourage most users to use a 6-8 diceware word passphrase for primary unlock and fingerprint + random 6-digit PIN for convenient secondary unlock. Cellebrite documentation and has stated they'll upload future versions of it if you want to look at the rest of it: https://discuss.grapheneos.org/d/12848-claims-made-by-forensics-companies-their-capabilities-and-how-grapheneos-fares/4 We have info on XRY, Graykey and others but not the same level of reliable details as this.

Cellebrite, XRY and others know about GrapheneOS and they don't like us. They talk about GrapheneOS in their advertising media and claim to support it but they only support extractions where the person gives away the device credential. We have copies of Cellebrite's updated government and law enforcement brute force / data extraction exploit documentation. Fully supported GrapheneOS devices (Pixel 6 and above) cannot be brute forced by them. GrapheneOS with a Pixel is the ONLY mainstream device they can't beyond up to date, modern iPhones (subject to change). GrapheneOS has additional features beyond the defaults to make this even harder which aren't mentioned in the docs. We plan to add more.

Make sure these guys identities is kept a secret! nostr:nevent1qqst3mtuajfjrhmtr5sls78ycp5jh96tz92mfdl3x7d3mwvvv7cerqspr9mhxue69uhhqatjv9mxjerp9ehx7um5wghxcctwvspzps26tfjesmn6ksf5mm36hpf9fkjut49sfeutfutvs2phrykn25v9qvzqqqqqqykvkmq2

This is huge! The leak. How GrapheneOS prevails. And how you guys keep pushing the boundaries of smartphone security even further. I'm so looking forward to the 2FA unlock feature and keep dreaming about you securing a hardware partnership! In the meantime, I will donate. Truly thank you for your work!

When you say "consent-based" do you mean you were able to prove it but you got consent from owners before you tried to exploit their devices? Or is it a specific type of attack I am not understanding?

Consent based extraction means that the owner of the device provided consent to extract the device by providing their password to unlock the phone. No OS can't protect against someone willing to do that obviously, so it's out of our scope.

Got it, I thought this was a report about a new attack, it is just denying some misinformation flying around that I haven't seen anyway. 🤷 Still, its cool to see that once again, GrapheneOS is 10 steps ahead everyone in the game. So for other devices, there is nothing to prevent brute force cracking but for Graphene (and pixel 6+) the secure element slows the attack down. Is that correct?

The secure element is the core piece that protects against brute force attacks and physical attacks. It is what enforces brute force throttling and also makes tampering far more difficult. We also use it for other features like in Auditor. It is a hardware requirement of GrapheneOS to have one and for the device to support an alternative OS using it. That is one of several reasons we use Pixels and this note is an example of the benefit.

If someone wanted to brute force a device that is BFU, they need to exploit that secure element in addition, rather than just the phone. Very old Pixels we do not support anymore have secure element exploits as per the Cellebrite documentation.

You're misunderstanding the post 😅 The documentation is saying modern Pixels (especially with GrapheneOS) cannot be brute forced and they only work if users give their passwords away. Cellebrite are having substantial trouble against us, they can't break into any device we support, nor GrapheneOS. GrapheneOS is mentioned in the documents (see pictures) and is the only OS mentioned separately to Android as their standard choices don't work.

If your threat model doesn't account being forced by someone to unlock with your biometric then it is a good choice. It also prevents someone seeing your PIN which prevents certain types of shoulder surfing. We do not support face unlock on supported Pixels as we do not think they are secure enough. The older generations had dedicated face unlock hardware the current Pixels don't have. Our second factor unlock will do a combination of fingerprint + PIN. That way they are two separate types of authentication (something you are and something you know).

Levando a sério endurecimento da segurança do seu telefone contra todo tipo de atacante. Importante pra quem usa celular como hardwallet e tem alguém com "Cellebrite" no seu modelo de ameaça. nostr:note1hrkhemyny80kk8fplpuwfsrf9wt5ky24kjmlzdumrkuccea3jxpqg43k5l

Personal note: Companies selling exploits for smartphones talking about #GrapheneOS in their internal documents and their limitation and failure in targeting the OS is only further evidence of the success of our recent mobile security and privacy work. A multi-million dollar industry of companies exist just to discover and sell exploits for devices. Cellebrite is only one of many. Attacks by actors of such capabilities is what GrapheneOS aims to protect against, like we had done earlier this year, where we discovered vulnerabilities these companies took advantage of and disrupted their fun with improving and adding new security features. There is more to come. We may not be as large as they are, but think about why they have to say our name and why they separated us from Android and iOS. What we do is significant and impactful. We don't ignore the competition or be deliberately vague or misleading about capabilities like these companies have been about us. Digital forensics is such a valuable (and in my opinion, undervalued) cyber security skill but it is a shame these titans of the industry are all secretive and protective about their work. Some go as far as to mislead the public. Transparency and co-operation is the most valuable trait in the realm of digital security and companies like these shouldn't get a waiver. I could have so much more to say including about how these companies' software are often designed too deliberately simple or complicated to make you depend on them and give them more money. Tools like Cellebrite are so easy to navigate and use that it feels like it's designed that way to not create forensics experts that can end up doing work themselves, and that other tools are deliberately complicated to faciliate to customer to buy their training. If you want to hit companies like these where it hurts, then try learning DFIR, learn mobile forensics, and do it without selling out to them. Reduce what they can sell to you and break the gatekeeping the sector has. nostr:nevent1qqst3mtuajfjrhmtr5sls78ycp5jh96tz92mfdl3x7d3mwvvv7cerqspz3mhxue69uhhyetvv9ujumn0wd68ytnzvupzps26tfjesmn6ksf5mm36hpf9fkjut49sfeutfutvs2phrykn25v9qvzqqqqqqym8r59g

> It means they can extract data from the device once the user provides the lock method, which should always be expected. They unlock, enable developer options and use ADB. No wonder you can extract data if the user provided you physical access to an unlocked device. What's the news?

There isn't. We're just posting a review on these leaked details to help dispel false claims about GrapheneOS being compromised by Cellebrite and also advise the general public what these companies are up to. The documents tell a bigger picture that we are one of the only platforms actually protecting against attacks on devices by users that don't provide the passphrase, as what the images tell.

I was requested to make a glossary for the terms so here they are: AFU: After First Unlock Cellebrite refers to devices AFU as a device where it is in AFU state where they do not know the user's credential. If it is known or brute forced, they use the term 'Unlocked' instead. AFU support without Brute Force could imply a unique exploit to unlock, like IPR or a lockscreen bypass. BF: Brute Force BFU: Before First Unlock A 'BFU Extraction' on the table is a type of extraction for a very small amount of BFU state accessible data only. It doesn't mean they can extract the entire device. Using a brute force to unlock the device would turn it into Unlocked. FBE: Filesystem-Based Encryption (Encryption Android and iOS uses) FDE: Full Disk Encryption (Android FBE is really a form of FDE, but they use FDE to refer to the non-filesystem-based dm-crypt encryption from older Android versions.) FFS: Full File System extraction (OS data, data of current user, app data, files and more). SPL: Security Patch Level ('Up to {date} SPL' means it works on versions BEFORE that date) Supersonic BF: Supersonic Brute Force IPR: Instant Password Retrieval (iPhone specific exploit) nostr:nevent1qqst3mtuajfjrhmtr5sls78ycp5jh96tz92mfdl3x7d3mwvvv7cerqsppamhxue69uhkummnw3ezumt0d5pzps26tfjesmn6ksf5mm36hpf9fkjut49sfeutfutvs2phrykn25v9qvzqqqqqqynge4jw

#GrapheneOS receives fourth Android Security Acknowledgement of the year. This time we are credited for moving wipe-without-reboot to the stock OS. CVE-2024-32896 which is marked as being actively exploited in the wild in the June 2024 Pixel Update Bulletin is the 2nd part of the fix for CVE-2024-29748 vulnerability we described here: nostr:nevent1qqsw5mj0jlf4e7jscd5yxnxjls0nscl79yjcktghx5kx0tqeaunp0zspzpmhxue69uhkummnw3ezumt0d5hsygxptfdxtxrw026pxn0w82u9y4x6t3w5kp883d83djpgxuvj6d23s5psgqqqqqqs545s2v None of this is actually Pixel specific. Bulletin: https://source.android.com/docs/security/overview/acknowledgements Attribution to us: https://source.android.com/docs/securi CVE-2024-32896 and CVE-2024-29748 refer to the same vulnerability of interrupting reboot for wipes via the device admin API, which applies to all devices. CVE-2024-32896 is a full fix in AOSP as part of Android 14 QPR3. It's not at all Pixel specific. This is being widely incorrectly reported in tech news coverage. Pixel Update Bulletins are almost entirely patches for vulnerabilities which apply to other devices too. Android Security Bulletins are the list of what other OEMs are required to fix, not the full list of patches. We explained this in our previous thread: https://grapheneos.social/@GrapheneOS/112204437363495338 CVE-2024-29748 was a mitigation for the issue implemented in the Pixel bootloader. Full solution is implementing wipe-without-reboot, which is now a standard feature in Android 14 QPR3 released as part of AOSP. Our 2024052100 release backported the upstream wipe-without-reboot feature being shipped in the June 2024 release of Android (Android 14 QPR3): https://grapheneos.org/releases#2024052100. We extended it to make it more robust via extra redundancy in our 2024060400 release: https://grapheneos.org/releases#2024060400. There were 2 main issues: 1) memory not wiped when booting firmware-based fastboot mode, allowing exploiting it to get previous OS memory 2) AOSP device admin API depends on reboot-to-recovery to wipe before Android 14 QPR3 Neither of these issue is being fixed outside Pixels yet. Each month, Android has a new version released. These are the monthly, quarterly (QPR) and yearly releases. The baseline monthly security patches are NOT the monthly releases of Android. They're backports of a SUBSET of the patches with High/Critical severity, not all patches. Most devices only ship the backported patches to older Android releases (12, 13 and 14). Pixels ship the monthly, quarterly and yearly releases. Other devices will mostly get the 2nd vulnerability fix when they update to Android 15. They'll have to fix the 1st issue on their own. We have a thread about forensic company capabilities at: nostr:nevent1qqst3mtuajfjrhmtr5sls78ycp5jh96tz92mfdl3x7d3mwvvv7cerqspzpmhxue69uhkummnw3ezumt0d5hsygxptfdxtxrw026pxn0w82u9y4x6t3w5kp883d83djpgxuvj6d23s5psgqqqqqqsa8r988 based on leaked Cellebrite documentation. Shows GrapheneOS does a much better job than iOS/Android blocking exploits and only Pixel 6 and later or iPhone 12 and later successfully stop brute forcing.

Here is the initial post and screenshots from me where you can see that GrapheneOS is trouble for them if you missed it: nostr:nevent1qqst3mtuajfjrhmtr5sls78ycp5jh96tz92mfdl3x7d3mwvvv7cerqspzpmhxue69uhkummnw3ezumt0d5hsygxptfdxtxrw026pxn0w82u9y4x6t3w5kp883d83djpgxuvj6d23s5psgqqqqqqsa8r988

It means they can only extract the device if the owner of the device is giving the person with Cellebrite the password to their device. Your pixel would not be able to be brute forced. The secure element helps in stock OS and GrapheneOS.