People have been paranoid of telecommunications security in recent months. Why? Of course you know why. The news is overflowing with worldwide assertions of espionage, hacking, and the bitter taste of modern technological complexity. It's almost daunting, how our every day lives have become saturated by some absurd fear of a consuming, constant, ever-present eye.
And here we are again, faced with a vulnerability that exposes all of our most precious tokens to the massive potential for risk. Sad face yet again. Even Alyssa Milano has commented via Twitter on the importance of acknowledging this bug. Oh, HeartBleed. You've brought the world together in a concerted howl of paranoia.
But do we really fully understand the risk? Apparently not. What everyone (including me) had missed about this vulnerability is its less obvious usage: telecommunications.
The HeartBeat Extension isn't just used in TLS, it's also a part of the DTLS protocol. The DTLS protocol needs HeartBeat even more than TLS does. Why? It's connectionless. DTLS is designed to run over IP protocols such as UDP, SCTP, DCCP, and more.
Messages in DTLS are not guaranteed to arrive on the other end of the conversation. In other words, when Alice is on a phone call with her friend Bill and says "I'll hate your mother's cooking", Bill may actually hear "I hate your mother". In DTLS, this is normal, as opposed to TLS, which sits on top of protocols that protect against data loss during a session.
To protect against the potential for data loss, the HeartBeat extension can be used to ensure a peer in the conversation is still alive. This helps validate that when a message is sent over the network using DTLS, it isn't being sent to a dead host. HeartBeats verify that the peer is still alive and can receive messages. Whether that message will be processed is another story. Alice can at least guarantee that the other side of the conversation has received the data.
Why is this important? DTLS is very common in telecommunications equipment. In fact, the most common office phones on the market can use DTLS to secure phone calls. Cisco's SIP phone uses DTLS to ensure confidentiality and integrity of phone calls over a virtual private network to a VPN head. This means that any embedded telecommunications product that uses DTLS is potentially subject to the HeartBleed vulnerability.
This widens the applicability of HeartBleed to an entirely different infrastructure: worldwide telecommunications. The peering and internal infrastructures that route telecommunications messages, including voice calls, SMS, MMS, HLR, and more, often use SCTP for data transfer. To secure these messages? They use DTLS. This means that critical internal and externally accessible networks that route our most private telecom messages can be subject to HeartBleed.
This makes you think a bit differently about the vulnerability, doesn't it? From an architectural perspective, you can now compromise a high percentage of the two most important pieces of infrastructure in modern technology today: web/email services and telecommunications.
If you ask me, this makes the HeartBleed bug a much bigger threat than remote code execution against Apache or OpenSSH. With RCE you have to work to get the data you want. With HeartBleed? Just extract the session tokens or private keys you need, and let your automated tools do the rest of the work.
I mean, hey, if Alyssa Milano is tweeting about it? It must be legit ;-)
D
No comments:
Post a Comment