Category Archives: Security and Privacy

Where to store your auth token? Cookie or JS? Both!

In the security community, there is a contention on whether an auth token (think OAuth access_token, JSESSIONID, ...) should be stored inside a cookie or if should live within javascript, so e.g. a variable in a single page application, local storage or session storage, etc.

If it is stored in javascript, all requests to resources that require auth have to be made from JS, so it is usually difficult to retrofit an application that was written for cookie-based auth to have it store the auth token in JS.

That being said, for new applications, the developers have to make this decision. Which one is more secure? It is often said that cookies are safer against XSS (with the HttpOnly flag set), but using cookies makes your app more vulnerable to CSRF. Tokens within JS, on the other hand, are easier to exfiltrate through XSS but CSRF therefore becomes much less of a problem.

But why not just combine the two approaches to get the best of both worlds? The web application can split the auth_token into two by doing: 

r := random_bytes()
share1 := auth_token XOR r
share2 := r

share1 can then be set as a cookie and share2 as a JS variable. The web frontend then needs to always provide both shares to the backend to authorize a request.

Instead of XOR, other cryptographic operations are possible, but XOR is especially performant and should be easily available in every programming environment.

A response to the denials from moxie and WhatsApp

This post is a direct response to moxie's post, hence the original title "There is a WhatsApp Backdoor", which I have changed now because I find the "Backdoor vs. Vulnerability" discussion uninteresting.

You can argue if we are looking at a vulnerability, so something that is in there by error, or a backdoor, i.e. something that is in there deliberately. But this discussion is not very interesting.

Facebook and moxie do not deny that there is a vulnerability that can be used to 'wiretap' targeted conversations, for example by governments with access to WhatsApp servers. For details on the vulnerability, see my initial blog post, some slides, or my video. In the video, you can also see that the vulnerability can not be avoided by verifying fingerprints or checking a checkbox in the WhatsApp settings.

The UX 'downgrade' we are talking about

Signal does not have this vulnerability, but WhatsApp has it. So how are they different? How more difficult is Signal to use?

Imagine you dump your phone into the ocean and only a month later you get a new phone. Then during this one month time period, some friends might've sent you messages. In WhatsApp, your friends phones are being instructed to automatically re-encrypt and retransmit. But they don't know if they are sending the messages indeed to you or the government. Then, and only if your friends specifically asked WhatsApp to do so, they will see a warning that there could've been something shady going on. Signal on the other hand will tell your friends something like "there might've been something shady going on. Do you want to resend your message?".

First: How often do those situations occur? I'd say not so often, WhatsApp says "millions of messages", which is actually not that much considering they are sending like 42 billion (with a b) messages per day through their servers.

Second: Is it really that much to ask for from the users?

Even with the "give me additional security" setting, WhatsApp retransmits messages

So there is this setting in WhatsApp "Show security features". It basically tells WhatsApp "Hey, I'm especially concerned about my privacy. I know what I am doing. Please give me the best privacy possible". But even with this setting enabled, WhatsApp will automatically re-encrypt and retransmit messages, leaving the sender vulnerable.

Moxie tries to explain why this choice has been made:

The choice to make these notifications "blocking" would in some ways make things worse. That would leak information to the server about who has enabled safety number change notifications and who hasn't, effectively telling the server who it could MITM transparently and who it couldn't; something that WhatsApp considered very carefully.

This claim is false. Those "blocking" clients could instead retransmit a message of the same length that just contains garbage, i.e. instead of "Login with the password d98y289whcma0", they'd send "0000000000000000000000000000000000000" and this message would just not be displayed by the receiver's phone. By the guarantees of encryption, those two messages are indistinguishable in the encrypted form. Hence, this technique would make identifying users with the additional security enabled on a large scale impossible.

Only one message?

There have been claims that only one single message is exposed before the sender notices that something shady might be going on. For technical reasons, only the case with one message can be demonstrated, but there is reason to believe the attack can be extended to a longer conversation. The Signal protocol allows "lost or out-of-order messages". Therefore it should be possible for the WhatsApp server to block all "message has been received" notifications for a long conversation while it still correctly forwards the actual text messages. The "receipt" notifications, if encrypted at all, can be distinguished from the normal text messages because they are the ones sent directly after the receiver receives the message.

