Def Con 21 - Justin engler and paul vines - Electromechanical pin cracking

>> JUSTIN ENGLER: My name is Justin Engler, I'm a senior security engineer at iSEC partners. This is Paul Vines. He's a security engineering intern for us. We both work for iSEC partners and we are here to talk about automated PIN tracking. 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 are going to go over what your approach would be if you neat to brute force something like this. We will talk about the robots we built to do it and then we'll 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 the device. You have a jaildevice and you hack the app to remove the protection. This is your best plan. It's usually quicker and usually a more direct route to do what you want to do. If for some reason you can't do the software approach, the next best approach is the hardware attack. Our example here is keyboard emulation. Darren Kitchen at Hat 5, he plugs into USB Rubber ducky and does something similar. Other hardware attacks are a good second choice. 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 are 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 ‑‑ (Laughter)  ‑‑ do the button pushing for you. (Applause) 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 his intern to push buttons all the time, he won't get his coffee and I don't want to get fired for that. A much better plan is to hire an intern and help him build the robot, to push the buttons and then he still has time for coffee later. So in order to build a robot to crack a PIN, you have a few things you need to do. You have to actuate the interface. You need to make the device make this think that the button was pushed. You have to keep track of where you are on the list of all the PINs and you need to usually figure out whether you were successful or not. There's some cases where you just need the device open and you don't care what the PIN was. In that case, you could do something even simpler than what we're doing, have them run through it all and keep going after that. By the time you have come back, after you went away for the weekend or whatever, then the device should still be unlocked because someone has been sitting the screen the whole time but you don't know what the actual PIN is. We are doing a little better than that. So this thing is a delta robot. That's at general class of robot that this is. Delta robots were originally for industrial work in the '80s. They are still used for that stuff today. There's a few rotational motors that through some math that we'll talk about 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 lifting power, but we don't care about those things. It seems like a good choice for us. 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 UK and so maths are plural. That's why there's a bunch of them. The good news for us is that we like open source and open projects and not only do you 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 kinematics. He also had 3D printed schematics and everything. He open sourced most of it. So ‑‑ and he actually sells it as a kit this one you are 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. ' essentially what we have is an Arduino, we have the physical parts of the robot and we have a computer and the computer is talking over serial to the Arduino and the robot knows how to move around. So the original kit was missing a few things. It was kind of an empty head. We added a stylus to the tip and just adding a stylus makes it not work. You have to ground it because the capacity of touch screen thinks what it is, is a change in capacitance. We added a camera. So that helps us for configuration. We won't have time to show it to you now. We can show it to you later. It is set up to recognize when the screen has changed because that means we successfully unlocked it. We are around moving at five presses per second but you notice there's a delay after each of the five. Most of the numbers I will talk about assume that you can do one full P.I.N. 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 of that stuff is done. We need to make some Python that makes it all work. We have a serial control, and Python makes that easy. We used open CV to analyze the stuff on the camera, and we have an easy interface for calibrating where all the buttons are. We originally tried to calibrate the buttons, it's too hard. Don't believe computer vision people when they say they can 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 are done. So, we talked a minute ago about how you have to ground the stylus to make it detect the touch. So at some point when I was working on this, I realized, well, why don't we just ‑‑ you missed a pin. 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 fire off the Python, which fires the relays and it all works, except it doesn't work. (Laughter). 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. >> AUDIENCE MEMBER: Try an isolater. >> JUSTIN ENGLER: There are all types of things we can try. 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 P.I.N. So what's the PIN? (Applause) We're looking for it. >> PAUL VINES: Was it 7777? >> JUSTIN ENGLER: 7777? 9977. >> PAUL VINES: Okay it was right before that. >> JUSTIN ENGLER: We have it multi‑threaded. It's starting the next run before it's analyzed the picture. So we can narrow it down but sometimes we are off by one. We actually saved the list of all the times 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. So as I was kind of alluding to when I was talking to Sebastian, we don't go in kind of stupid order from 0000 to 9999. There was a guy named Nick Berry that did an analysis based on leaked password files to try to figure out which PIN would be the most common. And he had some really cool, like, data visualizations but he wouldn't release his raw data but what he did wasn't complicated and we did the same thing. So we have the password list for that. It's included in the stuff we are going to submit you to guys, so you can do this too. There's also a guy named Daniel Amate. 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 ‑‑ (Laughter). Aggregate statistics about those. So we asked him for his data and he graciously provided it. It turns out 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 lists, because it's just straight down the screen, also corners. Anything else that makes a pattern or uses the letters. 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 any special secrets or anything. And we combined it with Daniel's list and the list that you will 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 have guessed. On the top, you have the percentage of phones that you have unlocked by the time you 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 have unlocked it, it's about 3700, which is still much less than the 8,000 you would expect at 80%. Obviously R2B2 is also able to, because we are 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 an old tape calculator and had it push buttons, but 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 pad locks that have buttons and tings like that. If you noticed all the doors around here seem to have codes on them. >> AUDIENCE MEMBER: Break one of those! >> JUSTIN ENGLER: Sounds like everyone knows what it is already. So now that you know how to brute force something. How do we go the other way and defeat brute forcing. One thing you could do is have a delay after bad guesses. On Android, if all you have done is set a PIN and you haven't set any other settings, all you have 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 that 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. In 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 a 20% success rate. So that's not 20% of the PINs because that would be a lot more. That's 20% success rate. Another important thing to note about Android, there are many other settings you can set that would change this behavior. If you have a Google account set, and you have two factor authentication enabled on that, then after something like 20 guesses, you will be prompted for your Google user name and password instead of why you ever P.I.N. So that's good. If you are using your device for corporate email, 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 exec. We have people who have people who have a PIN on their lock screen and we find that there's no brute force protection at all. And when we have an engagement and I tell them that there's no brute force protection, they say did you break it? No, I didn't have time and now we have the robot and 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 we have been tweaking code today. We only had a chance to test out a few items from the app store. Things like financial apps have it. Some antivirus apps, and like store your secret pictures and notes have it. Out of 13 that we had time to try, four of them had something that was effective enough that we couldn't break it and 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 for 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 will take 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 are up to 20,000 centuries, my robot will be broken by then, I promise. So the last slide, this is my device ‑‑ advice to developers of OSs or apps or whatever. You need to put some type 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 robot, we will finally get some traction on getting those things changed. ISEC and NCC thank you very much for giving us some money to build this robot. And Dan Royer, for doing the original define, and Daniel Amate for giving us some info and David Nichols who helped us with 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 of 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. Yeah. That's it. Thanks, guys. (Applause). We have time for questions maybe, a couple. Yes, go. >> AUDIENCE MEMBER: (Inaudible question). >> JUSTIN ENGLER: 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'm from close to Seattle. Yes. >> AUDIENCE MEMBER: (Inaudible question) >> JUSTIN ENGLER: How much is the robot. If you have a 3D printer and you print the stuff itself, it's less than $50 for everything else. If you need to buy the 3D printed parts, you will be probably just under $200, maybe $150. So not bad. Yes? >> AUDIENCE MEMBER: Is there any ‑‑ if you don't want the ‑‑ (Inaudible) ‑‑ that brute force password attacks has a longer pass code? >> JUSTIN ENGLER: So the question was is there an effective defense besides a device wipe. If you are the user and you don't have any choice, then a longer PIN or a stronger PIN is the best way to go. If you are a developer, you can do something like IOS does with the cascading wait where it takes longer and longer and then you can maybe not force the reset of everything. Make sense? All right. So we have a little bit of time, we will move over in the hallway so you can look it at closer. Okay. All other questions out here.