Live data from Hacker News

Exploiting vulnerabilities in Cellebrite UFED and Physical Analyzer

signal.org

11–20 of 352 posts

Re: Exploiting vulnerabilities in Cellebrite UFED and Physical Analyzer

#11

They literally said the unit fell off a truck. Funny... Correctly me if I am wrong, but did they really say they were going to be doing active attacks against Cellebrite units? Also funny... but they probably are not actually going to be doing that.

They didn't actually say anything of the sort. They may have implied some stuff. Anything they did imply wouldn't be an active attack though, it would be a passive one, triggered only if Cellebrite tried to gather data from the Signal app on phones. Not gathering info from a phone, or not gathering Signal data from a phone, would both be ways Cellebrite could avoid this potential passive attack.

Re: Exploiting vulnerabilities in Cellebrite UFED and Physical Analyzer

#12
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…

All that trouble becaused a bag conveniently "fell from a truck". All in all I'm really happy for all this.

Re: Exploiting vulnerabilities in Cellebrite UFED and Physical Analyzer

#13
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…

Sandboxing doesn't fix the problem. The problem isn't the same as a consumer app where you're trying to protect the OS from being rooted. Their problem is they need to protect the integrity of the report it generates because that's the thing that makes them money.

edit:

One thing they could try to do is to sandbox the parser itself to lower attack surface area... but the damage is done here and I really doubt they will win a security tit-for-tat with Signal.

Re: Exploiting vulnerabilities in Cellebrite UFED and Physical Analyzer

#14
post #11

They literally said the unit fell off a truck. Funny... Correctly me if I am wrong, but did they really say they were going to be doing active attacks against Cellebrite units? Also funny... but they probably are not actually going to be doing that.

They didn't actually say anything of the sort. They may have implied some stuff. Anything they did imply wouldn't be an active attack though, it would be a passive one, triggered only if Cellebrite tried to gather data from the Signal app on phones. Not gathering info from a phone, or not gathering Signal data from a phone, would both be ways Cellebrite could avoid this potential passive attack.

The digital equivalent of "stop hitting yourself". Notwithstanding their crypto issue, this gives me renewed confidence in Signal's team.

Re: Exploiting vulnerabilities in Cellebrite UFED and Physical Analyzer

#15
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 problems in the data) it's still fair game if the sandboxed tool is compromised.

There's multiple reasons to disclose it. First, because as another comment noted it attacks the credibility of the company, and credibility is very important for tools used in court.

Second, because their main goal is to protect Signal, not attack Cellebrite. Making Signal a problem to attempt to gather data about will possibly make them just blacklist Signal as an app they gather for. This could be temporary, but since Signal alluded to many exploits and that they have a bunch queued up for the future, it will always be a risk for Cellebrite to attempt to gather info from Signal, so they might just continue to skip it.

Re: Exploiting vulnerabilities in Cellebrite UFED and Physical Analyzer

#16
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…

The public disclosure about the Apple DLLs could potentially be used to drag Apple into any legal case between somebody versus Cellebrite. The disclosure needs to be public versus private or under seal or whatever to absolve the Cellebrite counterparty of any liability from reverse engineering. Suddenly Apple is now in potential collusion with Cellebrite. Or maybe not. This public disclosure makes the threat of Discovery a bit less toothless.

IANAL but I could imagine Cellebrite has existing or pending litigation where this disclosure upsets their position.

Re: Exploiting vulnerabilities in Cellebrite UFED and Physical Analyzer

#17
post #4

> 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 wonder if the intention here is to deter Cellebrite from parsing Signal files? Or to pressure them into fixing their security vulnerabilities?

Nah, Cellebrite will panic for a bit at the possibility of facing repercussions but ultimately not commit enough effort to change anything. Cellebrite's counterparties, however, might not be so complacent.

Re: Exploiting vulnerabilities in Cellebrite UFED and Physical Analyzer

#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 publicly unknown zerodays to extract data from locked phones?

Post reply on HN