9 ms·

Piercing Through WhatsApp’s Encryption

230 points by xnyhps 13y ago

tptacek 13y ago
A lot of cryptographic mistakes people make, you can blame on the 1990s. For instance, the ubiquitous CBC padding oracle (most recently of TLS "Lucky 13" fame) is the product of MAC-then-encrypt constructions, where attackers are given the privilege of manipulating ciphertext without having it checked by a MAC. We didn't have a mathematical proof to tell us not to do mac-then-encrypt until after the 1990s. So if you have that bug, you might consider blaming the 1990s. But using the same RC4 key in both directions of an encrypted transport isn't just a bug known in the 1990s; it is the emblematic cryptographic attack of the 1990s, the one crypto flaw that even non-crypto pentesters could reliably deploy. For instance, bidirectionally shared RC4 keys broke the Microsoft VPN scheme, a bug discovered by Peter "Mudge" Zatko when there was still a L0pht Heavy Industries. So my point is, this is a bit sad. I should add, recycling the keystream of a stream cipher is worse than he makes it sound. The attack he's describing is called "crib dragging" and implies that an attacker has access to plaintext. But attackers don't need access to plaintext to attack repeated-key XOR, which is what a set of ciphertexts encrypted under the same stream cipher keystream works out to be.
- dmix 13y ago
  A good question is how the engineer implemented a half-baked crypto system with 1990s style flaws in the first place. Considering the startup is relatively well funded. Ignorance? Lack of research? Lack of industry best standards? This seems to keep happening all the time. Although most programming in general is full of hackery and rookie code used in production. So that itself isn't alarming. I'm just curious if it's the security industry itself is particularly in need of better communication of best practices and things to avoid. Maybe more work with designers/writers to create online guides is needed.
  - kcbanner 13y ago
    I only took two crypto courses during my degree and these attacks were demonstrated as examples of simple things no one should get wrong. Its just plain embarrassing for these devs to screw this up.
  - deleted 13y ago
    [deleted]
  - mahyarm 13y ago
    From my experience, it's because security is a half baked priority #50 usually at startups. A sum total of a week was probably spent by some back-end engineer 2 years ago on message security since it's not a selling point. They probably record every single message too since storage without transmission is cheap and avoids a class of bugs with deletion. The stored histories could become a business advantage later to mine chat histories for marketing and advertising data like facebook, twitter, google and everyone else. They say they charge now to avoid a marketing driven approach, but cable TV has made similar promises in it's starting days too. Also they run on such platforms as blackberry, nokia s40 devices, windows phone and symbian where plopping in some C crypto library probably wasn't practical. From what I know, most crypto libaries are written in some C family language or you have bouncycastle for java. Everything else is relatively obscure or broken. So something they could roll by themselves might of been what they have to choose from. For many companies, security is something you do the motions for like you would with government paperwork and compliance, not necessarily because it's important to you. Unfortunately the average person only cares about door lock security, not real crypto secured products.
    - martinraag 13y ago
      WhatsApp is over 4 years old with over 300 million (claimed) active users. I would expect them to have addressed security by this point. Especially after their previous blunders, I'd imagine hiring a security expert or having a third party audit their code being on the top of their list. Apparently not. I think these news and concerns often don't make their way to a bulk of their users, who probably aren't very tech savvy. If they don't see any user defection as a result of these issues being uncovered, then I'm not surprised about their lax stance on security.
      - newman314 13y ago
        LOL. You would cringe at the amount of duct-taped infrastructure that plagues most large enterprises. Their viewpoint often is, "We have a firewall and antivirus so we should be good right"?
      - mahyarm 13y ago
  - Perseids 13y ago
    > I'm just curious if it's the security industry itself is particularly in need of better communication of best practices and things to avoid. The thing is, there is no such thing as a security industry that would be interested in pushing such best practices. It's a little bit like occupational safety. There are companies that sell hearing protectors, i.e. solutions to some specific aspects of occupational safety, just like there are companies selling firewalls to protect against some specific aspects of IT security. But you cannot sell one product to protect against all IT security threats that emerge in a software company as there are security concerns in every aspect of an IT product. On the server side it is about protecting the user content against outside threats (firewalls, SQLi, password hashing, log protection and redaction, strong SSH logins, DoS, etc), on the protocol side it is about authentication and encryption (MITM attacks, content separation (think about the beast attacks), strong crypto, using the right crypto for the job, DoS), on the client side it is about folk security models and social engineering (strong passwords, password resets, two factor authentication, social engineering, UI design). Occupational safety on a construction site has to be considered by every worker and in every part of the construction. IT security is just as much pervasive to software engineering. You think implementing a search feature for your website is not security sensitive? You might just have compromised your user login because of cross site scripting. Logging debug information is harmless? Not so much if your database password is output to the user in case of a poorly written exception filter. Heck, even simply storing some user data in a dictionary can be the cause of a DoS [1]. Basically what I saying is that IT security is not the responsibility of some specialised security industry, but of the whole IT industry. [1] http://events.ccc.de/congress/2011/Fahrplan/attachments/2007_28C3_Effective_DoS_on_web_application_platforms.pdf http://events.ccc.de/congress/2011/Fahrplan/attachments/2007...
