Why Look at WhatsApp’s Security?

Facebook’s acquisition announcement coincided with the starting week of Project Neptune’s beta program. Project Neptune is Praetorian’s new mobile application security testing platform that allows companies to keep pace with rapid mobile development cycles by incorporating continuous, on-demand security testing. And what’s a better way to properly kick off our beta program than to test a publicly available mobile app worth $19 billion?
Within minutes, Project Neptune picked up on several SSL-related security issues affecting the confidentiality of WhatsApp user data that passes in transit to back-end servers. This is the kind of stuff the NSA would love. It basically allows them—or an attacker—to man-in-the-middle the connection and then downgrade the encryption so they can break it and sniff the traffic. These security issues put WhatsApp user information and communications at risk.
The security test cases selected in Project Neptune were nonintrusive and limited in scope. Praetorian would need authorization from Facebook and WhatsApp to conduct a more thorough security evaluation of the mobile applications and back-end infrastructure. Despite the limitations in scope, the following were among the security issues that Neptune identified:

SSL Pinning Not Enforced

WhatsApp does not perform SSL pinning when establishing a trusted connection between the mobile applications and back-end web services. Without SSL pinning enforced, an attacker could man-in-the-middle the connection between the mobile applications and back-end web services. This would allow the attacker to sniff user credentials, session identifiers, or other sensitive information.

Update 02/21/2014: WhatsApp is actively working on adding SSL Pinning now

SSL Export Ciphers Support Enabled

WhatsApp’s back-end servers allow the use of weak 40-bit and 56-bit encryption schemes. Without malicious intervention this may not be an issue, because the mobile application and server will negotiate the encryption and settle on the strongest encryption they both support. However, an attacker could intercept the communication and forcefully downgrade it to 40-bit or 56-bit DES encryption, which would make brute-force attacks against the encryption feasible.

Update 02/21/2014: We no longer find evidence of export cipher support.

SSL Null Ciphers Support Enabled

It gets worse. WhatsApp even supports Null Ciphers, which is data that is supposed to be encrypted, but in reality is not. Null Ciphers do not perform any encryption. That is, it simply copies the input stream to the output stream without any changes. With Null Ciphers supported, if the client mobile application attempts to communicate to the server using SSL and both parties do not support any common cipher suites—as a result of a malicious intercept—then it would fall back to sending the data in clear, plain text. Supporting Null Ciphers is not something we come across often—it’s quite rare.

Update 02/21/2014: We no longer find evidence of null cipher support.

SSLv2 Protocol Support Enabled

WhatsApp was also found to support SSL version 2 (v2), which has been found to contain several weaknesses. SSLv2 is vulnerable to several specific attacks which require sniffing and man-in-the-middling. In addition, SSLv2 utilizes MAC post-encryption and 40-bit MACs, which are both considered design flaw weaknesses. Depending on the time and resources of an attacker, any communication protected by SSLv2 may be vulnerable to man-in-the-middle attacks that could allow data tampering or disclosure.

Update 02/21/2014: We no longer find evidence of SSLv2 support.

How Difficult Would it be for WhatsApp to Fix These Issues?

Not very difficult. The biggest challenge most developers have with security is understanding how their design decisions impact the integrity of an application. Mobile is still a new frontier for many developers. Unfortunately, security considerations often take a backseat when there is still uncharted space to explore with new technologies.

In the case of implementing certificate pinning, for example, there are a few things to consider. Pinning the certificate itself is the simpler way to do it, but it requires more maintenance overtime because developers will have to make changes to the application whenever the cert changes. Another way to do it is by pinning the public key, which can be more difficult. Choosing the best way to go often depends on the frequency in which the certificate itself may change. More details can be found in OWASP technical guide to certificate and public key pinning.
Surprisingly, it’s extremely common to see mobile apps without certificate pinning. This security control is used to counter the ability of an attacker to view and modify all traffic passing between the mobile device and backend server. It can also help protect against certificate authority trust failures during client and server negotiation, which coupled with the support of weak and null (plain text) ciphers—as found to be the case in WhatsApp—is an even bigger red flag.
Developers need a partner, with a deep understanding of application security, who can keep pace with the rapid speed of mobile development. One that can be with them throughout the mobile development lifecycle—from start to finish. We believe technology will fill this gap and we believe Project Neptune is the answer.

Mobile Has Fundamentally Changed the Security Landscape Forever

Organizations need to keep pace with rapid mobile development cycles by incorporating continuous, on-demand security testing. With Project Neptune, we are evolving the way mobile development teams address security challenges they encounter while building and maintaining mobile apps. Mobile moves too fast for security to still remain as an afterthought. It’s time for a fundamental change in the way developers build secure mobile applications. Our team is dedicated to helping the world’s leading companies deliver security mobile apps faster and more efficiently.