Blackphone rooted at Defcon — Part 2

As I mentioned in my earlier post — we took on the challenge of building a secure and private smartphone system. @TeamAndIRC threw a proverbial jab to the jaw, and well, our jaw is not made of glass. Kudos to @TeamAndIRC for explaining the exploit. No hard feelings —  things get fixed by being found.

Now to address the release of the vulnerabilities disclosed at #Def Con by @TeamAndIRC:

Issue #1: Enabled the Blackphone’s disabled ADB. Blackphone and @TeamAndIRC disagree on this issue. In the final days before manufacture, a bug was found with ADB on the Blackphones which could throw the phone into a boot loop when full device encryption was turned on. Rather than miss the manufacturing window or cause user grief, the developer menu was turned off. Disabling ADB is not a security measure, and was never meant to be — it will be returning in an OTA to Blackphone in the future once the boot bug is resolved; the realities of getting a product manufactured and shipped within the available manufacturing window meant a quick fix was needed. No root or other privilege escalation was required in order for this to be performed.

Issue #2: @TeamAndIRC found that in PrivatOS version 1.0.1 a system file that is responsible for remote wipe was set to debug. If a malicious App were to be installed on the Blackphone then this would allow for privilege escalation. As we mentioned previously, this was discovered last week and was part of the 1.0.2 update released on August 1 (https://support.blackphone.ch/customer/portal/articles/1645556-privatos-1-0-2-release-notes). PrivatOS 1.0.2 was released while the phones for sale at Def Con were in the air for delivery — and we figured that the Def Con crowd might not appreciate phones with the tamper seals cut open on all the boxes. The generally hostile network environment at the con makes getting the OTA problematic, and we’ll try to figure out a way to get the latest on devices in the future. Obviously, devices manufactured after 1.0.2 will ship with the new firmware out of the box.

Issue #3: @TeamAndIRC was not willing to discuss this vulnerability at this time. We are under the impression that this vulnerability affects many OEMs and not just Blackphone. When the vulnerability becomes public, we will implement the fix faster than any other OEM.

In general, @TeamAndIRC accurately described that in order to exploit any of the above-mentioned vulnerabilities the end-user would require physical access to the device and then perform the exploit. @TeamAndIRC explained that these vulnerabilities are not exploitable via a drive-by-download or other remote activities and will further require intentional user interaction. This would mean the user lost physical control of their Blackphone or they wanted to walk around with an exploitable smartphone. Nonetheless, we have a vulnerability and it is important to Blackphone to resolve this vulnerability fast.

We pride ourselves on being able to provide a quick turnaround to security problems. We control the complete OTA process, and are able to fix issues as soon as they are disclosed, if they haven’t been pre-emptively fixed. For example, Blackphone already has patches for other vulnerabilities such as the futex() kernel bug used by TowelRoot which has not yet been included in an AOSP versioned release.

Lastly, we expected the security researcher community to find vulnerabilities in our system in a previous post. Further, I mentioned in my post that we are launching an official security researcher program. While we do not have a Bug Bounty Program we will reward in non-monetary means; the non-monetary means have not yet been determined, but we are open for ideas. So, if you have ideas hit us up on twitter @netsecrex @blackphone_ch.

Keep a look out for the patch, it will be released soon!

Sincerely,

Dan Ford, D.Sc. (@netsecrex)

Chief Security Officer

SGP Technologies