• Sign Up, It's Free
  • Get Our Newsletter Plans & Pricing
    Generic selectors
    Exact matches only
    Search in title
    Search in content
    Post Type Selectors
  • Categories
    • Hybrid Work
    • Video Conferencing
    • Cloud Calling
    • Collaboration Devices
    • Innovation
    • Customer Experience
    • Event Management
  • Hybrid Work
  • Video Conferencing
  • Cloud Calling
  • Collaboration Devices
  • Innovation
  • Customer Experience
  • Event Management
 
  • Blog home
  • >
  • Engineering
  • >
  • # Stay safe – Always authenticate
Engineering

# Stay safe – Always authenticate

Aug 17, 2020 — Webex Team

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.

Click here to learn more about the offerings from Webex and to sign up for a free account. 

If everything has changed, why hasn’t my office?
Jun 1, 2023 — Chris Barwick

Experience Webex at Cisco Live 2023: The Future of Workspaces, Workstyles, and Customer Experience.
Jun 1, 2023 — Geoffrey Huang

Driving Hybrid Work Forward with Audi
Jun 1, 2023 — Aruna Ravichandran

How to reduce risks when using Artificial Intelligence (AI)
May 25, 2023 — Gautham Sridharan

UCentric Automated Migration to Webex Calling
May 16, 2023 — Paul McGuinness

Connect With Us
  • This newsletter is for you.

    Our monthly newsletter, The Collaboratory, features fresh insights from collaboration experts, plus tips & trends, new product announcements, and the latest on the biggest events of the year. Sign up to stay in the loop!

Webex logo
Get started for free.
Additional features, storage, and support start at just one low price.
Sign Up, It's Free See Plans & Pricing
Small Business
  • Pricing
  • Webex App
  • Meetings
  • Calling
  • Messaging
  • Screen Sharing
Enterprise
  • Webex Suite
  • Calling
  • Meetings
  • Messaging
  • Slido
  • Webinars
  • Events
  • Contact Center
  • Experience Management
  • imimobile
  • Security
  • Control Hub
Devices
  • Headsets
  • Cameras
  • Desk Series
  • Room Series
  • Board Series
  • Phone Series
  • Accessories
Solutions For
  • Education
  • Healthcare
  • Government
  • Finance
  • Sports & Entertainment
  • Frontline
  • Nonprofits
  • Startups
  • Hybrid Work
  • Integrations
  • Developers
Resources
  • Downloads
  • Help Center
  • Join a Test Meeting
  • Online Classes
  • Accessibility
  • Inclusivity
  • Live & On-Demand Webinars
  • Webex Community
  • News & Innovations
Company
  • Cisco
  • Contact Support
  • Contact Sales
  • Webex Blog
  • Webex Thought Leadership
  • Webex Merch Store
  • Careers
  • Webex Leap
© Cisco and/or its affiliates. All Rights Reserved.
  • Terms & Conditions
  • Privacy Statement
  • Cookies
  • Trademarks
  • English
    • English