My name is Justin Engler. I'm a senior security engineer at ISEC Partners. This is Paul Vines.
He is a security engineering intern for us for the summer. We both work for ISEC Partners
and we are here to talk about automated pin cracking. We will talk about R2B2, which you
can see here moving on the stage. You won't see C3BO and we will talk about why.
So quickly we're going to go over what your approach would be if you need to brute force
something like this. We're going to talk about the robots we built to do it in specific
and then we're going to talk about countermeasures and how the robots stack up against countermeasures.
So everyone here know what a pin is? Anyone never heard of a pin? Okay. Good. So if you
need to get into something that has pin protection, so bypass whatever the pin is blocking you
from doing, you have a few options. One, you could do a software approach where maybe you
jailbreak someone. You could do a software approach where maybe you jailbreak someone.
Maybe you jailbreak the device. Maybe you have a jailbroken device and you hack the
app so that it removes the protection. This would be your best plan. It's usually quicker.
It's usually a more direct route to do what you want to do. If for some reason you can't
do the software approach, your next best option would be a hardware attack. Our example
here is keyboard emulation. Darren Kitchen at Hat5 has a neat video where he plugs in
a USB rubber ducky into an Android device and does something similar to what we're doing
here. So that would be great. Other hardware attacks are also a good second choice. So
maybe you can pull the RAM and read it or things like that.
The last thing you should try to do if you have no other options is to brute force the
UI itself, which is what we're doing. I'm a security consultant, so I often work on
engagements that have a set time period. And I don't have time to sit and brute force out
a pin. It would take too long when I'm supposed to be doing other things.
So the next option is to get an intern to do the button pushing for you.
So you could have an intern just sit and push the buttons. But sometimes interns do
things wrong and we don't really have any way to guarantee that the intern gets it right.
My boss, Andrew, really loves his coffee and if I take the intern to push buttons all the
time, he won't be able to get any coffee. And I don't want to get fired for that.
So a much better plan is to hire an intern and have him help you build the robot that
will push the buttons and then he'll still have time for coffee later.
So in order to build a robot to crack a pin, you have a few things you need to be able
to do. Somehow you need to be able to actuate the interface. So you're going to need to
make the device think that the button was pushed. You're going to have to keep track
of where you are on the list of all the pins and you need to usually figure out whether
you are successful or not. There are some cases where you just need the
device open and you don't care what the pin was. So in that case, you could do something
even simpler than what we're doing, just have it run through them all and keep going after
that. By the time you come back after you went away for the weekend or whatever, then
the device should still be unlocked because somebody has still been hitting the screen
the whole time and you're in. But you don't know what the actual pin was. We are doing
a little better than that. So this thing is a Delta robot. That's the
general class of robot that this is. Delta robots were originally foreign robots. They
were used for industrial work in the 80s. They're still used for that stuff today. There's a
few rotational motors that through some math that we'll talk about later can turn rotational
movement into X, Y and Z movement. It's also very fast, but it doesn't have a lot of torque
or a lot of lifting power, but we don't care about those things. So this seemed like a
good choice for us. And I said it's fairly simple to do the math, but there are a lot
of maths involved.
ISEC is owned by NCC group, which is a company in the U.K., so maths are plural, so that's
why there's a bunch of them. But the good news for us is that we like open source and
open projects, and so not only do you guys not need to do the math, but we actually didn't
need to do the math either. We found a guy named Dan Royer had done a lot of this work
for us in setting up a Delta robot that did most of what we wanted to do. He already had
source code that would do the inverse code. He was able to do the inverse code, but he
used kinematics, which is the fancy roboticist term for turn what the robot motors do into
the X, Y and Z motion. He also had 3D printed schematics and everything. He open sourced
most of it. And he actually sells it as a kit. This one you're seeing here is built
out of mostly his kit parts. The one that Paul built, which is in the hotel room right
now, is actually completely built by us. We didn't want to be held hostage to them not
selling it anymore. So we did build it from scratch from all other parts and it all works
fine. So essentially what we've got is an Arduino. We've got the physical parts of
the robot and we've got a computer. And the computer is talking over serial to the Arduino.
The Arduino knows how to move the robot around. So the original kit was missing a few things.
It was just kind of an empty head. He didn't know what it was going to be used for. So
we added a stylus to the tip. And just adding a stylus
makes it not work. You have to ground the stylus because the capacitive touch screen
thinks that that's what it touches is a change in capacitance. So we added that. We added
a camera. So that helps us for configuration. We won't have time to show you guys that
now, but we can show it to you later. It also is set up to recognize when the screen
changes because that means that we successfully unlocked it.
We are around moving at five presses per second. But you'll notice there's a delay after each
of the five.
Most of the numbers I'm going to talk about assume that you can do one full pin, so that's
four or five presses in a second. There's some camera code that we can maybe modify
to get rid of that delay in the middle. So all that stuff is done. We need to make some
Python that makes it all work. So we have a serial port, control in Python. Python
makes that really easy. We used OpenCV to analyze the stuff on the camera. And we have
an easy interface for calibrating. We're all going to have to do a little bit of calibrating.
All the buttons are ‑‑ we originally tried to detect the buttons. It was too hard.
Don't believe computer vision people when they tell you that they can just recognize
anything anywhere. It's not true. And lastly, it can detect ‑‑ you tell
it where on the screen you want to say if this part changes, then we definitely unlocked.
And then we watch for that to change and when it happens, then we know that we were done.
So we talked a minute ago about how you need to ground the stylus to make ‑‑ to make
it actually detect a touch. So at some point when I was working on this, I realized, well,
why don't we just ‑‑ why don't we just hook up a bunch of wires to the screen on
the buttons and then ground them selectively and then we don't need any moving parts. So
you use a microcontroller connected to relays to trigger those in place that will then cause
the touches to appear on the screen. And you don't need any moving parts. You don't need
this complicated calibration. All you need to do is ‑‑
off the Python which fires the relays and it all works. Except it doesn't work.
So the problem in my particular case, the relays that I selected have enough capacitance
by themselves that once you hook it up, even if the relay is open, the screen sees it as
a touch. I don't know anything about electronics. Does anyone here have an idea of what's wrong
and how to fix it? Raise your hands. Yes, there's all kinds of things we can try
and I don't know what any of them are. But if you let me know what they are, we'll try
them. If we can get it fixed at DEF CON, I will give someone a full R2B2 if we have
C3BO working by the end of the time. So talking generally about brute forcing stuff.
We don't want to just naively go through and start with 0000 and then go 0001. We got
it. We cracked the pin. So what's the pin?
We're looking for it.
7777?
That was right before we pressed 7777. So what happens is we've got it actually
multi‑threaded so it's starting the next run before it's analyzed the picture to see
if it's changed or not. So we can narrow it down, but sometimes we're off by one.
We actually saved the list of all the times that we think we got it. So if we did get
it wrong, then you can go back and try the next, you know, few up. So we almost got it.
All right. So as I was kind of alluding to when I was talking to Sebastian, we don't
go in kind of stupid order from 000 to 9999. There was a guy named Nick Berry that did
a analysis based on leaked password files to try to figure out which pins would be the
most common. And he had some really cool, like, data visualizations, but he wouldn't
release his actual raw data. But what he did wasn't complicated, so we did the same thing.
And in addition, we pulled in more password files than he originally did to make sure
we had more data. So we have the password list for that. It's included in the stuff
we're going to submit to you guys so you can do this, too.
There was also a guy named Daniel Ametay. His was a little different. He wrote an app
for the IOS.
That goes through and, like, lets someone add an extra lock screen to their phone. And
then he collected the pins that people were using for that and did aggregate statistics
about those. So we asked him for his data and he graciously provided it. It turns out
that it's a little different than the data that's just from password lists because those
are from people that are usually sitting at a computer. And so those guys don't do things
as much where the position of the buttons matters.
So 2580 is much more common in Dan's list than in the other list because it's just straight
down the screen. Also corners, you know, anything else that makes a pattern or uses the letter.
So another one that's popular is the one that spells out love. So it's interesting to look
at those things. So the two data sets, the one that we synthesized and when I say we,
I mean Paul. And it took him, like, a half an hour to write the code. So I don't think
we're really giving away that much data. So we're going to show you a picture of the data.
I don't want to give away any special secrets or anything. And we combined it with Daniel's
list and the list that you'll have is the synthesis of the two.
So this is what you need to know about pin frequency. So on the bottom we have the number
of pins that you've guessed. On the top you have the percentage of phones that you've
unlocked by the time you've guessed that many. So if you want to be more likely than not
you have solved the problem and unlocked the phone, 670 pins is all you need out of
10,000. Assuming that the person that you are trying to crack is not some weird DEF CON
person and actually follows the statistics. If you want an 80% chance that you've unlocked
it, it's about 3,700, which is still much less than the 8,000 you would expect at 80%.
Obviously R2B2 is also able to, because we're just a robot, we can push physical buttons
as well as touch screen buttons. I don't have a demo for you because I couldn't find a good
one. I almost brought it to you. But I'm going to show you how to do that. I'm going to
use an old tape calculator and push buttons. I couldn't fit it in my bag. We also think
we might be able to do things that are completely mechanical, like there's some padlocks that
have buttons and things like that. If you've noticed, all the doors around here seem to
have codes on them. Sounds like everybody knows what it is already. So now that you know how
to do this thing, how do we go the other direction and defeat brute force? So one thing you could
do is have a delay after bad guesses. On Android, if all you've done is set a pin and you haven't
set any other settings, all you've done is set a pin, then it makes you ‑‑ every five
bad guesses you do, you have to wait for 30 seconds. That 30 seconds is constant, so the next
five you do, you have to wait another 30 seconds. That means if you want to go through all 10,000,
it's going to take you about 20 hours, which is not that bad for something that's important.
And like we just talked about with the other ones, if you wanted to be more likely than
not done, it's only going to take you 80 minutes. If you want 80% likely to be done, that's
only seven hours. IOS's lock screen handles things a little bit differently. So on IOS,
you get your first five for free. And after that it starts to scale up how long you have
to wait between each guess. And it goes up crazy fast. If you take that 20 hours that
we had for Android and you do the same thing here and you wait the required waits, you
only have like a 20% success rate. So that's not 20% of the pins because that would be
a lot more. It's 20% success rate. Another thing that's important to note here about
Android is that there are many other settings you can set that will change this behavior.
If you have a Google account set and you have two factor authentication enabled, you can
hold on that. Then after something like 20 guesses, you'll be prompted for your Google
username and password instead of your pin. So that's good. If you're using your device
for corporate e‑mail, hopefully your Exchange people have set up the wipe after ten tries
setting. So it's not like all hope is lost on Android. There's still a lot you can do.
It's just the default is not as good as it could be. I'm mostly an app sec. So what I
was more interested in is applications. We get a lot of clients that have a pin on their
application separate from the lock screen. And it's that kind of situation where we most
often find there's no brute force protection at all. And when we have an engagement and
I tell them there's no brute force protection, they say, well, did you break it? No, I didn't
have time. And now we have the robot, so now we don't have that problem. We very briefly,
because the robot was only stable ‑‑ stably working as of a day or two ago and even then
still been tweaking code today, we only had time to test out a few apps from the app store.
Things that are likely to have this are things like a ‑‑ financial apps have it. Some
anti‑virus apps have it. Some things that are like store your secret pictures and notes
have it. So out of 13 that we had time to try, four of them had something that was effective
enough that we couldn't break it. The other nine had nothing that would really stop us.
This is an interesting table.
So this tells you if you can do one pin per second and there's no other brute force protections,
how long it would take you to break something for various types of pins or passwords. And
the other side shows you what it would be like on the Android style where it makes you
wait 30 seconds every five bad guesses. So as you can see, it's not that hard. If you
do a four‑character password that includes all the printable ASCII characters, it's going
to take me two and a half years even if there's no brute force protection. And that's decent.
If you can go up to seven, we're up to 20,000 centuries. My robot would be broken by then,
I promise. So the last slide, this is my device ‑‑ or advice to developers of OSs or apps or
whatever. You need to put some kind of brute force protection in place. This is my advice
for users when you have to use an app that doesn't have any brute force protection in place. You need to pick a longer ‑‑
pin or one with better characters. This is not rocket science, and this is something
that the security community has known about forever. But at the same time, we still see
apps with no protection. So I guess we have to talk about it some more. And maybe with
this robot, we will finally get some traction on getting those things changed.
ISAC and NCC, thank you very much for giving us some money to build this robot. Dan Royer,
who did the original design that we modified.
Dan, happy Because he thought he might need it.
Daniel Amite for giving us some data and David Nichols who helped us with some app analysis.
This is our contact information. That's my Twitter handle. Your CDs already have the
kind of preliminary code that was working as of when they were due a couple months ago.
It will run and it will move the robot. There's no camera code in there yet. The ‑‑ I
will Tweet at this when we have the rest of it posted which will be sometime next week.
And I think we can probably get it on the ISEC web page. That's it. Thanks, guys.
We have time for questions maybe? A couple? Yes, go.
How many did we successfully break? How many guesses did it take? We're looking.
We'll look. Next question? Paul is from Seattle. I am from close to Seattle. Yes.
How much is the robot? Excellent question. If you have a 3D printer and you print the
stuff yourself, it's less than 50 bucks for everything else. If you need to buy the 3D
printed parts, depending on what the pricing is from where you get it, which seems to vary
a lot, you're going to be probably just under 200 bucks, maybe 150. So not bad.