- yuhong 13y ago
  Yea, a lot of MS's protocols and file formats from the 1996/1997 era has this flaw for example.
- goblin89 13y ago
  Dan Boneh's Cryptography on Coursera covers attacks on key reuse in first week. Actually, the very first programming assignment gives a few messages encrypted using the same “one-time” pad and asks to decipher one of them (indeed, with no access to plaintext). It's cool to see a real-world example of such an attack.
  - Mithrandir 13y ago
    Video and 1st assignment for the curious: https://class.coursera.org/crypto-preview/lecture/6 https://class.coursera.org/crypto-preview/lecture/6 https://class.coursera.org/crypto-preview/quiz/attempt?quiz_id=18 https://class.coursera.org/crypto-preview/quiz/attempt?quiz_...
nasalgoat 13y ago
I'm surprised they'd make such a rookie mistake when there are hundreds of good encryption methods online to crib from, just a Google search away.
- lukeh 13y ago
  Agreed. It can be fun and/or sometimes necessary to roll your own, but, at least get it reviewed by someone who knows what they're doing - anyone on the IETF Kitten working group, for example (for a SASL mechanism).
  - lukeh 13y ago
    Or, use RFC 4121. It's not just for Kerberos: GSS EAP (Moonshot), BrowserID (Persona), and SAML EC all use it for message integrity and privacy. And those specifications were all written by smart people (save for myself, at least) who could have rolled their own if they wanted to.
    - tptacek 13y ago
      For the love of almighty and merciful God please do not use GSSAPI. MAC-then-encrypt? CRC checksums? All-zeroes IV? CBCMAC? This stuff died in the '90s for a reason.
      - lukeh 13y ago
        GSS-API says nothing about any of the things you mention, it's an abstract standard (like SASL) that can be profiled for many different authentication and message integrity/confidentiality systems. The DES-based Kerberos GSS-API mechanism you're thinking of should be dying out by now. Granted, RFC 3962 does MAC-then-encrypt. This is being addressed in draft-ietf-kitten-aes-cbc-hmac-sha2.
        tptacek 13y ago
        Those are all things I took out of 3962. But furthermore, I'm now even more confused by your recommendation. If it's a metastandard (which has always been the rap on stuff like SASL), how does it help them design good crypto? I can't see any reason in the world to adopt GSSAPI. I strongly recommend that nobody else do so.