The users would then only get displayed one tick for all their messages, but won't bother because it is working. After days, weeks or maybe even month, the described attack can then be launched in order to get a copy of the whole transaction history since that point in time.

File transfers and voice calls affected as well

Not only messages, but also voice calls and file transfers can be intercepted with this vulnerability.

moxie, I do respect all the work you've done to promote widespread encryption. But regarding this topic you're wrong.

Facebook, please just fix this. Here is a personal suggestion what to do.

 

What is Facebook going to do? A suggestion.

The WhatsApp retransmission vulnerability has gained a lot of public attention today led by an article published by The Guardian. So what can Facebook (the owner of WhatsApp) do now? I think chances are pretty low that they come forward and say "yep, this is a backdoor, here is a copy of the NSL". Will they say "yep, this is a critical vulnerability, but it took us 8 month and 20 newspaper articles to fix it, because ... crrzzz ... crzzz ... the connection is really bad ... can you hear me? ... duut duut duut"? Unlikely. So the only option for them I can think of is to say "It's not a bug! It's a feature! It increases usability!".

Of course this is not a good argument. As Eike Kühl pretty well describes, this functionality only increases usability in a rare corner case: When you dump your phone in the ocean and you need a month to get a new one. Then everyone who has sent you a message during this period will not need to press an additional "OK" button.

I don't know about you, but the door of my apartment has a lock and I need a key to open it. Sometimes the inevitable happens and I forget my key inside my apartment and I only realize this after closing the door. Then I need to call and pay someone to come, check my ID, and open the door. This is very inconvenient. It would be much more convenient if the door stayed unlocked day and night. But am I willing to trade the worse security for the convenience? No! Just like in the case of automatic WhatsApp message re-encryption.

So here is my recommendation to you, Facebook: Say that this was intended as a feature, but acknowledge that you have made the wrong security trade-off. You can keep your face and fix the vulnerability. To restore trust into your messaging platform you should release the source code of the clients. Your business asset is not the source code of the messenger app, it is your massive user-base. The source code of your highly scalable server infrastructure is a true business asset but that part you don't have to disclose. For the client software there are anyways enough open-source solutions available that any competitor could just pick up.

After you have done that, you should consider working towards reproducible builds. This will again boost trust in your platform. And finally, if you could avoid storing all the metadata about us, like Signal claims, that would be even better!

WhatsApp vulnerability: Bug or Backdoor?

In April last year I reported on a vulnerability in WhatsApp. It now gained public attention as it has not been fixed yet. One question now is: Is it a bug or a backdoor? In other words: Is this flaw put deliberately into the WhatsApp messenger to allow them or the government to look at targeted messages? Or is the flaw introduced through a simple programmer error? Or is it even a useful feature?
If someone would demand WhatsApp to implement a backdoor, you might expect them to implement something more obvious. Like responding with the history of all conversations when triggered to so do with a certain secret message. Furthermore, this flaw can be explained as a programming bug. Just a missed "if" statement for one of the corner cases. It is a type of flaw that is not necessarily introduced by malice, just like many other critical vulnerabilities in important products that are reported daily.
But Facebook showed no interest in fixing the flaw since I reported it to them in April 2016. So maybe it was a bug first, but when discovered it got started being used as a backdoor?
WhatsApp has stated recently that this is not a bug, it is a feature! Because now senders don't have to press an extra "OK" button in the rare case they sent a message, the receiver is offline and has a new phone when coming back online. That's not a very good argument! And if "Privacy and Security is in [WhatsApp's] DNA", they should have fixed the flaw immediately after I reported it in April 2016.

My Take on The Internet of Things

Right now we are on the way to create a next generation of the Internet, the Internet of Things. The Internet of Things (IoT) will have a huge impact on many aspects of our lives. It will change the way we interact, the way we live, and the way we think. Remember the years where we had big debates on how the electronic address book in our phones will change our ability to remember things? Well, in the next years not only our phones will become smarter, every_thing will become smarter. Ordinary “things” like our cars, our TVs, our refrigerators, watches, light bulbs, but also industrial assembly-line robots become more and more connected and “smarter”. In an exemplary scenario this means that the bulk of data produces by an ensemble of sensors in our cars can be analyzed in the cloud to find subtle defects or inefficiencies and this information can directly be communicated to the robots in the assembly line to improve the production process. Next to mobility and industry, the health sector, urban living, retail and energy are just a few other sectors where the IoT will have a huge impact.

