Lessons We Learned from a Recent Attack

Share on facebook
Share on twitter
Share on linkedin
Share on reddit
Share on email

Joël Alwen, Cryptographer at Wickr
July 3, 2019Recently, the folks over at Forcepoint Security Labs published an interesting blog post detailing their findings on the insecurity of the Telegram messaging system’s bots. The discoveries were made in the course of Forcepoint’s investigation into malware which was using Telegram bots as Command & Control Infrastructure. It turns out that Telegram has made some unexpected design decisions surrounding their bots which resulted in weaker security than one might expect. Ultimately, these weaknesses allowed Forcepoint’s team to completely compromise the malware’s C&C Infrastructure. Despite the happy ending, this story highlights two general and very important points I think are worth considering:

  1. It is difficult to over-emphasize the importance of clear and consistent communication with end-users about what security a product does and does not.
  2. When designing useful features of a product, it is particularly important to consider the effects that those features could have on the overall security of the product.

Communication is King

Even the best tool can only be effective if it is wielded correctly. More to the point, properly communicating the capabilities and limits of a security tool is essential if users are to remain protected.

Returning to Forcepoint’s investigation of the Telegram bots, it seems clear that the malware designers were oblivious to the limitations of the security mechanism employed by the bots. Why is this? Well, Telegram bills itself as a secure and private messaging system. Indeed, its 1-1 “Secret Chats” are end-to-end encrypted using the (proprietary) MTProto protocol. However, low-level analysis by Forcepoint led to the realization that Telegram bots actually use the TLS protocol which is known to suffer from significantly more vulnerabilities than the MTProto. Admittedly, MTProto is far less well-studied by independent cryptographers than TLS. Moreover, those that have studied MTProto have raised some concerns about what they found. Still, the bot’s use of TLS is precisely what made it possible for Forcepoint’s team to perform a Man-in-the-Middle attack on the malware’s C&C channel.

The key point here is that this weaker level of security for Telegram’s bots does not seem to be well-documented by Telegram. In any case, it was not widely known, and the revelation comes as a surprise even among experts in the field. In fact, it took a successful and publicized attack by a dedicated infused team for this information to reach the wider public. I strongly believe that this is not the way such limitations should become known. While in this case the attack’s victim was a malware author — and may not have been worth our concern — that won’t be true in general. The vast majority of Telegram bot users will have far more legitimate reasons to want their traffic to remain secure.

Functionality, but with Forethought

The second point I want to make is highlighted by the events that took place after the initial MitM attack by Forcepoint. It turns out that part of Telegram’s bot API are some very powerful commands. Central to the investigation was the command to forward any message previously received by the bot to an arbitrary Telegram account or channel. Moreover, past messages are indicated via a predictable counter (which always begins at 0). The final fact that made this command so effective for the Forcepoint team is that all other information required to execute bot commands could be readily extracted from the decrypted traffic available to a MitM attacker. So, in effect, by gathering the required information and iterating through all counter values, the Forcepoint team was able to recover the entire message history received by the bot.

The point here is that by designing the API with such powerful — yet easily accessible — commands, the Telegram bots became very powerful tools for an attacker. Unfortunately, this functionality of bots is available as part of the API out of the box so, although it may not be needed by any given bot, the functionality is there. In essence, this is a great example of the unintended side effects of making tools too powerful or functional for their users’ good.

In fact, this is not the first time that the intended capabilities of one of Telegram’s API’s has had very serious side effects. In 2016, security researchers described an attack by the threat actor known as Rocket Kitten which resulted, amongst other things, in the enumeration of millions of Iranian Telegram users. Along with vulnerabilities in the global phone network, the attack made critical use of the open API made available by Telegram. Unfortunately, at the time no rate limit was enforced in the API, which provided an easy opening to enable the attackers to automate the discovery of Iranian phone numbers tied to Telegram accounts. This automation enormously amplified the effectiveness of their attack. Ultimately, once the attack came to light, rate limits on the API were instituted. However, the point remains. It behooves us designers of sensitive and powerful tools to think very carefully, as a vital part of the design process, about the ways in which our products might be abused.

A Mirror and a Balancing Act

As we at Wickr continue building out our API, extending Wickr’s integration capabilities and designing ever more capable and expressive bots, this recent story has given us pause to look in the mirror and think carefully about the balances and bargains that we strike every day. We reflected on how we navigate between capabilities vs. security, the resources we spend on innovation vs. assurance and the line we walk in communicating with our users between simplicity and clarity vs. accuracy and detail. We believe that the way we address and resolve these kinds of conflicts is as central to determining who we are and what it is we are really doing as any technical feature we could possibly build. Our commitment is to not just to do things, but to do them right — thinking of our customer’s security interests above all else.

As the technology, security and crypto nerds we are, sometimes it’s almost a little too easy to lose ourselves in designing and building the most amazing and awesome tools we can think of. The Forcepoint team’s story, and others like it, serve a valuable purpose: to remind us that there’s much more to the picture here if we want to build truly great systems that best serve all of our interests.