PakG1 13y ago
Here's what I'm sad about. Does every single web and mobile app that gets made by anyone these days now require an extensive knowledge of how to do security right? If so, that sucks, given how big the field is. Or do we all need to go and hire tptacek for a quarterly security audit? I imagine that can get quite expensive. It really gets in the way of just making things and putting them up; I think kind of kills the spirit of creation and entrepreneurship. :( I mean, it's great for people who are truly interested in security, but what if you're not? Are you doomed to fail at the startup game if you don't know security well?
- Everlag 13y ago
  According to wikipedia this company has 300 million users each paying some form of currency every month. Is it that much to ask that a company that large performs a security audit quarterly?
  - PakG1 13y ago
    Fair enough, but I'm asking about side projects.
- mikeash 13y ago
  When in doubt, don't reinvent the wheel. If TLS covers your use case, use TLS. Unfortunately, it appears that you are not at all doomed if you don't know security well. I say "unfortunately" because I'd rather have fewer secure products than the massive array of insecure products we enjoy today.
  - emn13 13y ago
    And I think a large part of that is because of the unbelievably irresponsible legislation on the matter - where the punishment for "hacking" is often punitive, but the punishment for negligence is often non-existent. I think it's kind of like cars and the corresponding (lack of) traffic & vehicle safety rules a century ago: right now it's everybody for themselves, but what you really need are rules that encourage those in a position to cause improvement to actually improve. Developers like us and firms that employ them need to be liable for security exploits - preferably with good enforcement with many small fines rather than a few "examples" that get the book thrown at them. And hackers, even if dubiously motivated, shouldn't be driven underground by punitive measures because that causes a really unhealthy head-in-the-sand dynamic.
SnaKeZ 13y ago
Alternative...Google Hangouts?
- scott_karana 13y ago
  More secure in a sense, but why should anyone need to give the keys to their instant messaging castle to Google? I'm shocked that a startup with a similar approach to WhatsApp hasn't made a reasonable rigorous application yet.
  - frank_boyd 13y ago
    > why should anyone need to give the keys to their instant messaging castle to Google? Equivalent to cc'ing the NSA.
    - pathy 13y ago
      Let's be honest, I'd rather have NSA snoop on what on my texts than a criminal. Both are bad but NSA is at least slightly better.
      - frank_boyd 13y ago
        The trick is to let nobody snoop on your texts.
        pathy 13y ago
        Which is, as we can see in the GP, is hard ;). Whatsapp - broken encryption Google Hangout - NSA Texts - NSA (and others) Facebook Messenger - NSA iMessage - probably NSA, though I don't know. and so forth. Most commonly used text services are woefully leaky.
    - scott_karana 13y ago
      Yes, that was exactly my point :)
  - 13y ago
frank_boyd 13y ago
https://heml.is/ https://heml.is/ currently looks like the best concept of a solution to the problem - if they keep their promise: > Will it be Open Source? > We have all intentions of opening up the source as much as possible for scrutiny and help! But it's not done yet.
- NKCSS 13y ago
  And it only targets iOS and Android...
  - Sami_Lehtinen 13y ago
    Which are both bad platforms if you want to maintain privacy.
    - frank_boyd 13y ago
      Exactly. And it sucks donkey balls.
chmars 13y ago
In other news, WhatApp's website got hacked, well, defaced this morning: Screenshot: http://i.imgur.com/wY2zDl7.jpg http://i.imgur.com/wY2zDl7.jpg Source (German): http://stadt-bremerhaven.de/server-von-whatsapp-gehackt/ http://stadt-bremerhaven.de/server-von-whatsapp-gehackt/
- sdoering 13y ago
  Well the update says it were the DNS-Servers, that got "hacked" not the WhatsApp-Servers. Not that this makes me like this thing any better, but I thought the correct info should be put into the discussion. ;-)
  - chmars 13y ago
    I wasn't aware of this important difference, thank you!
skion 13y ago
I love how exactly this mistake is covered in detail in the first week of Dan Boneh's crypto course: https://class.coursera.org/crypto-008/class The Russians made the same mistake in WWII, but Whatsapp shows the relevance today.

