 My name is Peter Hane. My talk is called exchanging demands and I'm going to be talking about the relationship that exchange servers tend to have with their mobile device clients and how poorly implemented those things can be on the client side. Closer? No problem. Fine. All right. And the relationship that these can have with the clients and how badly that's really done when it gets to using these things. So for a start, let's go into an introduction about me. I'm a pretty big fan. So who am I? Like I said, my name is Peter Hane. I'm a lecturer at a university called Edith Cowan University in Perth, Western Australia quite far away, about 28 hours to get here. Yeah. Great trip. I teach a few different subjects. So network security, computer forensics, and recently I had a unit approved called ethical hacking. I had to put the ethical in there to get it approved. But I teach my guys how to pop boxes. So I'm pretty happy that that got through. All right. In terms of my research, small device forensics, so pulling apart things like phones and routers and video game consoles, figuring out holes and how I can acquire data and do data analysis on those. You know, interesting stuff, not really, I guess a bit relevant to this, but not tons. I'm a hacker. I love just breaking things. You know, I'm sure that's why you're all here. You love breaking things too. So yes, breaking things. I'm a pen tester. I'm also a white hat sellout. I like getting paid. It goes well for me. It's a good thing. And last of all, you know, I'm sure I've got other attributes, but you know, here we go. I'm a PhD candidate due to complete in the next couple of months. And then I'll be talking down to you all and it's like, that's Dr. Peter. Yeah. So that'll happen. All right. So my interests. I mentioned breaking things. So first and foremost, you know, the hacker attitude, let's break some stuff. Let's figure how it works. Let's make it better. Let's just make it do something it's not supposed to. Into that, I also love laser tag. Yeah. Now, a lot of people don't know this. They're international organized laser tag competitions. You know, a couple of the guys in my team recently went to the international finals in New York and stuff like that. So it's a, there is a thing there and you know, there is competitive laser tag. So you should all be aware of that and go play some laser tag. Cats. I love my cats. So we've got the pale one is Alice and the darker one is Ada named after Ada Lovelace. Not the programming language, the woman. So that's okay. All right. So really into the talk now. You now pretty much know everything there is to know about me. Yeah. I'm very efficient. Okay. So a quick note first about what this talk is going to be. I looked for a place. I could put this info in the talk and nowhere seemed really to fit. So I started the beginning. I'm not dropping mad odays or anything here. There is no bug. There is no vulnerability as such. There are some poorly implemented protocols and what I consider to be very poorly put together UIs, which lead to a situation where an attacker can do some incredibly nasty stuff to people who are using exchange clients on their mobile devices. Okay. That's what this is about. You know, if there's no buffer overflows, it's nothing like that. And that's probably the strength of the talk. Anyone could have done this if they know how to operate wire shark and write about 30 lines of Python. Okay. That's why it's a problem. So that's it. You know, not leech, not hard to do, no amazing bugs, no odays. But, you know, this stuff happens and it works. All right. So I like stories. I'm a big fan of narrative and I'm going to try and structure this into the form of a story, but I've never been good at writing these things. So you're going to notice me swap tensors and, you know, pronouns and things are going to be all wrong, but hopefully it will be interesting. So here's our setting. This is post-pentest drinks with a client. You know, I'm sitting down with this guy Friday afternoon having drinks. He's read through the technical draft of the report. And, you know, this is a high-up manager. He doesn't really understand it. He's just flicked through it. One of his minions has advised him on some questions to ask. Anyway, so the question comes up. So if you own the Active Directory server, what exactly can you do? All right. And we know this, but, you know, this is a non-technical guy. So that's okay. And when it comes to this, yeah, it's the normal thing you'd expect. You control every user on the domain. You have the ability to push policy updates to every controlled machine. You know, you can do pretty much whatever you want on that network. But what came up for this guy I mentioned was like, well, I know I can remotely wipe phones from exchange like when we've had phones stolen. We've done that. Could you do that if you compromised AD? And we're like, yeah, of course. You know, that would be doable. But here's where it got interesting. The idea was, do we really need exchange in order to be able to wipe all these devices? I mean, really, it's just, you know, TCP-IP. It's just connection states. It's just, you know, please wipe yourself now being pushed from a server somewhere. Why couldn't we implement that ourselves? All right, and now here's the time for my first question. And you're, oh, actually, first of all, first time DEF CON speaker. So here we go. And now it's your turn. So I just, who here runs an exchange server? There's a few at Black Hat. It was just like, you know, all right, so these, just keep your hands up for like 10 seconds so these guys can spot you. All right, so there's shots going out. That's fine. All right, just a few, there'll be more going through. All right, so I'll just continue while these guys bring around a few shots. Do we really need exchange? Probably not. Maybe we just send the phone these commands directly. Maybe we just wait for a connection, do a man in the middle somehow. You know, man in the middle is easy. There's different ways to do it. But maybe we just send the phone these commands. Thanks. And see what happens and see how it goes. But really, thinking about it, if it were just as easy as capturing a couple of packets and replaying them to a phone to have the phone just wipe itself, there'll be more later, don't worry. Okay, but it couldn't possibly work, surely. There's going to be something to stop it from happening. We can't just replay like a packet and all the phones raise themselves. That would be ridiculous. It couldn't be that easy. It really couldn't. It's not, I'm sorry. Okay, surely we've got SSL. That if nothing else, SSL is going to stop this from working. Like, you know, it's going to go, that's not, no. Surely. But in addition to SSL, let's just assume we're going to have something else. And it's probably a good assumption. In most cases it would be. You know, if you had a server that could push out all these sort of commands, there's going to be some sort of extra secure exchange, some sort of stored secrets, you know, just something. You sort of logically think about it and think there's got to be something in there. All right. So, I'm not a Windows guy. I'm not a, you know, exchange server admin. I'm not a, yeah, that's not me. But I know people who are. Remember, I work in a university. So I just walk down the hall to the guy who teaches the Microsoft certification stuff. Which is this guy, Brett Turner. So I have a chat with him. He's always good. He doesn't drink at all. But, you know, people give academic bottles of liquor. So it's fun visiting his office. Anyway. So I have a chat with him. And what he told me was, this will work as long as SSL is disabled. If this SSL turned on, you've got no chance. Okay. Well, I thought, let's just try it anyway. I'll implement it without SSL. And then it's fine. And I can demo it to my students at least. And then I'll see if it does work with SSL or where the actual mitigation is. At this point, really, what I was thinking is, on every phone that I try, I'm probably going to get a pop-up box saying the certificate has changed. Do you want to continue? Yes, no. Or something like that. And I thought, I can probably, you know, change the name of this CAE or something to make it look like, please click this button, you know? That's what I was thinking at that point. But, you know, I'm sure we could do something about it. So I thought, let's get started. Let's try and make these things work. So first of all, exchange. Let's get some packet dumps. Let's set up an exchange server, connect some clients to it, fire up Wireshark, grab those packets, and see what we can see. See how these things work exactly. Great idea. So, I figure. I've installed post-fix. Yeah. I've installed Sendmail. You know, I'm a Linux kind of guy. And everyone's like, well, yeah, Windows is easy, right? No. It's horrible. Yeah, it's crap. I can't do this. I downloaded the manuals and stuff. No. But thankfully, like I said, we've got this guy. He teaches students how to do this stuff. He's all busy and wouldn't do it. But what I had was, I had some students hanging around. These were students of his. They, you know, do Microsofty stuff. Cool. The two on the left and the two on the right. There's a nationwide capture the flag competition run by government for university students in Australia. Anyway, so I trained these guys up. They entered the competition. You know, really, we're doing very well and then came second. But second in Australia is still good, right? And I'm breaking into this because the first prize was a ticket to Black Hat and Def Con. And so, you know, I've had drinks with the team that did win and I've got photos of me with them that I'm going to send to my students. And, you know, I think that's nice. But, yeah, the second prize, and this was our major telecommunications carrier that decided, you know what every hacker wants? You know, the second prize, they want an iPad. Yeah. So let's give them iPads. You know, all I'll say is, again, when it is a Black Hat, everyone just like, yeah, they want iPads, right? Anyway, so those were sold like 10 minutes after they got them. But just, they are saleable. That's a really good thing. But anyway, so these are students I had laying around. A couple of them had the MS certs. I was like, can you please install Microsoft Exchange for me? And, yeah, they understood and they did that. And that was great. So in about a day and a half I had an Exchange server with all the security options turned off so I could gather this data and see how it all works. So this is good. So, we did some packet sniffing, all right, and found the packets responsible for the white command. And what we were looking at was a two-stage process. So the first part is any request at all. And you can see I've just like dotted out the command, mainly to save space on the slides. But really, it's just because this could be any active sync request coming from a mobile device. It doesn't matter what it is. All right? In this case, I don't know, probably checking email or something. It doesn't matter. The next step here is the response to the I want to do anything at all over active sync request. And the response is HTTP error 449. Microsoft love inventing extra errors. Please retry after a provision command. I can't really read it down here, so I'm pretty sure that's what it says. And what that does is it's basically saying, I'm not going to talk to you or answer your requests until you request a policy update and adopt a policy update from the server. Okay. So this is the first part of it. And generally the device will make four or five requests of different types before it goes, okay, I'm giving up. I'm going to send the provisioning request. And that's when we get this part. So this is again just another request saying, hey, I've given up. Please send me the new policy. Here's the format I wanted in. And it wants it in WBXML. And great. So we reply. And we say, well, here's your new policy update. Here's what you are going to do. Here's what you're going to adopt. Now this really doesn't mean much. It's a binary protocol. So you can see the header and after that it's just you know, the periods which represent any of you know, 70 possible bytes, more than 70, you know. So it's a binary protocol. So we want to look at it in some sort of hexadecimal format and try and figure out what it does. But thankfully Microsoft published a very nice spec on how to decode these things. So it wasn't really too hard. So we managed to decode it. And there's a reason it's binary. It's not obfuscation. It's not you know, trying to hide anything. It's just these are things you're pushing to mobile devices. So if you can save two, three hundred bytes, you're doing a good job. So I'm a big fan of it. You know, it's efficient. It's semi well documented. And it's a pretty awesome protocol overall. So the idea is they just implemented XML in a binary format to safe space. So if we decode it, we end up with something that looks a little bit like this. Now there's a few options here that come into this policy thing. You can probably read some of them. But that's fine. I'm going to read them off and there's a bigger slide with them later. Essentially you can do a few things. You can set our timeouts for screens going inactive and saying you know, there's a maximum of one millisecond of no use before your screen turns black. You know, you can turn off Wi-Fi remotely and especially on like a Wi-Fi only iPad or something like that. If you push a policy saying to turn Wi-Fi off, it's very, very difficult to push another policy to allow it to be turned back on. Yeah, that was a bad decision I made when playing with it. Okay, yeah. There's a lot of other things you can set minimum password lengths up to you know, a couple hundred characters. You know, there's a lot of cool things in there that might be useful, that of course are useful in a corporate deployment but if someone were to get control of them they could be troublesome or potentially unhappy making for a particular user. And the one I chose for this demo, and certainly we can do a lot of things with this if it works, let's see. But the one I wanted to give for the talk as a demo was this remote wipe command that's in there. Because I figure that makes a good demo, you know. It's better than, hey look now the screen timeout is real fast. It's, the devices are raising itself. Okay, so we'll see that a little later on as long as my demo succeeds. Hopefully. Alright, so we're going to talk a little bit about the background of this now. So here's the structure that we have when we look at an active sync, an active sync session, you know, IIS and the exchange server on the back end and OWA there. And what you can see is that there's a relationship. So exchange talks to IIS, and IIS essentially has, you know, two sub-sites. One is active sync and the other is OWA, and that's how your mobile devices and your web clients talk to exchange. And you know, there's all this data exchange back and forth, but this is how it all goes together. So what we're doing is we're targeting that little bit that connects the phone to the active sync thing. That's where we're inserting ourselves when we're going to man in the middle. That's a part of the protocol where we're going to try and deal with. So it's that sort of last mile to the mobile device, and that's what we're looking at, and that's what we've been looking at so far. The rest of it's, you know, just neither here nor there. Okay. So now this thing that I, you know, did the manual decode on, it's in a format called active sync WAP binary XML. And it's an interesting protocol. There's a lot of extra functionality in there. There's things, I'll talk about those later, but let's get on to the implementation. So, we can man in the middle devices. Now the easiest way to man in the middle is something, and then there's a great Wi-Fi network here. Okay. I'm not going to talk on how you might man in the middle of something on open Wi-Fi too much. I mean, I'm sure there's like 20 talks you could go to, or, you know, just Google it. Yeah. You're going to be fine. So phones are cool. Wi-Fi is cool. Phones have got Wi-Fi. I sort of figured we're going to do the Wi-Fi angle. We're going to man in the middle of Wi-Fi, impersonate a server, and see what we can do to the phone. You know, you could use art poisoning. How many people are familiar with the Wi-Fi pineapple? Anyone? Yeah, we've got people. Where's my helpers? Drinks. Geez, that's a cheap tequila. Alright. Okay. So what the Wi-Fi pineapple does for those not familiar with it, is it basically, it's, you know, an embedded router running Linux open WRT, and it supports a few things, but what I'm using it for is the idea that it listens for probe requests from, you know, your laptops, your phones, saying, I'm looking for my cool home Wi-Fi or my work Wi-Fi or whatever else, and the pineapple goes, yeah, that's me. Brilliant device. I mean, no way claiming responsibility for it, just saying it was a very easy way for me to implement and demo this. Okay, and I think it's ideal. You know, it's battery-powered too, and it runs Linux, so you could put the whole attack on it and just throw it in a backpack or something. You know, it's a pretty good device. So that's the platform I used for testing. Now, as for the target selection, I decided to have a look at these guys. So we've got Android, we have iOS, and we have Windows Phone. So the most common mobile platforms are what we're going to look at, and, you know, we've got different degrees of success. So let's try and do a wipe. All right, and by the way, when I get to the demo, I'm doing my demo live, because last time I, you know, tried to rehearse the demo and do a recording, I messed my phones up so bad that I couldn't do the live demo. So we're doing a live demo. If it works, awesome. All right, so the dance. We're going to wipe some stuff. How are we going to do it? Well, first of all, we're going to accept a connection, and if we're accepting a connection, and we're accepting a connection over SSL, we need a shonky, self-signed SSL certificate. And I thought, you know, I'm not going to try it. Originally I was thinking, you know, I can accept it, I can look at the header, I can generate, I can go out, retrieve the real certificate, then generate a new certificate where all the fields match. The only thing is itself signed rather than signed by a CA. You can make it look really good. And then I thought, okay, I'll do that if I really, really have to. But I'm a lazy guy. So I thought, I'll just generate, you know, a really simple one. And, you know, this is essentially what it was. You know, you see it's lols.lols. You know, that's a photo shop there, because the actual certificate name was incredibly profane. But yeah, I just basically matched buttons, filled out all the fields funnily, the domains don't match. You know, this is a completely invalid certificate. Probably the only valid thing about it is that it expires in the future. That's it. Okay, everything else is wrong with this. It doesn't match anything at all. So this is pretty much the worst certificate you could have, unless you had one from like 1920 or something. Okay. So we accept our connection. And that really shouldn't work. But let's say it does. If it does work, then the next thing we know is that we need to send a HDP error 449. So this is, you know, the Python code to generate that command. You know, it's just straight from the packet dump aside from the, you know, time which had to insert there. Because when I was playing with it, none of the phones would accept, you know, that accept the dodgy stuff, other things, but they really wanted the time on this provisioning request to be somewhere near reality. So I did that. So we've got something there. And step three is to send that white command. And I sent exactly the white command. You know, the HDP header for the white command. Still, I'm using a date that was months and months and months ago. It doesn't care about the date on this one. It cares about the date on the provisioning request. I don't know. It's a little bit odd. So here we go. Demo time. Please just bear with me for a moment while I turn my phones on and turn wifi on and things like that. It's going to be about two minutes. Shots. That sounds good. Who has a telephone on them? Just pulsate the crowd while I set this up. Okay. The iPhone is a bit bright, but you don't really need to see too much detail. I've got a screenshot of what the iPhone does a little bit later. So we should be okay. All right. So I'm a big fan of the Fallout series. You know, anyone play Fallout? Yeah. Okay. And I was sort of thinking, you know, I'm coming to Vegas to represent New Vegas. I just recently enjoyed New Vegas. So the name of the proof of concept is New Coca-Cola. And so what we'll do, we'll fire the POC code up. There we go. Yeah. Okay. And back to the phones here. Now, I don't want to wait for them to check their email. Last time I did that, I ended up, you know, going, why isn't it working and they're picking the phone up and the phone erased itself. I was in my hand, not in front of the... So first of all, this is what the iPhone does. The iPhone basically comes up with three options. Continue, cancel or details. But continue is highlighted blue and is separate from the others. It's pretty obvious that if we were a CEO, we'd press continue. Okay. And of course, I'm off the display here. And now I've got the Android phone. Let's go. Where's my corporate email? Okay. So the Android is now checking corporate email. Let's hope that works. The Apple is rebooting happily. This is what happened last time. I'm not going to pick it up. I'm just going to pick it up. Oh, really, an error. I'm going to actually attach the antenna to this thing. I didn't want to do that. Don't worry, it's not spoofing like access stuff at the moment. It's just... Okay. So the Apple's done. So we've got one factory reset iPhone there. That's helpful. And you know what? It's exactly what happened last time. Where are we? That was with? Yes. Yeah. Yeah, I'll talk about the results. Who asked that? Yeah, you asked that. Do we have any shots left? If we do, there. Actually. Okay. Since I last played with the Android, I hadn't rebooted it. I do some funky things to them. So that's just going to reboot now. When it comes back on, we'll try it again and you'll see what happens. But I'll just continue for now and talk a little bit about the results that came out of this and sort of which platforms were vulnerable in which situations. Now when we tested it, I did it in two main ways. First of all, I tested it with my phones connected to an exchange server which uses SSL with signed, valid, you know, certificates. And then I tested them when they were connected to a legitimate exchange server with self-signed certificates. And with those self-signed, the ones I used were the ones that are generated by default when you install an exchange server. And anyway, in our testing and you know, surveying and everything else, we found that if you look at small to medium businesses, we found one in the sample of 100 we looked at that didn't use the default SSL certificate that exchange generates. So the majority of small to medium businesses are making use of self-signed certificates, so that was like that to cases there. And then we also tested the other. It's not working. It had helped the script running. And there we go. So that was the problem. I wasn't running the script. Okay. So I'll just leave that up there, you know, finish wiping. Oh, there we go. Now, reset the factor default. So now it's going to spend about 20 minutes booting for the first time. So that's done there. You know, if you've got really good vision, you can, yeah. So it did work. It did work. I'm very happy with that. The last one, the Android wiped itself in the air anyway. It worked. Great. And you saw both wipes happening. This makes me very, very happy that you saw both of them work, that did happen. Great. Okay. So I mentioned that I did testing. So I had mobile phones in two configurations. The first was connected to self-signed dodgy certs running on an exchange server. So the exchange server generated ones. And then a server which was using Proposy ASIGN certs. And the difference, the reason I did this was because there is a difference in the handling in Android. Basically to use a self-signed certificate in Android, without a ton of messing around, you need to turn on an option which says accept all certificates. Now, a sane person would think that this meant, you know, accept all certificates, whether you're connecting to a new server, but if that certificate changes, you know, during a transaction or just randomly, that's something that's probably wrong. No, it really just means all certificates no matter what, accept. And that's problematic. And I'm sure we can all agree that that is not a good behavior. Now, if you were using Android with a proper valid certificate, so you didn't need to turn that option on to use it, so you're, you know, the large enterprise organization sort of level, or you're in a small to medium with good understanding, or you're a home user who's for some reason running exchange and knows what they're doing, you know, whichever. You've got an admin who knows what they're doing essentially, then it doesn't work. It just displays their communications error, the same one that you saw when I didn't actually have my script running listening, that's what happens. So if using self-signed in an Android, this will work, no user interaction required, nothing else, it just goes to check its email change, bam. Okay. So iOS, in either case, self-signed or legitimate from CA, it will display the same warning, cannot verify server identity with the big blue button to continue, and then it arrays works. Now, here's the thing, Windows phone is the only one which did exactly what I thought it would do, and what it did was, if it noticed a self-signed certificate was changing and it's actually really hard to use a self-signed certificate on Windows mobile, Windows phone rather, you have to go in and manually install that into the phone's certificate store and do all this sort of stuff, and then of course when it changes, it's not going to work, because it's like, okay, this is an in my certificate store, and if it uses a valid sign certificate and you try and swap it for a shonky one, it just goes, no, connection error. It doesn't give you the option to continue. In that case, what you've got to do is remove the account, you know, install the certificate into the certificate store, recreate the account, and it starts working, and I think that is good behavior, because in reality, if you're looking at, you know, a centrally managed phone, they can push out a new certificate to all the phones two, three months ahead of time, you know, and then when they make the change over, everything's okay. To the point, if you're saying it's a desirable behavior to allow a user to accept a new certificate when it changes on the fly, it boggles the mind. If you're going to have corporate security features in there, so you can wipe phones remotely, so you can protect your data, have stuff in there so the user can't just screw it all up by pressing a button. All right, so in case you couldn't see it on the projector, because I noticed the iPhone's really, really shiny, you know, this is what the screen looks like, and you know, essentially what it's saying, do you really want your email? Yeah? Okay. Well, continue. Just press the damn button. Okay, and that happens. And yeah, so we did some testing just around campus, handed a phone to people and said, check the email, and they all pressed the big button, so we're pretty sure that's what most people are going to do. If you press the details, it shows the certificate information. If you get a $15 certificate from GoDaddy that was signed and the domain matched, then sure, that's valid like anything else. The iPhone does check to make sure the domain matches, that's still a problem. All right, so that's what we're ending up with here. This is how it all happens. Now, I want to talk a little bit about where I want to take this in the future. Now, certainly, it's not just about wiping. If you look back, back, back, back, back. Okay, at any of these requests, you'll notice that the passwords are base 64 encoded. Okay, so it's just basic auth. So a remote wipe is just a demo of one of the things you could do, and it's a pretty good impact. You see the camera, you see the factory resetting, that's great. By the way, I bricked my demo unit. I just erased my phone to impress you all. So, you know, thank you. So I'll be fixing that up later. All right, so the request has base 64 encoded passwords using basic auth, which generally wouldn't be a problem because SSL is protecting it. However, in this case, SSL is not protecting it because of the shonky implementation. So in essence, we could remote the device. We've got that password. We can connect to the real exchange server. We can take all their emails, all their records, everything else. You know, this isn't a remote wipe bug. It's just remote wiping is a cool demo with something you can do with it. You can do anything that involves the ActiveSync Protocol server or client. So, which brings me to this sort of compulsory open source software project announcement that, you know, you see after most of these talks, I want to put together a protocol library. I've already started doing a little bit of it to emulate as much of the ActiveSync protocol as I can. And I'm doing this in Python. There's basically, if you look at the client which is open, you can get it all, but it's in Java. And, you know, I'll probably just steal that. Someone suggested that to me. And I'll port it to Python and try to implement, you know, even the undocumented stuff. Because I want a really good ActiveSync library because I think there's a lot of potential for open source projects to integrate well with exchange servers. And right now, most of them just don't. Also, you can interact with mobile clients in new ways, like wiping them. Okay. And it's also could act as a translation layer between exchange clients and other servers. So you could do some extra validation, implement your own security, you know, implement new features, that sort of stuff. There's lots of things you could do with something like that and I'm going to try and make it happen. I've got a couple of people on board, so it's good. All right. Another goal. Data theft. ActiveSync as a protocol by its very nature is able to retrieve, you know, data in both directions. So rather than setting all their emails, we can also connect to the client and synchronize any of the locally stored folders in the mail client. So any drafts for emails that haven't been sent yet and haven't been synchronized, any local sent items, if those aren't being synchronized, we can grab a whole bunch more data back off. However, I've seen some deployments which feature remote backup functionality and what I'm looking into is how these things really work because there's a potential that we could possibly get more data off the devices and maybe we can get their photos, maybe we can get other things, maybe we can pull much, much more information off these devices. And this is a goal I haven't, you know, started on it yet, but it's something I really want to do because I feel this is potentially devastating. Yeah. As in, yes? Absolutely. No, yeah, I can see that happening and I don't feel it would be a huge issue. Ah, right. Defensive. Sorry, sorry. So, I was very confused. I was just thinking how is this a problem? Sorry. So I understand completely where you're coming from now. My strong recommendation would be use science certificates and don't use iOS. And just standard stuff, you know, monitor where your connections are coming from. If it all comes over, you know, a single telco provider that your corporation sent users do that. There's a functionality to push out to disabling Wi-Fi to any of these devices or one of these things because it's a weak point. You know, as we've seen, you know, the DEF CON secure Wi-Fi is ownable. You know, there is no secure Wi-Fi. Do not allow it to exist in your corporate networks and a lot of the problem goes away. I'm not saying they're not going to be really angry. I'm just saying that's how I deal with it. And, you know, aside from that, maybe give everyone a marketing and Windows phone. I don't know. Sorry to see you in time. Yeah. I am, what do I think about bring your own device, BYOD? I am a big opponent of it. I feel that if you're allowing untrusted devices into your network, the whole idea of perimeter security is gone and perhaps perimeter security shouldn't be relied upon and, you know, it certainly should be a line of defense. It shouldn't be your only line of defense. But I think if you're, you know, getting into our base sometimes, but, you know, it's, it's mostly, we don't do it often and, you know, if it does, it's only, you know, because, you know, people want to bring their friends. No. I really don't believe in BYOD at all. Yeah. Yes. Same result. Yeah. Okay. I've got one more goal and then I do some thanks and a conclusion and there's more shots and, yeah. So my lofty goal is configuration options that you can push through with Active Sync and one of them is to change the outgoing mail server and, you know, this is necessary in some deployments such as, you know, yeah. So, so you might want to change your outgoing mail server because they have to use their ISPs, SMTP server or something weird but you can push that as a policy update down there. So essentially we could have persistent access to all their outgoing mail from that device. We perhaps say and it would make sense from an administration point of view that there might be a feature in there somewhere undocumented because it's not in the doco that says from now on use this server instead for everything. You know, something like that. I want to see if there's a way to get decent ongoing access and I want to try and implement that so we can have sort of a persistent man in the middle after they've left our area of influence. And, you know, like I said, there's nothing hard about this. It's just making use of the implementations of SSL and giving the user too much control over things that honestly, and, you know, honestly, I would prefer I didn't even have access to that. You know, maybe when I'm at the server console or whatever, but an end user shouldn't be able to just go mash and go security's lane. It's not a good idea. All right. So, in conclusion, this is a problem. And, and I just want to reiterate, thank you, I just want to reiterate again, that this is not a vulnerability in exchange. It is not server side. This is just a problem with that last mile active sync connection to the mobile devices. Okay. It's just a bad implementation on the client side. There's, like I said, nothing lead about it. It's, yeah, pretty much. All right. So some thoughts. I've been, I noticed this code came up when I was sort of googling to try and find out if anyone had presented something like this before at a hackathon because I didn't want the audience says, isn't this the same thing that I did seven years ago? Okay. So I looked around and what I found was this piece of code here. A few years ago, this is Android code, by the way, someone threw this all up on a news site and got all huffy and they're like, Google has access to remotely wipe your devices if they don't like you anymore. Okay. That's not what this code is. If you look through the context, what this code is, is that they're trying to sell a competing product, the Google remote wipe is one of those pieces of functionality. Now, I haven't had time to properly investigate this or implement it, but this is the code responsible for it and if you have a look at that if statement, I really don't like what I see. Yeah. I can't imagine that works incredibly well and I think with some basic DNS spoofing, we might be able to achieve the same result. However, like I said, it's untested, so don't quote me on saying that it works. I'm saying it might encourage you to look at these sorts of things, too. It's really not that hard. Like the whole proof of concept is 40 lines of Python and most of that is just, you know, the twisted connection handling stuff. It's very simple. You know, you could grab out a programming book and a Wireshark book and in a day be able to do this stuff. It's really, really simple. Okay. So I've got some thanks to these wonderful people here who either helped me set up my server, loaned me hardware, let me wipe their phones. Really good guys. You know, shout outs to the guys in the various IRC channels there. Yeah. Just want to say thanks to those guys. They helped a lot in my work in terms of, you know, providing the things that I needed, reviewing my poor writing, that sort of stuff. So if we could get some cheers for those guys, that would make me happy. Okay. So thank you for listening to me because you know, I've been a fan of DEF CON since I was like 12 and it's been a dream to speak here so I'm pretty happy right now. It's really, really good.