final

  • Joined Jul 24, 2022
  • f1nal:matrix.org | new npub: npub1hxx.3q4sg75y

    • Edited

    quepasabebe I'm kinda curios of how? In the documents it shows that the accused had been sharing internet from his iphone to the pixel and been connected to wifi. What was the weak point? Signal? His hotspot through the iphone or maybe the router at home?

    User error.

    All of those things wouldn't ever be a factor in device compromise. They can't read signal messages, that's kind of why they need to extract the phone in the first place. Hotspot / WiFi access point history is also a common forensic source, you can access them on both devices easily.

    The document openly claims it can't get into a Google phone in normal circumstances:

    "Det hittades även en till Googletelefon inne i själva bilen (punkt 3) men denna har i skrivande stund juni 2024 inte gått att extrahera eller knyta till brukare."

    MACHINE TRANSLATION: Another Google phone was also found inside the car itself (point 3), but this has not worked at the time of writing in June 2024 to extract or link to users.

    This conclusion matches the expected outcome of our Cellebrite document sources exactly.

    The document claims they got into it 'manually', and the pictures show them taking a camera to the phone's screen instead of screen recording. Worth noting screen / display capture for unlocked devices is a standard Cellebrite feature but they didn't do it, weird why they didn't if they had the option. I guess it's practice over in Sweden.

    IT-forensiker har gått in i telefonen manuellt och fotograferat användarens eget alias

    MACHINE TRANSLATION: IT forensics have entered the phone manually and photographed the user's own alias

    If it was done manually they evidently had knowledge of the credential or they were consented. Targeting of other people involved, CCTV, forensics of fingerprints on the display, sharing the PIN with the iPhone, tons of potential factors would have led up to his failure.

    Quite frankly I personally don't care about the heaps of trouble that scumbag gang bangers and drug dealers get into. They deserve prison and I am happy they've been arrested. I'm only making this response to debunk before people get concerned about it. If they were talking about all their acts on the iPhones they had by the looks of it then clearly they're not the brightest and GrapheneOS wouldn't protect them and hopefully it stays that way. There's tons of factors that would have brung this person down even without the phone's data I'm sure.

  • horde https://paraben.com/e3-forensic-platform-3-6/ (version 3.6 SUMMER 2023)

    They mention GrapheneOS in every new release of their software.

    Paraben are not a serious digital forensics vendor. Their capabilities are just logical, consent (requires password) extractions. Logical extractions are the least capable extraction type and is equivalent to just backing up your device when plugging it into a PC. They don't even have full file system extractions like what Cellebrite or MSAB have. You can see "Partial File System“ on their list. They don't have exploits.

    They also have a video on YouTube about their GrapheneOS "support" which shows you how limited their extraction scope is: https://www.youtube.com/watch?v=FaK9Q8VVysk - Worth noting Cellebrite gives you the same amount of information by plugging a GrapheneOS device that has no password into a UFED and doing a generic logical extraction.

    It's not worth being concerned over. There are bigger industry players to focus on. Everything they mention they can extract for a GrapheneOS device where they need to know the password is the bare minimum as far as mobile forensics is concerned.

    • Edited

    evalda What does it mean? I am reading "BF No" as secure element time limiter is holding up and prevents them brute forcing all possible PIN combinations.

    If that's the case, what does "BFU Yes" mean? How they can extract the data in BFU state without knowing the PIN and without an ability to brute force it?

    BFU Yes and BF Yes: Can extract the limited BFU- available data and could brute force the device to try and turn it Unlocked. Whatever the 'Unlocked' extraction capabilities are on the table follows afterward, but obviously you should expect it to be FFS.

    BFU Yes and BF No: Can BFU extraction but not brute force to unlock the device.

    AFU state in Cellebrite documents mean the device is in AFU state but is not unlocked / consent. If there is no BF support but AFU locked support is available, it implies a device has an exploit that can bypass. Example of this could be old lockscreen bypass vulnerability or iPhone IPR if there is no bruteforcing required for it.

      • Edited

      @evalda A BFU extraction doesn't mean a typical extraction when the device is BFU, rather it is a special type of extraction to get a limited amount of data available by a device in BFU state. It's a weird misnomer and it could be more specific. If a forensics tool can brute force a device successfully from BFU, then they are performing an Unlocked extraction since they unlocked the device first.

      With BFU you're booting into the operating system to decrypt it. A very small footprint of the OS is encrypted by the device and not by a user's own credentials.

      A BFU extraction is to extract that particular data. Usually it provides very limited information about the OS and other device-encrypted data like app APKs (user/app data cannot be seen, only that the app is installed on a profile)

      As described in the document they have a method of extracting that data for the stock OS, but not GrapheneOS.

    • stereo3441 Cellebrite says Supersonic Brute Force is about 40x faster than the traditional brute force speed.

    • You will need to elaborate your issue. The phone always goes to BFU state when it is powered off, it doesn't return to AFU unless you unlock the device. It is possible you are confusing this with something else.

    • @Volen and @Tryptamine : I removed some comments about the project members in your replies. I understand they are positive comments and we aren't going to fault either of you for supporting us, it is just best wishes of the team to avoid developer gossip. :) Hope you both understand this. Likewise, it would be best for this thread to avoid being diverted off the thread topic.

      While it may appear to either of you sometimes that we come across as critical and grill things (and you like that), it really isn't meant to sound hostile except when what is being discussed is hostile towards security and privacy. Cyber security is an extremely important subject to get right and we don't stay silent about things when something is misleading, unsafe or malicious. It is a symbolic part of security culture. Critique and scrutiny is part of revealing a problem, which is then a part of introducing innovation. Just accepting problems that people have now means no one would bother to actually tackle the problems they have. It is why we have many features first or we are the leading example for security features after all.

      The feeling of security is really easy to sell to people, and there are people who make their name off of selling or getting fame from a false image of security expertise. When people put their trust in false security, it endangers them and the people around them. As people who work in security and privacy on a daily basis, anything that goes against those values or takes them away from people is unacceptable and it would also be ironic if we didn't do anything about it either. We do our best to avoid being negative. :)

      • Locked as solved, glad to see things are working!

        • Edited

        GrapheneOS uses MTE by default for the OS components on Pixel 8 and later and there is a per-app toggle to use MTE with apps you install. The GrapheneOS MTE implementation is far more stable and complete. The Vanadium web browser also uses MTE and is the only web browser that incorporates MTE in a production environment. It has been around for a while.

        MTE is used in hardened_malloc and is a massive security benefit overall. It is a mandatory requirement for all newer devices to have MTE support now before GrapheneOS will support them.

          • Edited

          News have only discussed Google desiring to design their own processors with a manufacturer like TSMC rather than working alongside Samsung for their Tensor processors. There is no suggestion to say everything will be inside one chip (which is also a very inefficient way to manufacture), but rather that Google desire to just have most of the components designed by them and manufactured. They would still be separate components, but, x86 platforms often have many physically separate processors manufactured by many OEMs but still receives many reports with firmware vulnerabilities in Wi-Fi, GPU, UEFI. Just having them as separate, removable components is not a security benefit.

          A component being on a separate chip is indifferent to whether it's isolated. In order to be isolated, the OS needs to not trust the drivers of the hardware being used. Earlier generation supported devices before Pixels had Wi-Fi and Bluetooth implemented on a separate SoC and that was less contained in comparison to a Tensor Pixel device. The vast majority of attack surface in these components are down to the software, not the firmware. The issues in vulnerabilities like these are from the OS trusting hardware drivers too much.

          Just because they also appear to be in one chip doesn't mean they all work like that. Newer Snapdragon Samsung devices put the baseband, processor and memory together in one component, but they are better described as being layered on top of one another to save space. Tensor processors are made in co-operation with Samsung and have a Samsung modem, while they are in separate locations on a motherboard it doesn't change the security, they're all connected to one another on the same board. An IOMMU is what the isolation is for.

          Look at CVE-2023-28582... (long scenario)

          It is easy to make up imaginary scenarios about exploitation but they are far from capable in reality. Your scenario would need a chain of exploits down to multiple layers of the OS or firmware to accomplish which is extremely unlikely. Even if memory corruption is present you would need additional work and further exploitation elsewhere to take advantage of the initial exploit in such a way that would allow a memory dump, exfiltrating that memory dump, making it undetectable, making it zero-click, reliable, and persistent (if you need it to be) among other things. Keeping such a sophisticated exploit chain is a gigantic pain with how much operating systems, drivers, and devices change, especially when you consider that many GrapheneOS changes are just security enhancements.

          Android (and GrapheneOS) uses a defence-in-depth security model, there are security measures all around the OS from mandatory access controls, sandboxing, use of least privilege, anti-persistence measures, exploit protections and mitigations. GrapheneOS improving them further with hardened_malloc, adopting memory tagging, prevention of dynamic native code execution and a lot more makes this less reliable than you think it would. Sometimes bugs considered vulnerabilities from the upstream could have happened on GrapheneOS, but because of defences added elsewhere it made exploitation of that bug impossible even when the bug is present. Finding a bug and being able to exploit that bug are two very different things in terms of difficulty. Where an exploit successfully gets through one security measure, it has others it needs to break if it needs to have further goals than what the current exploit already met.

          This reply isn't meant to downplay that specific CVE by any means, it is very bad, but you being able to even read that CVE is a good thing because it's proof the platforms are being assessed and scrutinized by security teams which forces additional security fixes and improvements. Many platforms and OEM's don't get this kind of eye and Google do a great job at this including by fixing vulnerabilities and crediting GrapheneOS by reports by GrapheneOS team members. We aren't worried about that.

          I have seen the exploit of a AMD processor , a user in Linux can write a script and force the CPU using a CPU bug to dump the shadow password file which then can be bruteforced.
          I think some similar attack style might be possible when all chips are replaced by one Google chip, no?

          If it were (also unlikely), then it would be patched just like AMD had done. An exploit of a processor could be done regardless if they were separate chips or not, they wouldn't affect the difficulty but this is still a massive effort.

          You will say its irrelevant but I think we should not forget what we are doing here. A free and open society requires human rights to be respected and discussion to be open, not censored and labeled as... (reply omitted)

          I have removed some comments on your reply. It would be best to keep the thread about your current topic and bringing up such past events wouldn't be appropriate, I hope you understand.

          GrapheneOS is open-minded although we are different from other projects work or behave. Certain topics get closed, deleted or redirected for a number of reasons. Misinformation isn't targeted out of malice, rather because their room for discussion disrupts the project's work. The objective of GrapheneOS is to provide a highly usable, private and secure mobile operating system while contributing to the mobile security/privacy community with bleeding-edge security research. The community GrapheneOS places itself in is unfortunately full of scammers, or at worse, criminals who try and sell the promise of mobile security and privacy and deliver neither of them. Many topics of interest can get discussed which mean little to nothing in the real world simply because these scammers use them as scapegoats or advertising speech to sell their false promise. Topics like open source software, global surveillance leaks, state-level threat actors become extremely ripe with people who believe completely wrong information about them because they read them from internet forums or these scammers rather than security teams and experts...

          The approach we take on security/privacy innovation is a leading factor in the high quality of GrapheneOS' work, we don't believe in security theater and the about section can tell you more about our approach. If we focus too much on what people want to believe are real, then we wouldn't have any work done in protecting ourselves against what actually happens. It is better to eliminate entire categories of attacks or vulnerabilities than focus on one small example of a vulnerability.

          As you have seen in our thread about vulnerability reports, it is worth noting that the companies responsible knew about GrapheneOS and had trouble with attacking it like they could with the stock OS. Our focus on what is actually happening protected people against real threats.

          • troika They would need to unlock the device (either by exploitation or consent) to perform any data extraction or cloning in the first place, so this situation wouldn't be a valid concern. Forensics software require the device credentials. They can't know you had this set-up unless they had knowledge of it before they took the device. They'd also handle it differently if they knew it could be triggered by you.

          • [deleted] That package changes the identifier(s) of the Mudi mobile router, not the devices you connect it onto. It has nothing to do with the phone you use. The idea of using that package is you change the identifiers when you change the router's SIM card. It is also a flawed approach because you need to keep buying SIMs and changing them on the router with constant use to maintain a minimal level of privacy.

            You're better with using Airplane Mode to disable the cellular radio and no SIM at all (to avoid WiFi calling etc.) if the cellular network is something you're trying to avoid.

              SoulKeeper Vanadium does have inbuilt content blocking now as of recent updates. It currently uses the EasyList and EasyPrivacy lists.

            • Carpool7341 You mentioned that the kernel also zeroes its freed memory. Does the hardened kernel that's used by GrapheneOS implement its own heap allocation algorithm, like the hardened malloc? AFAIK, malloc cannot be used in the kernel, since it must define all the functions itself.

              We enable kernel heap hardening features not used by the stock OS and add our own, but it's not a whole new hardened allocator as we do for userspace via hardened_malloc.

              Carpool7341 Is there any overflow protection in the stack? Canaries and/or randomisation to protect the return address?

              The stock Pixel OS uses ShadowCallStack for the kernel return address protection before 8th gen Pixels and PAC on 8th gen, we use both SCS + PAC on the 8th gen Pixels. Clang Control-Flow Integrity is used for forward edge CFI in kernel, which will switch to the more efficient kCFI implementation, same as the stock OS.

              Carpool7341 You mentioned that if GrapheneOS is targeted specifically, an overflow exploit can potentially be designed for it. Would that supposed attacker need to break the CSPRNG algorithm and/or the hardware memory tagging or would a good understanding of the implementation suffice?

              I didn't exactly say that it would be an overflow exploit, rather I was just talking about remote exploitation of the OS in general. Apologies if I made you misinterpret it. If a specific, sophisticated actor were to target the OS then they could possibly consider other categories of exploitation that wouldn't be covered too. Likewise, hardware memory tagging is only bulletproof against certain kinds of vulnerabilities like linear overflows, small overflows, certain classes of use-after-free not able to delay the use until it's reused later, among other things. It is also not the only mitigation on offer in GrapheneOS.

              Hardware memory tagging is mostly based on randomization, there are only 4 bits, 16 possible tags, standard for 0 to be reserved which it is for hardened_malloc and only used for free data (so 15 possible random tags). Attackers would need to bypass it multiple times in most cases, not just once, since it's for any reads and writes. Would be extremely difficult to exploit with success. I would point you to the hardened_malloc README again for some MTE details:

              https://github.com/GrapheneOS/hardened_malloc?tab=readme-ov-file#memory-tagging

              • Edited

              As per the features page, Hardened Malloc (and other relevant memory management hardening) are integral, significant components to GrapheneOS's approach of defending itself against unknown vulnerabilities. Hardened Malloc is one of the more important hardening projects the project has done. In addition, the GrapheneOS MTE implementation and support is one of the most important additions added to the OS since the project started ten years ago. GrapheneOS and Vanadium are the first platform and web browser to incorporate MTE in production. It is such a massive improvement that future devices will need to support MTE before they can be considered in-support for GrapheneOS.

              Hardening the memory management makes up a very large security benefit as most exploits (including the most severe) done on the upstream are memory exploits like overflows or use-after-free. Hardened Malloc is designed to mitigate attacks like these in particular plus other forms of heap/memory corruption exploitation. By changing the most exploited components either by hardening them or replacing them with a more secure alternative, the OS is less likely to be effected by exploits (known or unknown) that would target the Android platform. This is part of the second objective (the first being attack surface reduction) for the OS' exploit mitigations, where we try preventing an attacker from exploiting vulnerabilities by making such a move unreliable, unlikely, costly and difficult to develop an exploit for.

              As you've already read, the OS zeroes (sanitizes) the kernel and slab memory when it is freed. This would protect against use-after-free as there would be no data to use when sanitized. Address space and memory allocation re-use is delayed through the combination of deterministic/randomized quarantines to mitigate use-after-free as well. The sanitization would also protect against uninitialized data usage and keeps sensitive data in memory for a less amount of time (only when it is necessary to be).

              Other types of corruption are also covered, I would recommend checking the documentation here: https://grapheneos.org/features#exploit-protection
              and the README for hardened_malloc itself for detailed information on it's security properties, it is quite in-depth and it wouldn't do enough justice within a forum reply: https://github.com/GrapheneOS/hardened_malloc#security-properties

              Hardware memory tagging is a separate thing from Hardened Malloc, but it is integrated by Hardened Malloc and helps provide a form of memory safety for memory unsafe code (from C and C++) and low-level unsafe code in safe languages like Java and Kotlin. MTE is enabled for all base OS apps and almost all executables with some small exceptions on those that have bugs. You can use hardware memory tagging if you have a Pixel 8 or later.

              As for overcoming this hardening, it is still possible for someone to develop an exploit for the OS providing they had the skills and budget, even if it hasn't been known to be done. Although, it would be far more difficult for them to do in comparison to other platforms because of the hardening work done, ESPECIALLY on a platform incorporating MTE like Pixel 8 or later. It would also be far more difficult to upkeep an exploitation kit because these sophisticated threats would have to work faster against our pace of adding new security/privacy features and improvements. Making the exploit is already difficult, but making sure it is persistent or functional across updates is a harder effort, especially when this solution would need to be bespoke and made purposefully to target GrapheneOS.

              Blastoidea UX means User Experience. Basically it helps the experience for users who use their phone this way.