230 points by xnyhps 13y ago

A lot of cryptographic mistakes people make, you can blame on the 1990s. For instance, the ubiquitous CBC padding oracle (most recently of TLS "Lucky 13" fame) is the product of MAC-then-encrypt constructions, where attackers are given the privilege of manipulating ciphertext without having it checked by a MAC. We didn't have a mathematical proof to tell us not to do mac-then-encrypt until after the 1990s. So if you have that bug, you might consider blaming the 1990s. But using the same RC4 key in both directions of an encrypted transport isn't just a bug known in the 1990s; it is the emblematic cryptographic attack of the 1990s, the one crypto flaw that even non-crypto pentesters could reliably deploy. For instance, bidirectionally shared RC4 keys broke the Microsoft VPN scheme, a bug discovered by Peter "Mudge" Zatko when there was still a L0pht Heavy Industries. So my point is, this is a bit sad. I should add, recycling the keystream of a stream cipher is worse than he makes it sound. The attack he's describing is called "crib dragging" and implies that an attacker has access to plaintext. But attackers don't need access to plaintext to attack repeated-key XOR, which is what a set of ciphertexts encrypted under the same stream cipher keystream works out to be.

dmix 13y ago
A good question is how the engineer implemented a half-baked crypto system with 1990s style flaws in the first place. Considering the startup is relatively well funded. Ignorance? Lack of research? Lack of industry best standards? This seems to keep happening all the time. Although most programming in general is full of hackery and rookie code used in production. So that itself isn't alarming. I'm just curious if it's the security industry itself is particularly in need of better communication of best practices and things to avoid. Maybe more work with designers/writers to create online guides is needed.
- kcbanner 13y ago
  I only took two crypto courses during my degree and these attacks were demonstrated as examples of simple things no one should get wrong. Its just plain embarrassing for these devs to screw this up.
- deleted 13y ago
  [deleted]
- mahyarm 13y ago
  From my experience, it's because security is a half baked priority #50 usually at startups. A sum total of a week was probably spent by some back-end engineer 2 years ago on message security since it's not a selling point. They probably record every single message too since storage without transmission is cheap and avoids a class of bugs with deletion. The stored histories could become a business advantage later to mine chat histories for marketing and advertising data like facebook, twitter, google and everyone else. They say they charge now to avoid a marketing driven approach, but cable TV has made similar promises in it's starting days too. Also they run on such platforms as blackberry, nokia s40 devices, windows phone and symbian where plopping in some C crypto library probably wasn't practical. From what I know, most crypto libaries are written in some C family language or you have bouncycastle for java. Everything else is relatively obscure or broken. So something they could roll by themselves might of been what they have to choose from. For many companies, security is something you do the motions for like you would with government paperwork and compliance, not necessarily because it's important to you. Unfortunately the average person only cares about door lock security, not real crypto secured products.
  - martinraag 13y ago
    WhatsApp is over 4 years old with over 300 million (claimed) active users. I would expect them to have addressed security by this point. Especially after their previous blunders, I'd imagine hiring a security expert or having a third party audit their code being on the top of their list. Apparently not. I think these news and concerns often don't make their way to a bulk of their users, who probably aren't very tech savvy. If they don't see any user defection as a result of these issues being uncovered, then I'm not surprised about their lax stance on security.
    - newman314 13y ago
      LOL. You would cringe at the amount of duct-taped infrastructure that plagues most large enterprises. Their viewpoint often is, "We have a firewall and antivirus so we should be good right"?
    - mahyarm 13y ago
