Security-Focused BlackPhone Was Vulnerable To Simple Text Message Bug

mask.of.sanity sends this report from El Reg: The maker of BlackPhone – a mobile marketed as offering unusually high levels of security – has patched a critical vulnerability that allows hackers to run malicious code on the handsets. Attackers need little more than a phone number to send a message that can compromise the devices via the Silent Text application.

The impact of the flaw is troubling because BlackPhone attracts what hackers see as high-value victims: those willing to invest AU$765 (£415, $630) in a phone that claims to put security above form and features may well have valuable calls and texts to hide from eavesdroppers.

Comments

Security is a process ...

[gstoddart]

The problem with security is it is an on-going process, and it takes time. Which means the trust that you actually are secure also takes time.

So, just because you started out thinking "Oh boy, are we going to be hella secure" -- it takes a long time to FIND all those things which defeat that, and just as long to convince everybody that you've done it.

Almost as soon as I heard of this phone my first thought was "gee, you're brand new, why should be trust that you've got it sorted out".

And, as TFS says ... this phone is used by people who want additional security. What the hell made you think you wouldn't be immediately targeted? This is like advertising you have an unbreakable vault ... now everybody wants to prove you wrong.

I think they started trading on a reputation they hadn't earned yet, and now it's biting them in the ass.

Re:Security is a process ...

[BreakBad]

They should have called it 'GreyPhone', maybe one day, after many updates, 'DarkGreyPhone'. But lets face it...BlackPhone may just be unobtainable.

Re:Security is a process ...

[mlts]

The problem is that a company that has security as part of their mindset is hard to find. Most at best have it as an afterthought, something strapped on at the last moment.

Security takes R&D, just like everything else. Would I expect a v1.0 product to be secure, especially from focused attack by people who want to bypass it? No, and not even in a v1.0.10 product. Breaches will happen for the first few years.

However, I will state one thing about BlackPhone: They fixed the issue. Other vendors would just tell their customers to buy a new smartphone or go pound sand. Where the rubber meets the road is how security flaws are handled. Are they acknowledged and patched, or are they covered up, flagged as FNR (fixed in next release), and only threats of litigation able to actually get the vendor to make a patch. There will -always- be flaws. However, part of a company selling security is how they respond to issues, and here, BlackPhone has performed quite well. There was a problem, they fixed it, and that is what matters.

Re:Security is a process ...

[IamTheRealMike]

There will -always- be flaws. However, part of a company selling security is how they respond to issues, and here, BlackPhone has performed quite well. There was a problem, they fixed it, and that is what matters.

I agree that how a company handles incident response is important and the BlackPhone guys have apparently handled this well.

However, there are several things that are troubling about this story which lead me to not trust BlackPhone and question the security experience of the people designing it.

The first thing we notice about this exploit is that the library in question appears to be written in C, even though it's newly written code that is parsing complex data structures straight off the wire from people who might be attackers. What is this, 1976? These guys aren't programming smartcard chips without an OS, they're writing a text messaging app that runs on phones in which the OS is written in Java. Why the hell is the core of their secure messaging protocol written in C?

The second thing we notice is that the bug occurs due to a type confusion attack whilst parsing JSON. JSON?! Yup, SCIMP messages apparently contain binary signatures which are base 64 encoded, wrapped in JSON, and then base64 encoded again. A more bizarre or error-prone format is difficult to imagine. They manage to combine the efficiency of double-base64 encoding binary data with the tightness and simplicity of a text based format inspired by a scripting language which has, for example, only one kind of number (floating point). They get the joy of handling many different kinds of whitespace, escaping bugs, etc. And to repeat, they are parsing this mess of unneeded complexity .... in C.

Compare this to TextSecure, an app that does the same thing as the BlackPhone SMS app. TextSecure is written by Moxie Marlinspike, a man who Knows What He Is Doing(tm). TextSecure uses protocol buffers, a very simple and efficient binary format with a schema language and compiler. There is minimal scope for type confusion. Moreover, the entire app is written in Java, so there is no possibility of memory management errors whilst trying to read messages crafted by an attacker. By doing things this way they eliminate entire categories of bugs in one fell swoop.

So yes, whilst the BlackPhone team should be commended for getting a patch out to their users, this whole incident just raises deep questions about their design decisions and development processes. The fact that such a bug could occur should have been mind-blowingly obvious from the moment they wrote their first line of code.

pretty much expected.

[nimbius]

Blackphone arguably isnt interested in real security at all, just theatre. Their phone is Android, but their entire range of security applications (the part that keeps you safe) is proprietary, closed source, and subscription based. Blackphone exists for the paranoid executive banging the mistress, the paranoid trophy wife banging the pool boy, and the paranoid celebrity with a panic room.
Check out https://prism-break.org/ for real security. The open source community has worked hard for decades to help keep you safe and secure. Sometimes we dont have the sexiest branding, but for that tradeoff you get more than a promise. you get the source.

Re:pretty much expected.

[sasparillascott]

Um, because one of the guys at the top of that company is Phil Zimmerman who created PGP? And they moved the company to Switzerland to avoid the entangling fingers of the U.S. government surveillance state.

As to fixing bugs, that will always be an ongoing process. I'd like it better if they were open source, but I'd trust them better than most companies. JMHO...

Re:pretty much expected.

[jellomizer]

IT security is about tradeoffs.
The idea of 100% security while possible, it impractical.
Your argument about Blackphone is the fact they are not supportive of the OSS mind set, So you judging the quality of the technology based on what type of license it has.

Ok a flaw was found, and they put in a fix for it, what else do you expect from them?

Phone mode also at risk...

[The New Guy 2.0]

It seems that the phone app on this device is susceptible to "Bank Impersonation" calls where the caller pretends to be from a bank when actually is a scam artist.

Re:But, But

[ArhcAngel]

You meant that as a joke but when Microsoft first attained government security (C2 IIRC) certification for Windows NT there was a little asterisk by the cert. For the OS to be considered C2 compliant it must not be connected to a network in any way.

Re:Nothing is unhackable

[mlts]

It does have its appeal. For the average user who isn't that technical, and who doesn't know/care how to use PGP or gnuPG, this phone is a step up. At least a user who bought this will get better fixes with regards to security issues than with a lot of smartphones.

My biggest complaint is that it is a closed ecosystem. It would be nice if other devices that are not BlackPhones can run the apps so there can be a wider customer base. Otherwise, the device's acceptance will be hindered because everyone has to have that specific maker's phone. Plus, for every closed application, there is an open alternative.

Maybe the ideal would be to get PGP working independently and transparently with text messaging [1], mail, voice, video, and other items. That way, the metadata can be protected via one layer, but the actual contents are protected no matter what, even if the protocol is completely broken wide open.

[1]: An ideal would be something where sender's device would check if the receiver had the ability to receive (likely having the app poll a server every so often), and if so, send it over the Internet (mainly so it can be acknowledged it was received). If not, send it via SMS/MMS. Unlike iMessage, it would fall back and not assume that a specific app was installed and running.