Shut Up and Take My Money! (33c3)

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!