 My name is Brandon Dixon. I am a security engineer at G2, and you'll notice from the actual slide title that I named a carrier pigeon. This is a project that I started as a joke two years ago where I wanted to annoy a friend. And the carrier pigeon name is more of a, this is a delivery method, so to speak. It's not an actual exploit, it's not me packing headers, nothing like that, nothing adjusting the actual SMS message. It's using the SMS implementation as a vector to deliver malicious links, possible malicious code, spam, and things along those lines. So, two things I'm going to be talking about. One is abusing the short mail implementation that is offered by the carriers, and the second one is going to be bonding XMPP names with legacy instant messaging clients to actually reach out to phones. So, starting with the short mail, the second you have an account or some service with your mobile provider, your number is automatically associated with an email address. This email address automatically turns you into a victim. All you have to have is text messaging enabled. When somebody actually has your number and the carrier that you belong to, they can send a message to that number, that address, and the message will make it there without a problem. It's received as a text message, not as an email, so it shows up in your inbox. And cost equivalent is that it's standard to a regular text message. So, right away, one of the biggest problems with this is that it's enabled by default. The second you sign up for service, you have this enabled whether you know it or not. And one of the things I've noticed is that when you're filling out the application or whatever it is to actually get your service signed up, they don't sit there and tell you, they don't go, oh, by the way, we've enabled something by default. You may not necessarily want, but if somebody starts to abuse it, we're going to charge you for it. So, kind of attacking short mail, you have the conventional spamming techniques that are already out there today. You have the mass mailers, which, you know, email, you get flooded, you get in spam all the time. So, the only thing that spammers and mass mailers have to do is actually change the target list in which it gets inputted into these mass mailers. So, I'll get more on that later about actually creating those actual victim lists. So, another thing that spamming technique that you can use with this short mail attack is that you can actually spoof the source address. From some of the carriers that I have talked to, they don't actually concern themselves with the source because they're more concerned with the content. Which makes sense, but at the same time, an average user getting a message from, you know, president at the White House or, you know, whoever. It's, you know, if it does, if it looks real, then they're more than likely going to believe it. So, it adds another ability to actually do phishing and things along those lines. It's another attack vector. So, the carrier can be identified by services online. It's completely scriptable. And that kind of goes hand in hand with generating these victim lists in that you can actually go to several sites, these form-based sites, write a parser to go through the site, and input the actual user's number, and fairly accurately generate a list of all the victim numbers that you want and the respective carriers they're associated to. So, some of the limitations with this attack is anything past 160 characters may be dropped, and this depends on the carrier. I've noticed that some carriers will do the truncating for you, and they'll send the, you know, the 10, 15 messages based on the length of the actual email you send while all the ones just drop right past 160. So, the other part is the carrier must properly be identified for the message to go through, which is kind of common sense. If you're sending a message to a number that doesn't exist on that proper carrier, then it's not going to make it. And as the same way with SMS, there's no delivery confirmation, there's no reliable means of expecting that message to know that it made it through to the actual user itself. So, overall, why is this bad? In incoming text is a charge to a user. Whether they want it or not, it's owned by default. You can send the short mail from any client. So, like I said, it goes back to the standard spamming techniques and mass mailers, and that nothing changes for them. Nothing changes if you're, you got an ex-boyfriend, ex-girlfriend, whatever. Once they keep on sending you these messages, they can instantly do it right from their standard mail client. So, all of this, of course, is a problem because it's turned on by default, and most people don't even realize it. So, the carriers offer limited methods to stopping the attack by default. And what I mean by that is that the carriers give you the ability through some web interfaces to actually block 10 to 15 domains, block certain emails, block certain numbers. The problem with that is that, you know, I can generate a random email with a domain name of 30 characters that's random every single time, and it's going to make it through. And when I did my initial testing, all the messages were different, obviously because it's coming from a different source. So, you block 10 to 15 addresses. It doesn't matter because I can generate 10 to 15 in five seconds without a problem. So, that's some of the stuff they offer by default. And the other information is just not clear. I actually got to talk with some of the carriers, and they told me certain things. You know, yeah, we do have this available, but the information to actually find that, readily available to the user, was fairly difficult. It was kind of, you know, obfuscated within all the other things that they offer. So, some of the carrier capabilities that I did discover, and actually, in coordination with the DEF CON talk, they put me through Sprint, and Verizon, and some other carriers. And I was able to speak with them to see what protection measures they had in place, and they couldn't tell me everything about, you know, obviously about their infrastructure, but they could tell me enough that there was some protection for the user. So, obviously what I said before is that users can block certain domains, or completely shut the feature off, depending on the carrier. Throttling and rate-limbing are in place, actually at the carrier level, which is, it's not exactly clear how that's implemented, because they couldn't talk about their infrastructure. But, during my testing, I could see that messages would get queued up. Some of them would be dropped, depending on the rate that I sent them. Another carrier, a few carriers I've heard of, allow you to actually alias your short mail account, so that you're no longer exposing your number and your carrier, which is great, but that doesn't, it's not a feature that's available for all carriers. So, kind of the trend that I've noticed is that carriers implement some sort of protection, but it's not all the same. Some do it better than others, some offer this, some offer that, but it's never, you know, 100%. Next thing the issue, the feature should be easily adjusted by the user, and what I mean by that is it should just be turned off by default. There's no reason why that should be on right away, but part of actually turning that off is now the business end of it, in that it's been on for who knows how long people are used to it, and I've actually, you know, met people that legitimately used the service, and shutting that off now would just cause a lot of issues, forcing people to actually go back, turn it back on. It's just a, it's got to be analyzed from a business perspective, and they have to ensure that, you know, when they do this, or if they're going to do it, is it worth the actual, is it worth it to actually go and do it? So, one of the other things that I noticed given throughout the carriers was that more power should be given to block unwanted messages by default, and what I mean by that is that some of these carriers, like I said, 10 to 15, and that's it, and the rest of it, you actually have to go to the carrier, deal with them directly, and say, hey, I got a special case, you know, my wife is going crazy, she won't stop emailing me, you know, I can't, I keep on getting these messages, and it's, you know, where I keep on getting the spam, and you actually have to go with them and deal with it by dealing with the actual carriers as one off case. So, moving on to the next part of this, the XMPP and Jabber aspect of it, I kind of put a few things on here that kind of covers XMPP and Jabber that are of interest for wood, I'm going to be talking about next. The communications are done through XML, setting up your own server is extremely easy, there's multiple options for different platforms, allows for bonding to legacy chat implementations, and what's meant by legacy is that you're actually, things such as AOL, Yahoo, things along those lines that aren't using XML, they're considered legacy. So, you have control of the message flow, there's actually no rate limiting on your own server if you set up your own local XMPP server. So, right now there's this internet to mobile communications, there's Google talk, there's Yahoo, AIM, MSN in some areas. So, you can input a user's phone number, you know, as long as you know it, and they're now considered a contact within your list, you can send a message to them, it's going to make it to their phone, it's up to them whether or not they want to respond. So, messages get sent in the form of an SMS. So, what's new? Obviously this is nothing new. Google forces, you know, some of these implementations have been done correctly. Google for one forces a user to respond after a chat's initiated. If there's no response after a few messages, you have no more talk with that person until they respond later on. Yahoo also forces a user to respond after a chat is initiated, and they actually perform some throttling in place whereas Google doesn't. So, AOL on the other hand does not force a user to respond back once a chat is initiated, but they do do some throttling which is easily bypassed. So, moving on to abuse AOL, the rate limiting is imposed when sending message is too fast. You can go through their fat client and actually just pick somebody and just keep on sending messages, eventually it's going to tell you that, hey, you're sending too much too fast, stop. So, that's easily handled by putting a delay. You know, this can all be done programmatically. You put a delay in your program to actually slow it down a little bit so you're still sending your messages, but you're getting past their throttling and rate limiting. So, one of the interesting things I've noticed compared to short mail was that messages past 160 characters are split into multiple messages and not dropped. So, one message has a 2,000-byte max, and that's equivalent to 13 messages. So, going back to this rate limiting imposed, I can send one message and have it effectively turned into 13 messages on somebody's phone, which is great, because then I can send five messages. I still haven't hit the throttle yet, and they've just got a whole lot more messages. So, one of the things that I noticed quite recently, and like I said, I started this a long time ago, probably two years back, and it was nothing more than a joke, I've noticed that you must accept the actual user who is sending you a message when you're on your mobile device now. Before, from my testing, I could send messages to anybody and my messages would come right back up, but it appears that AOL has actually taken some steps to further and strengthen this by forcing you to now accept any person that is new within your mobile device. You have to accept communications with them. By default now, they send you messages like you can easily block this, you can do anything you want. They offer a lot more options, but the problem still remains that if you accept it, you're going to keep on getting messages from that person if they've already kept on sending them. So, as I mentioned before, abuse can be done programmatically, and now we move kind of into the XMPP and Jabber transports, which brings the XMPP and the legacy services together. So, a transport in itself is a bolt-on service for a Jabber server. There's transports for Yahoo, MSN, AOL, all different types. So, it shows up in the service directory for the hosted Jabber domain. Users can bond to these quote-unquote legacy services with their Jabber name to an AOL name. So, what happens is that they log in at their Jabber account and they can see all their AOL contacts to give an example. The user looks like AOL contact at MyJabber.com, where MyJabber.com is the actual XMPP server. And the AOL contact is somebody that you would actually be sending a message to on your contact list. So, the Jabber name can bond to multiple AOL names. Each must be in a different transport, and there are plenty of public transports available. So, one of the benefits that I had doing all this testing was that a lot of overseas, places in Europe and other countries openly have public transports available that you can connect to and bond your names to. So, when I was doing my testing, there was no way I was doing it from, you know, my local box. It was always from Brazil or Norway or the Czech Republic. And those, you know, they're getting hits all the time. So, more than likely they're not keeping logs. More than likely they don't care who goes on their server. So, it's just another way to obfuscate your traffic and another loop that you can push all your messages through. So now, kind of tying everything together. Phones and Jabber. You can have an internal Jabber server set up with an AEM transport service. This could be local or you could use, like I said, one of the public transports. You bond your Jabber account with your AOL account, and you send messages to the phone using your internal Jabber account or just whatever your public Jabber account. The connection bonding and authorization can be done programmatically. So, you don't actually have to have a fat client available to you. There are some messengers that actually do this. PSI is one of them. But I quickly realized that using a fat client just to bond my name was going to be pointless and it was better to actually go find out how to do this programmatically. So, the XMPP specs readily available. They tell you how to do it. They have the code there. All you have to do is send the messages to the right server. It consumes it. It does everything you need it to do. So now, moving on and abusing phones with all of this, you effectively generate a phone list. You have whatever number you want. When I was doing my initial testing I generated numbers for my local area codes for both the 443 and the 410 to have everybody's number, whether they were a cell phone or not, in that list. I then need to generate an AOL account list and you must own these. I'm sure there's plenty of ways out there to get those. You can read through the list and send one giant message per number. Effectively, I'm reading in each number and sending one message that may be equivalent to 13 messages. What that does is it bypasses the rate limiting because there is none on XMPP. I keep on going, scrolling through all my numbers. Then AOL is never going to push any throttling because I'm never sending more than five messages to the end user. When I did my testing between two XMPP services I was able to send 1,000 messages per second. Obviously there is the potential that you could overload some networks and whatnot, but that was putting no load on my server at all and messages went through without a problem. You can also send multiple messages to one number, but like I said you've got to add that delay in there to avoid any throttling on AOL's end. The limitations, obviously AOL is a single point of failure. The public transports, there's plenty of them out there that you can bond to. Rate limiting is a pain to deal with. The phone carriers seem to queue up messages. They have limited bandwidth on the channels. Some messages could be dropped in my experience that depending on how you send them they will be dropped in some cases. AOL provides support to combat against these spam and allows users to block these messages now. Why is this bad? You can send messages at a high rate of speed. Some transports have support for SOX proxies such as TOR, so you can push all your traffic and messaging through TOR and be completely anonymous. The public transports are often found in other countries with a large user base. It's good for hiding. All attacks can be done programmatically without interaction. Fixing the problem, AOL has done a pretty good job so far, but they kind of need to push their implementation a little bit better and force it so they kind of fall in along Yahoo and Google and that the user has to respond back before any chats can actually continue. Like I said, the protection has gotten better since I began testing. They had AOL's two servers, Oscar and Tok, and the Tok servers no longer appear to support the internet and mobile communications. I don't know why that was shut off, but coincidentally I noticed this when I was doing a month-long testing of a couple of friends. I don't know if I was attributed to that, but it's definitely shut off now to protect it every now and then. So bringing everything back full circle, why does this all matter? The user is at risk with limited ways to fight against the attack. It depends on the vendor. In this case it's the cell carriers and AOL. And the cellular networks are potentially at risk for targeted attacks that could affect their services. So I'm assuming the vendors are fixing things, and that's all that we're concerned about. And I hope that it can only get better and protect the user. So I know I have a demo marked down on here, and I think you guys are going to hate me, but unfortunately I've had having issues actually working the demo. So I can't explain what it was doing at one point in time before I broke it. The web application eliminated dependencies within the libraries. So all this was done on Linux using the Java and XMPP libraries. So one of the things I wanted to do with the web application was abstract all that. And basically have it so that any person anywhere could just do these attacks. So the web application itself could be easily made into a framework. It can be accessed anywhere. And the proof of concept that I had working allowed for bonding of the names, the XMPP names to the legacy services, sending messages through our choice of transports, which would be pulled down real time, sending spoof short mail messages, identifying public transports, and then obviously more could be added. So here's my contact information. Like I said, if you guys have any questions, feel free to grab me as I'm leaving or if you see me at the con. And that's it.