Video Conferencing Team Collaboration Collaboration Devices Engineering

# Stay safe – Always authenticate

Aug 17, 2020 — Richard Barnes

Richard Barnes – Why authentication always needs to be the first thing you do with something you receive over the Internet.

Authentication lesson

Much like Cisco’s collaboration products, WhatsApp is used by millions of people around the world to communicate and collaborate — and a little while ago, it was discovered that due to a vulnerability, WhatsApp also allowed anyone on the Internet to take over the phone it was running on. What can developers learn from what went wrong here, to avoid making similar mistakes in other products? The key lessons here are:

Treat any data you receive from the Internet as potentially hostile
In particular, always use authentication so that you can reject traffic from bad actors
Use memory-safe languages and libraries, especially when handling data from untrusted sources

Here’s how Facebook described the vulnerability in their advisory:

“A buffer overflow vulnerability in WhatsApp VOIP stack allowed remote code execution via specially crafted series of SRTCP packets sent to a target phone number.”

Let’s unpack this

There are a couple of things to unpack here. The phrase “remote code execution” hints at the severity of the vulnerability. By exploiting this vulnerability, an attacker can run any code they want on the victim’s phone. The really scary phrase, though, is “specially crafted”. That means that anyone on the Internet could make up some packets, send them to your phone, and take it over.

The core mistake WhatsApp made here was trusting unauthenticated data. Cryptographic authentication is the way we separate the good guys from the bad guys on the Internet. Whenever a program or device receives data over the Internet, the very first thing it should do is verify that the data was sent by the entity that the product thought it was communicating with. That way, we immediately reject traffic from unknown parties, so that the worst thing that can happen is that the thing we’re communicating with can send us bad data – we’ve scaled down the risk from billions of devices to one.

As usual with cryptography, you should use standard tools for this, and most of the standard security tools include authentication. TLS and its cousin HTTPS are the right tools for most things. They provide authentication using digital certificates. For real-time media, the best tool is DTLS-SRTP, which you’ll always be using if you’re using WebRTC. If you can’t use DTLS-SRTP for some reason, you can fall back to Security Descriptions, which at least ensure that your media packets are from someone who was involved in the call signaling. With all of these, you should configure your software using an AEAD algorithm such as AES-GCM to make sure that all of your communications are authenticated as well as encrypted.

In fact, WhatsApp usually uses Cisco software to encrypt and authenticate their real-time traffic! WhatsApp incorporates the libsrtp open-source library that Cisco maintains. In this case, though, WhatsApp seems not to have been getting all the protection libsrtp should have offered. They seem to have done some processing on SRTCP packets before they use libsrtp to authenticate them. Authentication always needs to be the first thing you do with something you receive over the Internet.

Buffer overflow

A second issue here is indicated by the phrase “buffer overflow”. This is an ancient class of vulnerability, which is almost entirely prevented by using more modern languages like Rust, Go, or even Java. If you’re stuck with C or C++, you should make sure to use defensive coding standards to avoid bad practices, and apply sanitizers and fuzzers to find memory corruption bugs before they turn into vulnerabilities.

It’s never pleasant to see large-scale, high-risk vulnerabilities. They put peoples’ data, work, and lives at risk. But it’s good when these vulnerabilities are found and fixed, and it gives us the opportunity to learn. This case is a good reminder that we should never trust data from the Internet, and we should use modern tools to avoid memory corruption.

About the author

Richard Barnes is an IETF appointee to the ISOC Board of Trustees. He is employed as the Chief Security Architect for Collaboration at Cisco. He currently chairs the IETF PERC working group, and is actively involved in working groups across the security and applications areas. Mr. Barnes has been involved in the technical work and management of the IETF for several years. He has served as Area Director for Real-time Applications and Infrastructure (RAI) and co-chair of the IETF ECRIT and GEOPRIV working groups. He is co-author of several RFCs related to geolocation, emergency services, and security, including RFC 6155, RFC 6280, RFC 6394, and RFC 6848. He is also co-author of the book VoIP Emergency Calling: Foundations and Practice (John Wiley and Sons, 2010). Richard has also served as the chair of the RIPE Measurements, Analysis and Tools working group, and on the program committee for the Middle East Network Operators Group (MENOG). Prior to joining Cisco, Mr. Barnes was Firefox Security Lead at Mozilla. In that role, he was responsible for assuring the security of the Firefox web browser. Before joining Mozilla, he was a Principal Investigator at BBN Technologies, leading research activities related to real-time applications and Internet security. He holds a B.A. in Mathematics and an M.S. in Mathematics from the University of Virginia.