33C3 preroll music Herald: Next talk is gonna be “Shut up and take my money” by Vincent Haupert. Vincent is a research associate at the security research group of the Department of Computer Science at Friedrich-Alexander-Universität in Erlangen, Nürnberg, Germany. Typical, very long German word. His main research interests are authentication, system security and software protection of mobile devices. It’s actually Vincent’s second time speaking at the Congress. Last year’s talk discussed conceptual insecurity of app-generated passwords in online banking. This year he will discuss the practical aspects and some successful hacks that, if I recall correctly, took over entire bank accounts from users’ mobile apps. With that, Vincent, over to you. applause Vincent Haupert: Hello again, thanks for the warm welcome, and let’s dive right into it because we have a tough program. Okay. First of all, online banking is something that affects us all, because virtually everybody uses it. In traditional online banking, we use two devices. One to initiate our payments – and to log in with user name and password – and another device to confirm transactions. With the rise of mobile devices, app-based confirmation procedures became popular like this app there. In the recent past, what I have been talking about last year, it became popular to implement those two devices in two apps. That means you only have one single device and have two apps now to authenticate transactions. Last year I showed that this has severe conceptional drawbacks. But this is not the end of it. The latest evolution in online banking are now one-app authentication models. I already said this last year: Actually, it doesn’t make so much difference. So banks are no longer faking to have real two-factor authentication. It’s now clear that it’s just one, so you do the transaction initialization inside the app and the confirmation is just another dialog inside the app. This time I want to talk about N26, the shining star on the German FinTech sky. Actually, this time I’m only going to be talking about technical issues. It’s clear that we have similar conceptual problems like with two-app authentication, but I will focus on technical issues because we have enough of this there. Briefly about N26: N26 is a Berlin-based, “Mobile First” FinTech and it plans to establish your smartphone as your financial hub for everything, so that you do literally everything from inside the app. Actually it was only founded in 2013, it started in 2015 with their app and it already has over 200.000 customers, which is astonishing, actually. It now also has its own European banking license. It’s only, I think, half a year ago; and it announced not even one month ago that it’s now available in 17 European countries. And they also claim that you can open a bank account in just eight minutes. As it turns out you can lose it even faster. laughter Okay, let’s talk briefly about transaction security in the Number 26 app. If you want to do a transaction, you at first need to log in. This works with your user name, in this case it’s just your email address, and your password. This is pretty standard. Afterwards you are good to initiate a transaction. After you have entered all the details you also have to supply a transfer code. This is just a four-digit number, you use this also to withdraw cash. Probably you would call this ‘PIN’. The last factor in this authentication scheme is you paired phone. This is actually the most important security feature of the N26 account, and you can only pair one smartphone with you N26 account. That means, from a technical perspective, the N26 app, the very first time you start it, generates a RSA key pair and sends the public key to the N26 backend. And whenever you initiate a transaction they are going to send an encrypted challenge to your smartphone and you send it back decrypted. That’s how it works. Actually, re-pairing, that means pairing another phone is a pretty well secured process, but we will talk about this later. Just to talk about the infrastructure of N26: basically they have two apps, one for iOS, one for Android, and they communicate over a JSON-based protocol, TLS encrypted. The backend is at api.tech26.de. How do I know, actually, that this is a JSON-based protocol: because I used a TLS man-in-the-middle attack to log the protocol. I only needed to install a certificate, the MITM proxy certificate on the client, but actually I was surprised that I didn’t need to touch the client, because they didn’t implement any certificate pinning. applause So that means, the first thing that comes into mind is like: Let’s do real-time transaction manipulation. That means we manipulate a transaction that the user does, but we will change the recipient and the user won’t see nothing about this. So if we look at this graphic again, what if an attacker could get the DNS record of api.tech26.de under his control? This would mean that all traffic is routed over the man-in-the-middle attacker server and, as there is no certificate pinning, we could just issue a Letsencrypt TLS certificate and the app is going to trust the certificate. How does this work? Let’s take an example here. Let’s image I want to transfer 2 Euro to my friend Dominik. After I entered all the transaction details I have to enter my transfer code, too. When I did this I get like the second factor where you need the paired device and I need to confirm it. This is just like the next dialogue inside the app. After I confirmed it, the transaction went through, everything looks good. 2 Euro less on my account, pretty good. In the next step you can see in your transaction overview too, that there are 2 Euro less. But after the attack when N26 realized that something wrong was going on and they fixed it you will realize that we actually transferred 20 Euro, not 2. But this was completely transparent for the user even after the attack. Okay, this is nice. We can manipulate a transaction in real time, but wouldn’t it be even more interesting to take over entire accounts to do our own transactions? For this, we need the login credentials, the transfer code and the paired phone. So we need to obtain all of them. Let’s start with the login credentials. Actually, I want to assume, that the login credentials are already compromised. But there are some weak points in the security system of the N26 transactions, that make it an easier task to obtain those login credentials. There are two things I want to talk about. The first thing is the recovery-from-loss procedure. When you forget your password, N26 just sends an email to your email account. There is a link inside, you click it and you can just reset your password. This breaks the N26 password policy which is actually pretty solid, because if you have access to the email account, you have automatically access to the N26 account, too and the access to the email account could be as bad as “password” or “123456”. Another idea is spear phishing. Think of spear phishing like a more targeted version of phishing. What you always need for phishing is a similar domain, something the user can relate to. And if you want to make spear phishing you want to have it more targeted. That means you want to expose N26 customers, so only send out mails to them. And you need to have a valid reason to contact them. About the domain: usually N26 uses number26.de; and for password resets e.g. number26.tech. Sounds pretty valid in my eyes. Only by chance I happen to own that domain. laughter The next thing is exposing N26 customers. N26 offers peer to peer transactions, that means if your recipient also has a N26 account, those transactions are instant. To show the N26 customers who of his contacts actually have an N26 account, they upload all of the email addresses, all of the phone numbers in your address book to the N26 backend. Unhashed. applause But we actually want to use this to identify customers of a given dataset. We can actually abuse this API for that. Do you remember the recent Dropbox leak that revealed 68 million accounts? We evaluated all of those 68 million email accounts against this API and N26 took no notice of this. There were no limits applied. They just think, I’m really popular. laughter applause In the end, we revealed 33.000 N26 customers and could now send out e-mails to them. Actually, this also provides a valid reason to contact them. E.g. the usual e-mail of N26 looks somehow like this. So we could say to them: “Hey, you are affected by the Dropbox leak, please change your password for your own security. Click this link to change your password.” Now I can already see the N26 management board nervous, but don’t worry, we didn’t do this. My professor had legal concerns. laughter Now, that we have the login credentials, we have to wonder: Can we already do something with those login credentials? And this brings me to Siri transactions. With iOS 10 N26 now supports transactions using Siri. That means now you can just say: “Send 5 Euro to Dominik Maier using N26”, then the transaction pops up and you can say: “Send it” and afterwards it’s gone. The app doesn’t even open. So this already sounds wrong, laughter …but you can only do this with the paired device. If you use another phone and just log in and try to use Siri with this, this dialogue appears and you really have to open the app and have to confirm it with the paired phone. As it turns out, this is just a client feature. laughter This is actually the entire payload you need. It’s just like “5 Euro to Dominik Maier”, and there is the phone number. And look at this API endpoint, ‘/transactions/unverified’. So it turns out you don’t need the paired phone to do this type of transactions. applause Yet another thing that’s interesting is that N26 claims that they have some intelligent algorithms to immediately detect irregularities and prevent fraud before it even occurs. So we thought: “Challenge accepted!” laughter and applause And what we actually did, and I think this is pretty irregular, we sent 2000 Siri transactions worth 1 Cent within 30 minutes. laughter Try to speak that fast. Ok. And so what happened? Like we waited the next day and the day after nobody actually made contact with us, and we thought they would never actually make contact. But over three weeks later N26 required Dominik to explain the “unusual amount” of transactions. Okay, they even threatened to cancel his account. I mean, this is actually… it’s reasonable because it’s a clear misuse of the account and it violates the Terms of Service of them. But Dominik didn’t send those transactions, he received them! laughter They contacted the wrong person! This is kind of like if Gmail cancels your account because you received Spam! loud laughter applause Okay, let’s go back to the account hijacking. And the next thing we need to obtain is the transfer code and get the control over the paired phone. What we will do: with the transfer code we will try to reset it; and the paired phone we have to un-pair. Actually, those processes are not as independent as it seems. So I will right start with the paired phone. As I told in the beginning, un-pairing is actually a highly-secured process and I mean, this is my serious opinion. So let’s look at the process. At first, when you want to pair a new phone, like I said, you need to un-pair the existing one. Therefor, you open the app, then you click at “Un-pair” and afterwards they send a link to your email account. Then, in the e-mail you need to follow the un-pairing link. In the next step the real un-pairing process starts, where you have to enter your transfer code first, then your MasterCard ID. This is something that is kind of special for N26, like, every N26 account comes with a MasterCard, and they have printed a 10-digit numerical token below your name. I don’t know what this actually is, it’s not the PAN, it’s not the credit card number but some other sort of token. So you need to have the Mastercard, actually. And in the last step they’re going to send an SMS to you with a token, and you have to enter it. And only after this process the un-pairing is done. So that means we need to have access to the e-mail account. We need to know the transfer code. We need to have the Mastercard and we need to own the SIM card in order to receive the token. You can’t screw up each of those. laughter and applause Okay. Let’s go into it. So, the first thing: when you actually click on that item in your app where it says “Start un-pairing” it sends – this is basically HTTP GET request but you wouldn’t believe that they send the link as a response. So – it’s not this plate (?) but it’s there. So you don’t need to have access to the e-mail account because it’s in the response. laughs laughter Okay. Next thing. The transfer code – I actually will skip this for the moment and we’ll get right back to this. But the next thing is actually the Mastercard ID. And this ID is printed on the card, and we don’t have access to that card. So what will we do? In the transaction overview N26 shows a lot of properties, e.g. the amount, the beneficiary, whatever. And it turns out that this… laughter and turmoil that they used this Mastercard ID, they thought: “Oh, this is actually a nice ID, let’s use it as a prefix”. So, again, this is not displayed to the user inside the app but it’s clearly there in the API. It’s way too verbose. So… applause Okay. Whenever… the step that I just skipped was this transfer code. The transfer code is unknown. But you can reset the transfer code. And it is – as it turns out – what you need to reset the transfer code is the Mastercard ID. laughs laughter and applause So you need to enter this Mastercard ID that I just told how we will get it and then we just will confirm our new transfer code. Think of one, I don’t know. Any code. And therefor we don’t need to know the transfer code. Not even the old one because it’s not required. The Mastercard ID is sufficient. Then. The last step. SMS. The SIM card is inaccessible. We don’t have access to that phone. But this is a 5-digit token that they send out and it’s only numbers. I mean this is 100.000 possibilities. And even though the login procedure, the login form, has a brute-force protection this doesn’t have any brute force protection. So… laughter …the maximum that I could get out of the backend was 160 requests per second! laughter So this means… laughs applause So that means that it takes on average approx. 5 minutes to get this token. In the end we will just brute-force it and that’s it. Okay. That’s… laughter Let’s look if this really works. At first we will login to the app just to see that it’s paired. And if it wouldn’t be paired we would know, like, see a dialogue that we should pair our phone. So now it opens. Great. And now we will start our script. And N26 claimed that this attack doesn’t scale, just don’t blink! exhales sharply So those are the login credentials laughter …that will do all the fun. And actually, everything already happened, it’s just the brute-forcing that now takes place. And I have to admit that I have been really lucky this time because we are done now. laughter So this is the response, now the SMS numeric token is valid, and the phone has been successfully un-paired. Okay, now let’s verify in the app… if this worked really? So let’s open it again. Touch-ID expired, so this is actually good. That means that something happened. Let’s login with our password. And there it prompts us for pairing the phone. So it worked. applause Yeah… laughter This… even though I said that this attack really scales very well it has a drawback. Because three mails are sent out to the user. The first one when you actually start the un-pairing, the second one when you reset the transfer PIN and the third one when the un-pairing is successful. And the user also receives an SMS. But I mean fraud is perfectly possible. But is there a possibility to avoid this? Let’s try to call the customer support. The customer support is actually the most powerful entity in the N26 security model. Because they can even change things you can’t change inside the app. E.g. your email address, or name – you cannot change. But they can. So let’s talk with them. They can… it turns out they can also un-pair phones. So now the question arises of course you cannot just call there and say: “Hey, my name is Vincent, please un-pair my phone.” Of course they are going to authenticate you. And what… loud laughter …and what will they ask? They will ask for the Mastercard ID. We know that. The current account balance is always available if you have the login credentials. Okay. There’s one thing that is still missing. Place of birth. It’s always the same. laughter It’s, again, you can’t see this information inside the app. It’s just not displayed. But it’s there. There’s so much information you can’t think of. Really, they know more about me than I do. laughter Now that means we have all information available, and we can change any data. And the user won’t receive any notice of that. So no email, nothing. So we can just un-pair the phone, and later we can pair our own one, or… this is perfectly stealth. Now actually I heard already: “Ah, I only got 50 Euro on my account, why should I care?” This is actually a valid argument because many N26 accounts are opened out of curiosity, and many are inactive, or not used seriously, that means you only use it for travelling or paying things online because of the conditions. But you don’t use it as the salary account so there is frequently not so much money in it. But as this wants to be the financial hub for all the services you of course can also apply for an overdraft. And this is an instant overdraft that is granted during two minutes. And it’s between… you have guaranteed 50 Euro and up to 2000. This requires the paired device. What did we just do? We have the paired device. We have the entire account. So what do we do? We will just hijack the account then we apply for an overdraft, and then we will take all the money he has as a balance and as an overdraft. So even if you don’t have money on your account and think you’re safe you are not. laughs Okay. This was quite a bit, something. I want to talk briefly about disclosure before I will draw my conclusion. I reported all these issues to N26 on September 25. I didn’t establish the contact, this was the CCC. Thank you for that. I did this because I didn’t know how N26 would react to this kind of vulnerabilities. But, actually, there was no reason to think so. Because they acted really professional. And they were actually thankful that I revealed these vulnerabilities. applause Then, afterwards, they started to incrementally fix the issues. I don’t know when they fixed the first thing. I didn’t monitor the process. But the last fix I know of happened on December 13 when they implemented certificate pinning on iOS. And, apparently, I have to say that I didn’t check everything. But apparently all issues are resolved. But what are the consequences out of this? It is obvious that N26 needs to put more emphasis on security. It’s important to notice that this wasn’t a coincidence. It simply wasn’t! And N26 needs to understand that it’s not enough to release videos with caption “mobile first meets safety first” and to claim that security is of paramount importance of them. So PR shouldn’t do your security. It’s funny: If you visit the N26 home page you will find out that they currently have 44 open positions. Not even one is dedicated to security. Furthermore, with such a strategy FinTechs squander the trust in financial institutions that banks established over years, actually. Today you usually trust in your bank that they will deal with your money responsibly. And in the end you also need to question authorities. I mean it was BaFin that granted a banking license to N26 only six months ago. And, really, those vulnerabilities are in sight for longer time. Okay. I think, like… résumé for this is: you shouldn’t say “Works for me” when it’s about security. So, thank you! applause Herald: Thank you Vincent. That was awesome. And also kind of fucking scary. We only have a short time for questions. Is there anybody who has a question for Vincent? No, I guess everybody is out deleting banking apps. laughter Oh, number 6! Question: Quick question. Do you know whether they have disallowed those apps that have not yet been updated to still manage their bank account? So e.g. if someone has a mobile app that has not yet been updated to the version that includes certificate pinning would that person still be vulnerable to man-in-the-middle attacks? Vincent: Yes. laughter laughs Actually they don’t have so much of an idea which device you are using. They don’t even know which is the paired device! This is only a client value. Herald: Do two more, it’s a guy here on number 1. Question: Thanks for the talk. Did they actually invite you to help them or give your talk at N26? Have they been in contact with you? Vincent: Yes, we have been in contact and I also visited them and gave a workshop, so yeah, they… laughter and applause Question: Are you serious? Vincent: I am serious, yes! ongoing applause Herald: And we do one last, one here, from number 5, please. Question: So during your talk you name-dropped Letsencrypt, and you kind of glossed over that bit, about getting them to issue a certificate for their API host name. Do you know something I don’t? Vincent: Ehm, the question, again? I don’t… Question: So you mentioned getting a Letsencrypt certificate to impersonate their API host name, because they weren’t using certificate pinning. How did you go by doing that? Vincent: But I didn’t do. This, like, was a scenario. That’s an attack scenario. I didn’t hijack the DNS record, okay, sorry. laughs Question: Thank you. Herald: Alright. Thanks everybody for joining. And get a big round of applause here for Vincent! applause postroll music Subtitles created by c3subtitles.de in the year 2017. Join and help us!