Trying to predict the future and imagine how the IoT will exactly change things and identify upcoming challenges on this path, I want to first distill the game-changing factors related to IoT. I will then relate those to the Security and Privacy issues arising and present a (not even) half-baked solution.

In IoT there is the I and the T. Let’s look at the T, the things, first. The number of things with general purpose chips and rich connectivity will skyrocket in the next decade. While a traffic light today might only hold a small electronic circuit of a few gates, it will soon be equipped with a whole general purpose microprocessor and in addition to the signal wire which connects it with the other lights at the intersection, it will have a WiFi chip or an Ethernet interface. Putting more hardware into things and giving them more capabilities is simply a ramification of always decreasing cost of this hardware. Continue reading →

Security: Status Quo

On Tuesday, June 21, 2016, the Commission on Enhancing National Cybersecurity #WHCyberComm met in Berkeley to get input from Industry and others. The main goal of the commission is to produce a “transition” memo to the next president to implement important policy changes within the first 100 days of the new administration, which is usually a time window where dramatic moves are made. The industry witnesses highly valued their chance to bring across their views and influence policy decisions to their benefit which made it an interesting event to watch. In this blog post I try to summarize the most important points that were made during the day. Continue reading →

WhatsApp Retransmission Vulnerability

Last week I already tweeted

WhatsApp message not delivered. Contact announces new public key. Auto retransmits messages encrypted under new key. head -> table.

That explains this simple bug in the latest WhatsApp version, which now promises beautiful end-to-end encryption, very good. But for my not so nerdy friends I want to provide some more explanation. I'm not following the usual responsible disclosure procedure here as WhatsApp users are not less secure than when they did not have end-to-end encryption at all. A white-hat report to facebook (#1008534892515816) has been submitted.

Setting: Three phones. Phone A is Alice's phone. Phone B is Bob's phone. Phone C is the attacker's phone. Continue reading →

Secure Communication, Finally!

A beta version of the Signal Desktop client is now available and What's App integrated the Signal protocol into their widely used messenger. TLS certificates are now available for free, many websites provide https, and certificate transparency is on a good way to solve the CA problem. It really seems like the world of computer security has become a bit less broken over the past few years. I'm wondering why it took humanity so long to create a usable secure communication platform that supports multiple devices and group chats, but I'm happy that this problem finally solved. Nobody should have an excuse to communicate insecurely anymore!

So,

  1. How do we get rid of insecure e-mail?
  2. When will What's App hide the meta data?

32c3 - Highlights from the 32nd Chaos Communication Congress

Here is my personal shortlist of talks that I found most interesting. All talks are available online at media.ccc.de!

Fun Talks

Beyond your cable modem

In a short and entertaining talk, Alexander Graf shows how he by accident discovered how to gain complete control over three million routers in the network of the German ISP Kabel Deutschland. With this access he could dial expensive 0900 phone numbers, intercept phone calls and all other traffic through the router, and attack other devices in the local network like IP cameras or other “smart” devices, which often do not require additional authentication. This again shows that many systems are built without any security in mind and this was especially true 10 years ago and many systems do not get security audits as long as they work.

The exhaust emissions scandal („Dieselgate“)

In this exciting talk, Daniel Lange and Felix "tmbinc" Domke give more background information on the exhaust emissions "scandal", based on their knowledge. Daniel gives insights on what is driving the Car Industry today and Felix Domke explains his findings when reverse-engineering the ECU, the “brain” of the car engine.

Politics

Continue reading →

Security and Privacy of University Grades - Part 2: Security [Updated]

After I have talked about Privacy of University Grades, I now want to talk a bit about the security of university grades and present a vulnerability in a frequently used software.

Security of University Grades

Many of my Professors in the Mathematical Institute and also many Professors in other Universities use OKUSON to publish, manage, and grade homework assignment. OKUSON is an open source software written in python which provides a complete web server and was made at RWTH Aachen. Back in mid 2013 I screened the source code and was not amused in the first place because the coding style was what I would consider *not so good* (the software mainly consists of one file containing ~4000 lines of code with rare comments). However, my amusement raised after a while when I found the first vulnerability.

Have a quick look at the relevant code: Continue reading →