- Perseids 13y ago
  > I'm just curious if it's the security industry itself is particularly in need of better communication of best practices and things to avoid. The thing is, there is no such thing as a security industry that would be interested in pushing such best practices. It's a little bit like occupational safety. There are companies that sell hearing protectors, i.e. solutions to some specific aspects of occupational safety, just like there are companies selling firewalls to protect against some specific aspects of IT security. But you cannot sell one product to protect against all IT security threats that emerge in a software company as there are security concerns in every aspect of an IT product. On the server side it is about protecting the user content against outside threats (firewalls, SQLi, password hashing, log protection and redaction, strong SSH logins, DoS, etc), on the protocol side it is about authentication and encryption (MITM attacks, content separation (think about the beast attacks), strong crypto, using the right crypto for the job, DoS), on the client side it is about folk security models and social engineering (strong passwords, password resets, two factor authentication, social engineering, UI design). Occupational safety on a construction site has to be considered by every worker and in every part of the construction. IT security is just as much pervasive to software engineering. You think implementing a search feature for your website is not security sensitive? You might just have compromised your user login because of cross site scripting. Logging debug information is harmless? Not so much if your database password is output to the user in case of a poorly written exception filter. Heck, even simply storing some user data in a dictionary can be the cause of a DoS [1]. Basically what I saying is that IT security is not the responsibility of some specialised security industry, but of the whole IT industry. [1] http://events.ccc.de/congress/2011/Fahrplan/attachments/2007_28C3_Effective_DoS_on_web_application_platforms.pdf http://events.ccc.de/congress/2011/Fahrplan/attachments/2007...
yuhong 13y ago
Yea, a lot of MS's protocols and file formats from the 1996/1997 era has this flaw for example.
goblin89 13y ago
Dan Boneh's Cryptography on Coursera covers attacks on key reuse in first week. Actually, the very first programming assignment gives a few messages encrypted using the same “one-time” pad and asks to decipher one of them (indeed, with no access to plaintext). It's cool to see a real-world example of such an attack.
- Mithrandir 13y ago
  Video and 1st assignment for the curious: https://class.coursera.org/crypto-preview/lecture/6 https://class.coursera.org/crypto-preview/lecture/6 https://class.coursera.org/crypto-preview/quiz/attempt?quiz_id=18 https://class.coursera.org/crypto-preview/quiz/attempt?quiz_...

nasalgoat 13y ago

I'm surprised they'd make such a rookie mistake when there are hundreds of good encryption methods online to crib from, just a Google search away.

lukeh 13y ago
Agreed. It can be fun and/or sometimes necessary to roll your own, but, at least get it reviewed by someone who knows what they're doing - anyone on the IETF Kitten working group, for example (for a SASL mechanism).
- lukeh 13y ago
  Or, use RFC 4121. It's not just for Kerberos: GSS EAP (Moonshot), BrowserID (Persona), and SAML EC all use it for message integrity and privacy. And those specifications were all written by smart people (save for myself, at least) who could have rolled their own if they wanted to.
  - tptacek 13y ago
    For the love of almighty and merciful God please do not use GSSAPI. MAC-then-encrypt? CRC checksums? All-zeroes IV? CBCMAC? This stuff died in the '90s for a reason.
    - lukeh 13y ago
      GSS-API says nothing about any of the things you mention, it's an abstract standard (like SASL) that can be profiled for many different authentication and message integrity/confidentiality systems. The DES-based Kerberos GSS-API mechanism you're thinking of should be dying out by now. Granted, RFC 3962 does MAC-then-encrypt. This is being addressed in draft-ietf-kitten-aes-cbc-hmac-sha2.
      - tptacek 13y ago
        Those are all things I took out of 3962. But furthermore, I'm now even more confused by your recommendation. If it's a metastandard (which has always been the rap on stuff like SASL), how does it help them design good crypto? I can't see any reason in the world to adopt GSSAPI. I strongly recommend that nobody else do so.

PakG1 13y ago

