Exploiting vulnerabilities in Cellebrite UFED and Physical Analyzer • Hacker News Board

Re: Exploiting vulnerabilities in Cellebrite UFED and Physical Analyzer

#141

Post by tptacek » Wed, Apr 21, 2021, 10:06 PM UTC

wglb wrote: post #135

tptacek wrote: post #68

Earlier quoted context omitted.

The quality of forensics software is extremely low; a similar story was once written about EnCase, and had zero impact on any legal case anywhere.

As in https://www.securityweek.com/forensics-tool-flaw-allows-hack... ., yet it is used in cases large and small, civil, criminal, federal state.

Matt Blaze did some research on this, and it seems to turn out that when you put an argument like this in front of a judge or jury, ultimately you have to back it up with evidence that it actually happened; it's not enough to say that the potential existed. Which makes sense, because the potential exists for a lot of stuff, including stuff we don't often talk about.

Re: Exploiting vulnerabilities in Cellebrite UFED and Physical Analyzer

#142

Post by saagarjha » Wed, Apr 21, 2021, 10:07 PM UTC

marcodiego wrote: post #20

> One way to think about Cellebrite’s products is that if someone is physically holding your unlocked device in their hands, they could open whatever apps they would like and take screenshots of everything in them to save and go over later. Cellebrite essentially automates that process for someone holding your device in their hands. Aren't Cellebrite products/services more advanced than that? I mean don't they use pu…

AFAIK there are various “levels” of Cellebrite’s products, from “I’m a phone shop and I want something help me make a phone backup so I can restore it” all the way to “tools to break into locked iPhones”.

Re: Exploiting vulnerabilities in Cellebrite UFED and Physical Analyzer

#143

Post by saagarjha » Wed, Apr 21, 2021, 10:10 PM UTC

polar wrote: post #81

Klonoar wrote: post #79

If it's true that you can grab a Cellebrite hardware piece without too much difficulty (Ebay, etc - and note I'm not speaking from expertise so someone please fact check me), I'd find it hard to believe Apple wouldn't have done this kind of inspection themselves and/or noticed those DLLs being shipped. Curious if there'll be a response of sorts.

I am reasonably confident that Apple is a Cellebrite customer. Their security team certainly has access to forensic tools from other vendors. That team also spawned BlackBag Technologies, which is now part of Cellebrite.

Apple uses Cellebrite devices in their stores to transfer data from devices, I believe.

Re: Exploiting vulnerabilities in Cellebrite UFED and Physical Analyzer

#144

Post by rodgerd » Wed, Apr 21, 2021, 10:16 PM UTC

po wrote: post #7

This is truly a hacker’s retort. It attacks Cellebrite's ability to operate by casting doubt on the reports generated by the product that their customers may wish to use in court. It places them in legal peril from Apple, and removes any cover Apple would have to not take legal action. (I assume someone at Apple knew they were shipping their DLLs?) It makes a thinly-veiled threat that any random Signal user's data ma…

> It makes a thinly-veiled threat that any random Signal user's data may actively attempt to exploit their software in the future and demonstrates that it's trivial to do so.

That does not make me feel good about Signal.

Re: Exploiting vulnerabilities in Cellebrite UFED and Physical Analyzer

#145

Post by matheusmoreira » Wed, Apr 21, 2021, 10:24 PM UTC

tony101 wrote: post #64

A reminder that you can pair lock your iPhone to prevent analysis by Cellebrite or similar tools: https://arkadiyt.com/2019/10/07/pair-locking-your-iphone-wit...

Are there similar features for Android devices? A database of Cellebrite-resistant phones, perhaps?

Re: Exploiting vulnerabilities in Cellebrite UFED and Physical Analyzer

#146

Post by rodgerd » Wed, Apr 21, 2021, 10:26 PM UTC

barbazoo wrote: post #124

paddlesteamer wrote: post #3

> In completely unrelated news, upcoming versions of Signal will be periodically fetching files to place in app storage. These files are never used for anything inside Signal and never interact with Signal software or data, but they look nice, and aesthetics are important in software. I wish I could see those files in action...

