In 2014, QuarksLab was missioned by OpenITP to audit the iOS application ChatSecure and to identify any weakness that could lead to information leakage or any other risk that could impact the user.

Our findings and conclusions on ChatSecure were surprising. Even though the application was coded with encryption and security in mind, developers (at that time) did not succeed in visualizing all the possible attacks they needed to defend against. We will not cover everything that we found in this blog article, as it would be a complete rewrite of our report, but we will try to organize problems in great categories.

And these were only examples of all the possible attack scenarios... To be effective in the time constraint, we divided the work into different areas:

Evaluating the anti-surveillance security of an instant messaging application is not an easy task considering the huge attack surface that the reviewer has to cover. Here are some common possible weaknesses:

Back in February 2014, QuarksLab was missioned by OpenITP to audit the iOS application ChatSecure and to identify any weakness that could lead to information leakage or any other risk that could impact the user. To sum up OpenITP, here is a quote from their website: "OpenITP improves and increases the distribution of open source anti-surveillance and anti-censorship tools by providing the communities behind these tools with many kinds of support." In our particular case, OpenITP funded the audit of ChatSecure. What could be a better help for an information security app? Obviously, there were time and financial constraints, but we did our best to identify most issues to assist in improving the security level of the app. 3 security researchers worked on the subject for approximately 20 days:

Protocol weaknesses and user unawareness

The biggest problem with ChatSecure 2.2 is that it tried to handle multiple protocols, each being implemented in different sub-modules. We sumed up the differences in the next table:

AIM is obviously the concern here, but not only because it is not encrypted: the idea of ChatSecure at that time was to handle the maximum number of protocols and protect the communication with an additional layer of encryption, as of Adium on Mac for example. Adium let you concentrate all your accounts coming from 15 different services in a single app, and use the Off-the-Record (OTR) messaging standard on top of them to secure the communication. Is OTR over many protocols a good design choice for a secure messaging app? Here at QuarksLab, we think that it is not. OTR has been designed with security in mind, but when it is used over weak protocols, and when fingerprint verification is not sufficiently enforced, man-in-the-middle is still possible. Moreover, multiplying protocols means extending the attack surface and is a bad design practice for any secure application. Now let me explain why being AIM compatible is a bad choice for any messaging application: the AIM protocol does not authenticate the server, and the traffic is unencrypted, which means that an attacker on the network can impersonate the AIM server, being in a man-in-the-middle position. OK, but why is it important at all considering the whole communication is encrypted on top of the AIM protocol by OTR? There are multiple answers:

the fake server can intercept and spoof the user's buddy list

the fake server is in strong position to try man-in-the-middle attacks on the OTR protocol

the fake server can forge unattended packets

In the particular case of ChatSecure, here is what we found in addition:

the AIM protocol implementation was prone to multiple memory corruptions

the AIM protocol implementation included "debugging" commands in the message parser, probably left by the developer :-( These commands did let a remote user with a simple message (using any AIM app) read the buddy list of a remote ChatSecure user, add/remove buddies, force a disconnect and even more fancy stuff...

Conclusion: limit the attack surface if you intend to code a secure application by limiting its functionalities. The more code, the more risks.

Another problem related to all these protocols is the user unwareness of their weaknesses. Although ChatSecure's Facebook and Google XMPP implementations both rely on a certificate pinned secure connections (Facebook and Google certificates bundled with the app) , the Jabber XMPP one did not enforce STARTTLS. The user should be aware that if he wants a really secure connection so that no attacker could be in position of, as with AIM, intercept metadata and forge packets, he has to connect to a STARTTLS compatible server. Using ChatSecure 2.2, the user adds Facebook, Google, Jabber, or AIM accounts without knowing if the server he is communicating with can be trusted and differences between protocols secureness. Either way, even if Facebook or Google servers are authenticated for sure (because of certificate pinning), who knows if some malicious user is not hacking these servers? That's why I am now continuing with the interresting part. Is ChatSecure OTR implementation a fortress?