Here's what I'm sad about. Does every single web and mobile app that gets made by anyone these days now require an extensive knowledge of how to do security right? If so, that sucks, given how big the field is. Or do we all need to go and hire tptacek for a quarterly security audit? I imagine that can get quite expensive. It really gets in the way of just making things and putting them up; I think kind of kills the spirit of creation and entrepreneurship. :( I mean, it's great for people who are truly interested in security, but what if you're not? Are you doomed to fail at the startup game if you don't know security well?

Everlag 13y ago
According to wikipedia this company has 300 million users each paying some form of currency every month. Is it that much to ask that a company that large performs a security audit quarterly?
- PakG1 13y ago
  Fair enough, but I'm asking about side projects.
mikeash 13y ago
When in doubt, don't reinvent the wheel. If TLS covers your use case, use TLS. Unfortunately, it appears that you are not at all doomed if you don't know security well. I say "unfortunately" because I'd rather have fewer secure products than the massive array of insecure products we enjoy today.
- emn13 13y ago
  And I think a large part of that is because of the unbelievably irresponsible legislation on the matter - where the punishment for "hacking" is often punitive, but the punishment for negligence is often non-existent. I think it's kind of like cars and the corresponding (lack of) traffic & vehicle safety rules a century ago: right now it's everybody for themselves, but what you really need are rules that encourage those in a position to cause improvement to actually improve. Developers like us and firms that employ them need to be liable for security exploits - preferably with good enforcement with many small fines rather than a few "examples" that get the book thrown at them. And hackers, even if dubiously motivated, shouldn't be driven underground by punitive measures because that causes a really unhealthy head-in-the-sand dynamic.

SnaKeZ 13y ago

Alternative...Google Hangouts?

scott_karana 13y ago
More secure in a sense, but why should anyone need to give the keys to their instant messaging castle to Google? I'm shocked that a startup with a similar approach to WhatsApp hasn't made a reasonable rigorous application yet.
- frank_boyd 13y ago
  > why should anyone need to give the keys to their instant messaging castle to Google? Equivalent to cc'ing the NSA.
  - pathy 13y ago
    Let's be honest, I'd rather have NSA snoop on what on my texts than a criminal. Both are bad but NSA is at least slightly better.
    - frank_boyd 13y ago
      The trick is to let nobody snoop on your texts.
      - pathy 13y ago
        Which is, as we can see in the GP, is hard ;). Whatsapp - broken encryption Google Hangout - NSA Texts - NSA (and others) Facebook Messenger - NSA iMessage - probably NSA, though I don't know. and so forth. Most commonly used text services are woefully leaky.
  - scott_karana 13y ago
    Yes, that was exactly my point :)
- 13y ago

frank_boyd 13y ago

https://heml.is/ https://heml.is/ currently looks like the best concept of a solution to the problem - if they keep their promise: > Will it be Open Source? > We have all intentions of opening up the source as much as possible for scrutiny and help! But it's not done yet.

NKCSS 13y ago
And it only targets iOS and Android...
- Sami_Lehtinen 13y ago
  Which are both bad platforms if you want to maintain privacy.
  - frank_boyd 13y ago
    Exactly. And it sucks donkey balls.

chmars 13y ago

In other news, WhatApp's website got hacked, well, defaced this morning: Screenshot: http://i.imgur.com/wY2zDl7.jpg http://i.imgur.com/wY2zDl7.jpg Source (German): http://stadt-bremerhaven.de/server-von-whatsapp-gehackt/ http://stadt-bremerhaven.de/server-von-whatsapp-gehackt/

sdoering 13y ago
Well the update says it were the DNS-Servers, that got "hacked" not the WhatsApp-Servers. Not that this makes me like this thing any better, but I thought the correct info should be put into the discussion. ;-)
- chmars 13y ago
  I wasn't aware of this important difference, thank you!

skion 13y ago

I love how exactly this mistake is covered in detail in the first week of Dan Boneh's crypto course: https://class.coursera.org/crypto-008/class The Russians made the same mistake in WWII, but Whatsapp shows the relevance today.