 Okay, so owning the enterprise with the BlackBerry. I am Xi'an, some of you here know me as Xi'an, I'm also known as Jesse de Guano, I'm a founder and director of professional services and research with Pretorian Global, a consulting company in Northern California and also a core member and current team captain of Digital Revelation, we're a security research group who actually formed here about five, six years ago, kind of centering around the DEF CON capture the flag originally and we've done some things since then but we usually seem to participate in the capture the flag events. So who here's uses BlackBerry? Who has a BlackBerry? Wow, I have a feeling more than that. Lots and lots of people use BlackBerry's. It's according to Gartner, they're the market share lead for handhelds and I thought it was pretty interesting when the when research emotion was going through the whole copyright issue and there was a potential for an injunction that government and emergency workers were gonna be it seemed like exempt from that because it was critical infrastructure so I thought it was it was worth investigating a little bit more as far as the security of it. I'm gonna take some time and go over kind of the background of how the BlackBerry solution works in in case for anybody who's not familiar with how it does the thing it does. Here's a diagram of a typical BlackBerry corporate BlackBerry installation pretty much. You've got your mobile devices here. I apologize for I thought that we could get the slides for part of it on both screens. We're gonna have a couple demos so if you can't see very well out in this side of the crowd I apologize but anyway so you've got your portable your handheld devices which connect to some wireless carrier next to or singular or whatever your carrier of choice is and then you've got this little cloud as if if any of you saw FX's talk he kind of goes into that as well where you've got a bunch of arrows on the you know the diagrams but nobody really knows what the the rim network really does and then that tunnels over the internet to basically your corporate your corporate network. So the bez and also different elements that are associated with the bez lie on your corporate network. Bez is BlackBerry Enterprise Server. There's also the MDS which is a component of that the mobile data service and attachment service and different things like that that can either be on one machine or separated into multiple machines. Then I have just typically the bez talks with the exchange box or Lotus or whatever depending on your installation and then basically just whatever other application services and things like that that you provide access to from your BlackBerry. This also typically users have work state a workstation on the corporate network that as long as it's on the domain and that user has a BlackBerry assigned to them then there's this relationship between when they sync the BlackBerry's and it does magical stuff that will go over later. So to break it down a little bit as far as how that all how it works how you can actually access internal applications and internet sites and things like that as in your mail and your calendaring and all of that from your BlackBerry. First the MDS actually creates an outbound TCP connection from from inside your network out to rim. You actually you have to of course create allow this by creating firewall rules and then negotiation takes place between rim side and your MDS or your bez MDS and that creates kind of a persistent tunnel between the bez and your and rim. That in turn the BlackBerry I'll go back for a second. The BlackBerry is of course connected to the wireless carrier and so with somewhere in that little that rim cloud the mystery network it gets connected and gets end-to-end encryption between the handheld device and your bez and MDS and all that jazz. So you end up with basically something kind of like this it's a persistent tunnel through the internet from from your bez out to the internet through rims network through the carrier network and to your handhelds and so basically your handheld then ends up virtually on your internal network which looks great because you can then access all your internal apps and browse websites that only you could if you're in the office things like that. Anybody see any problems with that though? Typically handhelds the security of handhelds that is usually focused around the data on the handhelds email things like that not what risk it can pose to your internal network. Here we have an always-on always connected code running device that sits on your internal network. So here's a just a you know simple review of that I think I skipped a slide basically. So the big problem and the reason why we figured that this research was a good thing to do and giving a talk this talk was a good thing to do was to increase the awareness with with BlackBerry users and administrators as to what the dangers the potential dangers could be and what an attacker could possibly do with the typical BlackBerry installation. So it's obviously important to remember that they are computers that sit on your your network and in your typical IT infrastructure though they're not thought of that way they're not thought of and controlled in the way that you know a VPN or a dial-up solution or something like that would be. So you obviously end up with with big problems so we can exploit this problem obviously that's why we're all here. So there's this out this little application through together called BB Proxy and what BB Proxy does is first it creates an outbound socket connection from your BlackBerry device out to an arbitrary attack or controlled host on the internet kind of like that. If you can typically at least from you from your BlackBerry you can at least browse websites. So if the if you chose to use port 80 or something like that then obviously most likely your connection is going to be allowed through. Then from the attack or controlled host we have a listening socket that that it's connected to and we create we tell the BlackBerry just to create a subsequent connection to a second host and and the benefit of this is that we can make a subsequent connection now to an internal host kind of like that. So now from our attacker controlled host we can directly talk to a machine on the internal network and and not have to worry about you know silly firewalls on on the perimeter. Okay so I think yeah I have a we'll do a little demo to just show how that works. What I'm going to do is just start up a netcat listener. Hold on one second and this will this will be kind of like our little internal service. Use your imagination for what do you want it to be. It could be telnet or SSH or an intranet site or whatever and on this host we'll start another listener. This will be our attacker host over here. So we have our attack host here on the internet on this side and our friendly little intranet site here here. So what we'll do is again just netcat listener now from the BlackBerry we'll fire up BB proxy. Do you mind questions during the talk or you want them afterwards. No you can go ahead. So maybe I missed it but this is predicated on being able to actually get code to run on the handheld which requires it to be signed and hashed by RIM which means they know about it right. Sure we'll get to that actually. You will. Okay. Yes. Just wanted to make sure that I can miss something. Thank you. Oh no. It's all right. I think we usually do. Don't we. Okay. So what we get is a helpful little message here that asks to enter the destination host and port in kind of standard fare. So we're actually let me kill this first. Sorry. I need to prove that we can't. I can't just connect to that because we could be cheating. One, two, three, four. So no, sit there. Nothing. Okay. Can we ping it? That's my special ping actually. Okay. Hopefully everybody believes it now. All right. Back to the we'll start up our listener. Firewall punch or BB proxy. I mean now anything typed we can interact just like it was in interactive service because it's being proxied through the conduit of the Blackberry. So it's over there. Okay. Cool. Okay. Back to the presentation. Okay. So now we saw we can interact now with a Talmud service or anything on the internal network without the silly firewall rules getting in our way. But this is Defcon, right? I mean we came here to break stuff, not just to do things that are nice. So we've all heard of Metasploit, I think, probably. The point click root from Spoonom and Hdmore and all those folks. Well, now it has Blackberry flavor. I just basically added a simple function to Metasploit, which will create a listener and wait for an incoming Blackberry connection. Once it gets that connection, it hands it off to, it stores the connection and will hand it off to whatever Xploit calls it. So I'll go over exactly the details of that too, kind of how easy it is to port Xploits over to use it and things like that. So basically, so I'll show a little demo of that. Pretty much the same thing, except now we're actually going to exploit a box. Clear? Okay. Yeah. No problem. Sorry. So start up Metasploit. And we have over here, our little host here happens to be an unpatched XP box. I know it's not very realistic that there would be, on the internal network, a vulnerable machine. So you're just going to have to use your imaginations. Listener function. So it sits and waits for an incoming Blackberry connection. So actually, yeah, 182.168.102.100 and port 1455. So that goes out and connects. And it got the connect. So now we can go ahead and just set our normal options like we would whenever we're exploiting a box. So hold on. So now we just exploit. And we've got root. All right, so cool. We can now root boxes on the internal network. Okay, so to port an exploit to use the file handle that we, the connection, it's actually pretty easy. I'm just going to walk you through the amount of code that it takes to port your basic kind of vanilla TCP exploit over to it. We use, I used MSASN1, kind of old school exploit, but it's pretty reliable, even though it's one shot. So basically first, we set the target to the, let's see, hardly see. Okay, so we listen for the proxy connection that there's a global variable set if if the Blackberry listener, the listener function has been invoked. And if we've gotten a connection from that that's been handed off, it's set to that global variable proxy con. Then from there, instead of doing the, we remove the standard kind of socket build stuff that that happens right before an exploit is sent. So the stuff that actually goes and makes a connection to a vulnerable service and replace it instead with if the socket that we got from the Blackberry exists, it sends it through that. Otherwise, it sends it, you know, the normal way. So as you can see, it's pretty straightforward and pretty easy to just port most exploits to this to use this conduit. We sleep a little bit just so that it gives the connect the second connection a little bit of time to actually make the connection. And then we send our exploit. The limitations with currently that we have with the Metasploit patches is that it's only it's limited to TCP based exploits, kind of vanilla TCP based. We've run into some problems with with certain RPC protocols and those kind of exploits. And it would be really easy to port it over to UDP and also to make to let it work with some of those as well. But just haven't gotten around to it yet. So look for an update to these patches. We're gonna I'm gonna provide these patches also to Metasploit so that you can play around with it. But check back to so one cool thing to it about this is that we actually have the ability to completely basically evade all perimeter defenses, not only just can we talk to machines behind the firewall, but because of the functionality in the best and MDS, we can we can really evade IDS sensors on the perimeter as well. We don't actually need to make to use the MDS to make the first connection. Most newer devices have a TCP IP stack on them themselves, and can make a connection from the device side via the carriers network. So what it's very easy to specify this in code, it's it's a simple device side equals true or device side equals false in the URL for the connection string. So what we can do is we can make a the first connection from the device directly from the device and then the second connection via the MDS. And you're essentially straddling the border because nothing ever actually travels across the the perimeter other than through the nice and happy encrypted network that goes from your best here handheld a little diagram of how that works. So the black the blackberry itself is is just going through the carrier network and making the connection to the attacker control box without any any interaction with the bez itself or the MDS. This is doing it just on the device side. Then the second connection is then the one that we are exploit is going over is actually going through the whole the what we described earlier, they threw rims rims network through the MDS and interior internal network connections. So it's a lot basic. It's a little bit of a complex diagram, but here you see the first connection out to the attacker control box and then the second connection going all the way through the rims network and the internet and the firewall and through the MDS and then and connecting to an internal host. So just let it basically just like having a machine, a workstation has two ethernet connections, one inside your your internal network and one outside on directly on the internet and straddling your perimeter defenses, kind of like the reason we usually don't allow dual home systems and configurations in VPNs. But again, people don't think of this as a remote access solution. Okay, so the problem with with this as far as a viable attack vector is that it really requires control physical control of a device to put your code on the device and and run it in order to go out to an attacker control host and et cetera. So the solution to that is a Trojan that you can actually download over the air and have the users run without seeing anything, of course, just like we all know what a Trojan is. So hot game 2006 is has the same functionality of BB proxy. The user only sees the game interface, the tic-tac-toe is our hot game. We have the ability to over the air download. And of course, this is just a proof of concept. So it's fairly limited in function, just kind of plugged in the code from black and BB proxy. But obviously, you could use a lot more specialized control channels and things like that like IRC and also functions to identify kind of the the internal network structure and that sort of thing. Right now, we just have a hard coded host inside. So I'm going to demo that again with our imaginary vulnerable system on the internal network. Everybody can see? All right. So hot game 2006. It's actually flipping sweet. You should check it out. Okay, so we got the connect and Temtale is going to play tic-tac-toe for us. Hold on. Well, hold on. Maybe Temtale won't be playing this once. All right, we're back. Our configs are still the same. So the user won. But I actually won. So as you can see, we have a root again. So hold on. So like I think Toby said, RIM actually requires code signatures in order to use any of their proprietary APIs within the J2ME edition that they have. Also, without your code being signed, a third party application requires like verification in order to do network access and things like that. The reason for this is they they take basically a hash of your your code and you send that in and you pay a hundred dollar processing fee to get a private key basically. And so when you have your code, you send that in and they sign it with your private key and you get a signed code back or you can sign your code. So the way they verify this though, you can order a signature online with a hundred dollars via a credit card and they make sure that your name and address, you know, match what's on the credit card so that if somebody were to write some malware for the BlackBerry, no, we would do that or anything. But they can go and look who did it and go and prosecute. Hopefully not. So there are prepaid credit cards. So FX brought up that they have, I mean, there's no such thing as stolen credit cards, but even one better prepaid credit cards are very easy to acquire. Apparently, they don't have them in Canada. But you can go into most supermarkets here in the states and drop some cash and get a nice prepaid American Express or Visa or MasterCard and go and sign your code. Completely anonymously, obviously. So we have so far we can talk to hosts behind the corporate network. We can attack them. We can subvert the IDS and any data logging. Also, thinking about that as far as the whole subverting all perimeter defenses, one aspect of that that I didn't talk about other than IDS is that things like the regulations that are now with due to the SEC and things like that where they actually have to log all data that comes in and out of your network. This would be a way for someone to leak information from the internal corporate network out to the internet without any real traces. Okay, so we can also sign our Trojan anonymously and use all the APIs. But it even gets kind of worse than that or better, depending on your perspective. This is actually kind of funny as far as a story but device provisioning, how they how you can provision a device on the internal network, a new device to a user who has been configured to have a BlackBerry. Obviously in security, ease of use versus security is always a fight and ease of use usually wins because marketing guys have more pull in most companies. With BlackBerry, it's extremely easy to add a new device. Actually, as long as the user is on the domain and they are configured to have a BlackBerry, you plug in the device and it will ask if you want your new device put onto the network and replacing the old device. So, then the new device is on the network. Each BlackBerry is identified by a unique pin. As you can see, the second one from the bottom, that pin actually identifies to rim the device, the handheld itself, so how to route whatever traffic is coming from the device over to the appropriate network. So, when a user plugs in their new device to a PC, the new pin is recognized and encryption keys are basically are generated and then stored on the BlackBerry handheld. The new pin and the newly created keys, encryption keys, are also then pushed to exchange via the MAPI interface. And this information is stored in the BlackBerry handheld info hidden folder on exchange in the user's mailbox. After that, basically, the MDS on a regular interval, depending on what the administrator has said, pulls the exchange mailbox for any new information. And when it does and it sees an updated, updates its database and in turns updates rim and now the new device is on your internal network. So this process can be obviously automated because it's fairly simple, actually, just using MAPI in order to push this stuff as long as the user is on the internal network. I was hoping to have an automated, nice demo to show you of placing a rogue device on the internal network, but was in Europe for the last three weeks and didn't have any time to sit down and pound more code out. So hopefully pretty soon, if you check the website, I'll have a demo up and some code in order to show this process of basically hijacking a user's connection. Shoot, I need to change that. Stupid technical difficulties. You can check either Pretorian G presentations, Blackjack, or didrev.org slash Blackjack for the slides for this and also the code. As well as if you go to blackberry.com slash security, they've done a really good job. It looks like of responding quite quickly. And they've updated with good white papers for how to securely deploy the Blackberry solution and segregating your Blackberry, your BEZ, and your MDS from the rest of the internal network in order to protect the internal network. As well as security precautions for general security precautions for malware in the Blackberry solution. Any questions? The question is, what is the latency? It's GPRS. And so what is the latency through the Blackberry? If it's fast enough to drop the VNC, reverse connecting VNC payload? And yes, it is. Actually, I was hoping to do that as a demo, but the stupid Mac, I couldn't get the VNC client to order. So yes, it is and it is successful. The other thing I wanted to point out was that we had to use the emulator because there was no actual feasible way of showing a real Blackberry device up on the screen, other than holding a camera over it. And actually, apparently that's what RIM does too. But this does work actually on real devices. So Eli, scanning the internal network, we actually have a port scanner as well for the Blackberry. They actually, it's interesting because it is a little bit more difficult to scan the internal network than it is to scan the external network because the MDS, just where it should give you certain error conditions, it just craps out. Basically, part of it, I'm told, is because of trying to compensate for latency. And so when you try to make a connection, like a SIN connection to a TCP port, if the port's closed, it won't throw an exception for like two minutes because in case you're going through a bad signal area and things like that. So it makes it kind of hard to write a port scanner and certain, especially a port scanner, in that specific condition. What we're doing actually is having a separate thread that runs beside it in order to basically, if it lasts more than a certain amount of time, kills the first thread and marks it. Any comments about the Blackberry, the IT policy that's in the BEZ server, that they disallow loading third-party applications, disallow external connections, specifying which applications are allowed to use the MDS conduit, basically? I know that the defaults, they allow this, basically. But many comments? The comments from my side are mostly just that it's insecure by default, but it is this particular, the vulnerabilities highlighted here are protectable with the policies. If you use policies to restrict your users from downloading third-party apps and things like that, then you can restrict people from doing this kind of thing. The problem is, in my experience in talking with customers and things like that that have Blackberry installations, a lot of times administrators, by the time they get the Blackberry, their BEZ and everything up and running, they've been quite frustrated and are happy that it's running. And so I would suggest, basically my suggestion to RIM, and I've talked to them about that, is more secure out of the box. But the mechanisms are there to protect most of it. So a Trojan that would be persistent after a power cycle. Well, there are APIs to run things in the background. So actually, especially since our code is signed anonymously, we don't actually have to have a front end for the user, that kind of thing. The user could download over the air. And like many things, it just doesn't work for some reason, and it's running in the background. And I believe there are also APIs for starting something, basically starting something up on startup. So essentially, it would be possible, probably, so. This may be an aside, but did you look into the hashing algorithm they use for the sign code? Do you happen to know what the hashing algorithm is itself? I bet Ian does at SHA-1. I knew that, actually. Because if you could defeat that and use a signature for a matching SHA from a valid app, if you could defeat it by using a matching SHA from a valid app, I was hoping you'd say MD5, of course. Johnny's being awfully loud. Got it. Sorry, I can't. I'll ask FX, please. Now, you said that your code that you have downloadable on your website is already pre-signed, then? No. Only for the demo. No, actually, what would be on the website is the BB Proxy, the actual user interface one, and the patches for Metasploit. And also the port scanner will be also available. The Trojan is not going to be available on the website. But for that BB Proxy, is that signed, then? No. So if we actually want to try it, we have to send it ourselves? Yeah. Well, I mean, you can use it. It will ask you, when you try to make a connection on a real device, it'll ask you for confirmation. But you can use it without it being signed. It's not using any of the restricted APIs, actually. And just as a follow-up, does RIM currently have in their infrastructure the ability to revoke signatures of something that's already been signed and automatically push that out to all their devices? Does RIM want to comment on that? I guess that's the answer. Actually, he just asked part one of my question. But the other part was, is there way RIM can filter through their mystery network these attacks? I can't really see a way of filtering these attacks, because it's really, it's legitimate traffic. RIM, as far as, I mean, that's the whole thing with the security of the BlackBerry, is that it's end-to-end security. The bez has a key, and your device has a key. And RIM can't see what's going on in that tunnel. And so as far as, I assume maybe you're talking about IDS or intrusion prevention on their side to block traffic. Is there anything that identifies like the application when it's going through their system, like the packets? No. No, yeah. There's no review of code in any way. It's just, basically, they take a hash of the code file, and that's what the signature is based on. It's not a review of the code in any way. It's really, as far as I know, the only purpose for it is to make sure that if somebody does something bad, they can figure out who it was. If you own the bez, sure. Yeah, that would actually be, that is another potential attack vector that we've played around with, is using FX's exploits for the bez itself. One email, own the bez, kind of thing. Basically, if you own the bez, not only can you push it out to all of the other, all of the blackberries on your network, because you can push applications. You could also provision yourself a new device and place your attacker-controlled device onto the network without even having to have code run on a workstation or anything like that. Can you come over to here? Is that possible? Oh, OK. Well, between a Blackberry handheld and a Pocket PC, I wouldn't want to be the one to have to make a statement about that. There's kind of differences in a lot of ways. The Pocket PC is not persistent on your internal network. If it's on your network, it usually has a Wi-Fi card or an ethernet jack, and it's on your network when you're in the office. It's not like a Blackberry where you're actually really always on, always connected to your internal network. And so it can be, your internal network can be attacked wherever your Blackberry is. I'm going to have to, if there's other questions, I think we'll have to move out of the room, because it looks like they're shooting us out. But thanks to Didrev and Pablo Marx, because I didn't know Java, and FX, and Ian.