Vulnerabilities found in Facebook’s new multi-billion dollar mobile app. Are WhatsApps’s 430 million users at risk?
Update Friday, 21, 2014: The WhatsApp team told us they are actively working on adding SSL pinning to their clients and we no longer find evidence of export ciphers, null ciphers, or SSLv2 support. Credit should be given to the WhatsApp team for implementing these fixes so quickly!
If you haven’t heard by now, Facebook announced its acquisition of WhatsApp yesterday for a reported $19 billion. If you’re not familiar with WhatsApp, it is a cross-platform mobile messaging app that allows you to exchange messages without having to pay for SMS. It has basically done for messaging what Skype did for voice and video calls. By using the Internet as its communications backbone, WhatsApp is on a shortlist of companies that have completely transformed personal communications, which was previously dominated by the world’s largest wireless carriers.
Facebook is buying in to WhatsApp’s over 430 million active users, which in itself was a milestone the company reached as of January 20, 2014. The fact that it reached a user base of that size faster than any other company in history is no small feat for its small team of 32 engineers. The service processes 50 billion messages every day across seven platforms. Sequoia Capital, the sole investor in $19 billion WhatsApp, calls its crew of developers “L E G E N D A R Y” for their ability to support 12 million active users for every one single developer—an impressive ratio—but who was in charge of security?
The WhatsApp acquisition comes on the heels of Facebook’s unsuccessful attempt to buy Snapchat for $3 billion. Shortly after Snapchat dismissed the offer, the company took a massive blow from hackers when 4.6 million of its users’ accounts were exposed in a very public security breach. Will Facebook’s new WhatsApp suffer the same fate now that the spotlight and attention begins to grow on the $19 billion mobile messaging app?
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 resolved
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 resolved
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 resolved
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.
