Security assessment of instant messaging app ChatSecure: when privacy matters

Introduction

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:

·         Sébastien Kaczmarek (@deesse_k): Cryptography assessment

·         Nicolas Grégoire (@Agarri_FR): XML fuzzing

·         Cyril Cattiaux (@pod2g): Application security

The audited version was ChatSecure iOS v2.2. The full report is available at the end of this blogpost.

Methodology

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:

·         app should not let users trick other users into believing they are discussing with a trusted contact while talking to somebody else (prevent spoofing)

·         app should not let users trick other users into doing dangerous actions (prevent phishing)

·         app should not let users inject scripts into conversations (prevent XSS)

·         network protocols used should not let an attacker intercept and modify the discussion (prevent man-in-the-middle)

·         communication should not be readable by an attacker either active or passive over the network (prevent surveillance)

·         app should not let attackers execute code or access private data remotely (prevent control)

Findings

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.

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:

ChatSecure's OTR

Quote from wikipedia : "Off-the-Record Messaging (OTR) is a cryptographic protocol that provides encryption for instant messaging conversations. OTR uses a combination of AES symmetric-key algorithm with 128 bits key length, the Diffie–Hellman key exchange with 1536 bits group size, and the SHA-1 hash function. In addition to authentication and encryption, OTR provides forward secrecy and malleable encryption." Cryptographically wise, OTR is a really strong protocol with excellent features, particularly the perfect forward secrecy and deniable authentication. Cryptographers Ian Goldberg and Nikita Borisov behind OTR even provided a C implementation in a library for simple integration into instant messaging apps: libotr. ChatSecure depends on libotr, and a wrapper library has been written in Objective-C for the occasion: OTRKit. So, OTR is secure, but as most asymetric key communication, it is vulnerable to man-in-the-middle attacks: remember our talk on iMessage? Libotr provides 2 ways to authenticate the other user (and verify nobody is in the way):

·         Fingerprint verification of the DSA key of the remote party

·         Socialist-Millionaire protocol

SMP is not implemented in ChatSecure and the fingerprint verification was messy and partial, let me explain why. The most important thing in a secure communication is to be assured that you are talking to the right person, and ChatSecure provides a verification process for that:

·         you click on the padlock icon, and it shows the expected fingerprint of the remote user and yours.

·         your contact does the same

·         in another secure channel (GPG mail, iMessage, or best, in person) both double check the fingerprints

·         communication is now verified, the padlock has a little checkmark in addition to being locked

     Issues:

·         ChatSecure v2.2 tends to forget about the verification status and you have to do the operation at every new discussion with the same user

·         The padlock is small, and if you do not pay attention, you are not warned nor encouraged to do the verification process

·         OTR is not even tried automatically by default, user have to manually force it (this behavior is overridable in the settings pane)

·         A user can still send you unencrypted (non OTR) messages even if ChatSecure considers the communication as secure

·         Remote user can decide to stop OTR and continue unencrypted, ChatSecure will just write a very small status text in the message window saying that the secure chat session has been ended

·         If the fingerprint of the remote party is different than last time, no warning pops. The communication is just not verified, as usual anyway, because ChatSecure v2.2 forgets about the verification state

So basically, to be certain that the communication with your contact is safe you would need to do, each discussion with him:

·         manually click on the padlock to activate OTR

·         verify the communication using another "secure" channel (quotes because this channel could obviously be man-in-the-middled)

·         watch the padlock and the microscopic status change text before reading or writing any message

And still, somebody could be in the middle and could send you unencrypted messages as if he would be your contact without you noticing. Sketchy implementation, isn't it?

Conclusion

Developing a secure instant messaging application is a tough task. Secure messaging does not only rely on using strong cryptography:

·         the attack surface should be limited to the maximum so that nobody can take control and for example execute remote code instead of trying to break the cryptography

·         the user must be guided on how to verify the communication properly and be warned if everything goes wrong

·         the user should be encouraged to upgrade to the last version of the application and of his operating system

Also, thinking that OTR can protect you on any kind of channel is totally wrong. If a man-in-the-middle position is gained by an attacker because the underlying protocol is unsecure (AIM, XMPP without TLS, untrusted XMPP server, etc.), he can attempt to modify your buddy list, to disconnect the OTR communication and revert back to unsecure, forge unattended network packets, etc. Is ChatSecure v2.2 a secure instant messaging application? No. However, ChatSecure v3.0 is in the way and a lot of our findings and comments have been integrated, examples:

·         removal of AIM support

·         TLS required for all XMPP connections

·         message archiving with SQLCipher (encrypted database)

·         warning on insecure iOS versions

But what would be the ultimately secure IM application? An application that does not try to be compatible with existing services, and that would rethink everything from the ground up. No XMPP support (attack surface is huge), only one secure transport protocol, OTR like cryptography on top of it, and a clear and manageable list of fingerprints. 

For more  details: quarkslab