I don't get it, can anyone elaborate on what they are talking about there?

Signal is going to start attacking third-party tools once it's installed on your phone.

It's as though Theo decided that OpenSSH should respond to portscanners by trying to pwn the source systems.

Re: Exploiting vulnerabilities in Cellebrite UFED and Physical Analyzer

#147

Post by akerl_ » Wed, Apr 21, 2021, 10:32 PM UTC

jjoonathan wrote: post #98

jaywalk wrote: post #74

Earlier quoted context omitted.

Well, if you read the whole blog post, it certainly seems like they're actually doing it.

Nah. The cost/benefit of saber rattling makes tons of sense while the cost/benefit of actually doing it makes much less sense. Probably. No amount of certainty about Marlinspike's actions should comfort Cellebrite, though, because Moxie Marlinspike isn't the only person allowed on the app store.

I’m not sure what you mean. The end of the post pretty clearly describes the framework they’re using to roll out these exploits as latent files within the Signal app.

Re: Exploiting vulnerabilities in Cellebrite UFED and Physical Analyzer

#148

Post by matheusmoreira » Wed, Apr 21, 2021, 10:43 PM UTC

idlewords wrote: post #60

jjoonathan wrote: post #58

Earlier quoted context omitted.

Signal isn't going to actually do it, they know how that would end, they're just playing the FUD game in the other direction. Which I am 100% on board with.

Maybe the one thing worse than boasting that you're putting malware in your product is boasting about it and not doing it.

Malware? Any countermeasure against state surveillance is a good thing for us.

Re: Exploiting vulnerabilities in Cellebrite UFED and Physical Analyzer

#149

Post by acdha » Wed, Apr 21, 2021, 10:43 PM UTC

kbenson wrote: post #15

Nextgrid wrote: post #6

So I wonder, why disclose this? This will just prompt Cellebrite to improve its security process and sandbox the entire tool. If they wanted to destroy the credibility of the tool, using the vulnerabilities to silently tamper with the collected data or even leaking it online would be a much better option and hit them without any warning, not only jeopardizing those cases but forever casting doubt on not just Cellebri…

> sandbox the entire tool. Sandboxing doesn't really help. The problem isn't that the tool is used to infect the rest of the system, but that the tool itself is compromised, the reports it generates are compromised, and and past reports may be compromised. Unless you're pushing that data outside the sandbox (which is a hole in the sandbox, and while much more limited might also be an exploit vector or a way to cause…

This is too quick a dismissal: if they sandboxed each extraction tool they'd be more likely to be able to say that a compromised tool did not compromise the entire system or data collected by other tools. This is exactly why programs like browsers, messaging clients, etc. have moved things like media decoders into separate processes, especially since those tools can be sandboxed quite aggressively whereas a monolithic program will use a fair number of different permissions.

Re: Exploiting vulnerabilities in Cellebrite UFED and Physical Analyzer

#150

Post by rpdillon » Wed, Apr 21, 2021, 10:44 PM UTC

rodgerd wrote: post #144

po wrote: post #7

This is truly a hacker’s retort. It attacks Cellebrite's ability to operate by casting doubt on the reports generated by the product that their customers may wish to use in court. It places them in legal peril from Apple, and removes any cover Apple would have to not take legal action. (I assume someone at Apple knew they were shipping their DLLs?) It makes a thinly-veiled threat that any random Signal user's data ma…

> It makes a thinly-veiled threat that any random Signal user's data may actively attempt to exploit their software in the future and demonstrates that it's trivial to do so. That does not make me feel good about Signal.

I've seen this reaction a few times. Can you say more? Presumably Signal users value privacy, and the implication is that when hacking tools used to violate that privacy are applied to a device running Signal, it may try to interfere and prevent the extraction to some degree. This seems like an ideal feature for a private messenger.

In contrast, it would strike me as strange if a Signal user switched to another messenger that allowed the data extraction because they were uncomfortable with Signal blocking it.