 Okay, I'm Abel LaTrope. For those of you who don't know me, I'm a security consultant with ISAC Partners and you are here for exercise in messaging and presence ponage. I apologize for shutting off with a pun, but you do what you have to do. So I'm gonna go through a few different things here, starting off with just kind of the basics of XMPP if anyone's not familiar with it. Go over a tool that I developed for the kind of manual portions, just sussing things out. Anybody who's familiar with WebScarab or Burp will kind of know the drill. Then go over a few of the kind of more tempting extensions to mess with in XMPP and then a couple of the better ways to do that. So for anyone who is not familiar with it, it used to be the Jabber project which often times is what people remember it as still. It's mostly used for IM although they're trying to expand it out into a kind of ridiculously broad range of things. I guess they're doing voice over IP stuff via jingle, bunch of other things. So the main reason that I chose it, it's everywhere. Most people's work chats go over XMPP at this point. And as usual when you've got decision making via committee, it's an open standard. Things tend to go in somewhat conflicting directions and then you have all of the additional problems introduced by the choices people make in the way that they implement it later. So as you'll see once I get into more of the details, there are hypothetical solutions to a lot of these problems already being recommended but they're just not being implemented because some of them are too complicated and sometimes people just get a little lazy or want to do a very low overhead client and just don't put it in. So the basics of how it works, it's decentralized. You don't have one almighty server the way you would with AIM or something. The usual format username, that's server name. It's really, really widely used according to the source that may or may not have been Wikipedia 10 million people. I have no idea how I can get that is. The requests for comments are just huge. I mean, it's incredibly large. You've got maybe several hundred at this point and some of them run into like small books. So anyway, it runs with TLS for encryption and SASL for authentication. Yeah, sorry, I just skipped down for the next one of my notes. So I'm gonna back up. We'll just do that over. The less diligent server certification is you're only as safe as that is completely lost my place now. So go with the third bullet. HTTP binding and this one's kind of fun because all of the kind of web inline clients that use Jabber use this. So you'll have kind of an HTTP wrapper with an GUI XMPP center and I'll kind of have more fun with that later. And then the most common thing you see is an XML stream where it's initiating a connection and then you just have kind of this ongoing document that's getting added to you as you go along. So there are a few different types of stanzas but all of them have these attributes in common. Obviously the two in from are pretty self-explanatory. JID stands for Jabber ID. You get a lot of legacies in the name since the switchover is pretty recent. There's an ID which is optional depending on stanza type, some things require it. And scope of uniqueness is flexible on that. Sometimes it's only unique to a server. Sometimes you want it to be a little more global than that. The type is just for specifying the purpose of the stanza. So you end up with get set, all the usual stuff. XML language is basically a relevant for security standpoint. It only affects the way it displays. So the first type which I won't deal with too much is just the info query. You see a lot of these in the beginning when you're setting up the connection and then tends to be kind of keep alive sort of stuff but there's not a ton that was super interesting here. Presence is one that ends up being fun because this is just a huge volume of the messages that you see in the traffic. Many receiving updates from one. It ends up being, you know, every time someone logs on or off a group chat it sends out to everyone else logged in. So you see just a ton of this when you're looking at the dumps. Message is exactly what you think it is. You know, it's the user traffic. You're saying hi to your buddy and it's going out this way. So on to the proxy that I put together for kind of looking at these things. If any of you are a blackhead and some of my coworker Rachel Engels talk it basically extends the product that she had put together which is just kind of a really lightweight version of a web scare burp type of thing, you know, just it was designed for kind of speed, very low feature set, not a lot to mess up basically. So I kept the HTTP functionality for that and just kind of tacked on, you know, the ability to do very similar things but with XNPP data instead. So I also added the ability to do, you know, multiple concurrent listeners. You're not just tied to, you know, local host 8080 and you aren't stuck with the same thing over the course of the session. It's got the basic, you're just a transparent proxy watching what's going by and also the kind of intercept, twiddle forward thing. So yeah, all around it should be very familiar for anyone who's used general attack proxies before just Brex MPV. So this is kind of a look at the listeners tab. You have the option of creating whatever you want. Couple of improvements that I want to make because currently you have to kind of reset all of those fields and then hit start top twice and this kind of offends me on a minimalism level. The pass through mode, you've just got blob the text scrolling by. I realized that I probably want to add timestamps at like 10 a.m. this morning. So clearly didn't have time to do that but we'll be doing that before I toss it up on our servers. Intercept mode, again, you know, just very simple, very clean. The thing you see in the upper left hand corner, I haven't actually implemented for XNPP yet. We've got kind of this interesting thing that you may have heard if you went to our talk where you can send the commands to external shells and you know, manipulate them further if you want kind of a good tie in for making this the basis for a fuzzer. And basically, you know, just modify it however you want. Hit the send button. It passes it on to either the client or the server depending which you're currently trying to manually fuzz. So I mentioned a couple of things that I kind of wanted to change before this goes up. Also want to add replay functionalities so that you can just, you know, send the same command. Also wanted to be able to have, you know, because we got the concurrent listeners going, it seemed like an obvious thing to be able to take a packet that was destined for one of those listeners and instead send it to the other so that you can kind of, you know, get some more fun in that way. I also want to have a more legible detail view because as anyone who's tried to read XML just, you know, without any of the invitation would know. It's kind of a pain and generally end up, you know, copying it out and putting it into some other word processor to get that. And then obviously the wrapped XMTP handling that I was talking about earlier currently, you know, it's HTTP or XMTP view so you will see it in the HTTP tab but it's not as, you know, elegant as it could be in terms of actually being able to get in there and manipulate it a little more easily so. So as I accidentally mentioned earlier when I got a little ahead of myself, the protocol extensions are specified kind of by community. You know, anyone can submit it. It does the usual, you know, IATF style thing where it goes through draft and experimental and whatever and, you know, gradually just gets kind of hazed by virtue of people implanting it. There's a core set of protocols but it's really grown like crazy from there. I feel like I barely scratched the surface in going through these. I just picked some of the more obvious ones because it's just huge. I mean, it's an enormous volume of information. So I kind of picked out a few select highlights, things that, you know, left out at me as being honestly really to the easy to cause trouble with in addition to being, you know, fun. So the interesting thing too is that you'll find kind of a random assortment of things implemented. Like a lot of the ones marked experimental, you'll still find fairly popular products. So, I mean, just because it's not marked finished, you'll still find it all over the place in the wild. So, the first one that I wanted to take a look at was PubSub, obviously, given that I had my eye on DOS. This was kind of the obvious first choice. They just, yeah, this is another one where it's kind of run away. You have to focus on the main obvious use and just chat because they want to use it for everything. Basic idea, you know, it's kind of an observer slash push system. You've got one publisher pushing to many observers. It's broadcast to users. So this gets used for things like, you know, my friend updated their blog entry so I'm being notified in my feed. So the leaf nodes it's mentioning here on the bottom line, those are basically nodes that only contain published items. So you've got the parent, which is the publisher, and then the leaf, which is the publisher. So the fun thing about the publishers in this situation is that they have more or less complete control over the nodes. So pushing to subscribers really doesn't require that much of their participation. The interesting thing here is that, you know, again, they have a specification that would give users the ability to block PubSub nodes, but no one uses it. That would be, you know, XEP 16, if anyone's following along at home. And, you know, I didn't find a single product that actually lets you do this. I think the problem is just that it's really, it's way over complicated. You know, it's this big privacy lists thing where you have to go in and maintain who is on it. And, you know, you can block by JID but also subscribe state and you can block specific types of stanzas. And it would all around just be really intimidating for a non-technical user. So what you see people do much more often is 191, which is great if you want to block a specific user but doesn't help you out when it's PubSub nodes that are the problem. So this is what most of the web applications that do kind of a little inline chat applet use. Some kind of take additional precautions but basically the only security mechanism that's mandated is this little request ID. And, you know, as usual, it's supposed to be non-sequential but it's generated by the client. And, you know, again, anyone who's met developers, if you have a random ID, half of them won't know that it's supposed to be used for a security purpose and so it will end up being implemented in a sequential fashion. The other interesting thing, which I kind of noticed the last minute, was that they recommend you not to use the regular authentication. They recommend you use HTTP off. So then you kind of get into exposure to all the usual web app phones. And then multi-user chat was another obviously fun one. It basically wants to be IRC. So, you know, you've got the usual kick-ban mods admins. And then here again, you've got kind of, I wouldn't say godlike powers assigned to the parent nodes but they can mess with you more or less, it will. So, anyone here, raise your hand if you've done a Google Vanity search? Anyone? Okay, I think most of you are lying. And the upshot is I had done one to see what people were saying about the talk and had happened to come across this, which entertained me, so there you go. So, the DOS protections that they recommend are really, I wouldn't say insufficient but they're kind of low tech. It's more relying on human intervention on the part of the admins than actually in having it be resilient in the first place. So, here's where the presence traffic really becomes fun because there's just so much of it. I mean, you're picking at a fairly high rate and so if you have a reasonable number of people involved in a multi-user chat or something, it's just, it's a ridiculous volume of traffic. And there are just kind of scalability issues, partly pertaining to that in general. Some of the ways that they recommend that you, actually most of the ways they recommend that you mitigate it are not implemented widely. Limit connect attempts by IP or JID. I was just sitting there, connect, connect, connect and you can do it for an hour and they won't even notice on a number of different clients for most of them. So, kind of ditto with unauthenticated connections being denied for whatever reason, a lot of, like even Google Talk will let you log in over HTTP if you're really so inclined. So, the only real defense you have against spam instant message spam is to restrict access to the pub sub and multi-user chat functionality which kind of defeats the point of using XMPP in the first place. I mean, you wanna be able to do those group chats, you know, particularly in an office situation where you've got a lot of people trying to collaborate. If you can't have access to that, you're not really getting the full use out of your internal chat. The other things they recommend are, you know, stand to size limitations and things like that and, you know, again just don't really see it implemented in the wild very often. And then another problem there is just parser errors are indistinguishable from Pigeon just having a bad day frequently. I noticed maybe half the time I'd actually see a little XML error that mostly it would just, you know, spit back out the connection. And half the time, you know, I have these problems when I'm not fuzzing with Pigeon. So, it's really, there's not that same level of user interface acknowledgement that you would get in web browsers yet. They just haven't really caught up to doing, and, you know, obviously not getting the whole controversy on whether that little secure thing in the header actually helps or not. But you really just don't have equivalence for chat clients yet. So, if you have a parser error, then it's just gonna choke and it may tell you that you had an XML error or it may just mysteriously refuse to connect. So, the aforementioned problems tend to make amplification attacks pretty likely. Obvious targets being multi-user chat and PubSub. Again, you know, they just skip straight to admins can block specific JIDs only if you have any kind of coordination. Blocking specific JIDs is not going to be a fast solution. It's not gonna be an effective solution. And if you're talking about, you know, a large companies, say, internal chat, then it's gonna be a significant business impact with really not that much of a way to mitigate it. So, in the XML parsing, they've done a good job on some of the more common types of attacks like entity expansion. I was trying to find a way to do that and didn't go up with one. But in terms of some of the stanza-specific requirements, you can make it choke in entertaining ways a lot of the time. One of the issues that I encountered early on kind of by chance, actually, as I was kicking this off, a coworker had dumped, I think it was spew from a malfunctioning ethernet adapter into our common chat room, which turns out kicked everyone who had a live purple-based chat client off. Unfortunately for me, that was a known issue, but still unfixed. So a lot of these DOS issues kind of blend into the XML parsing issues. Just if you have any kind of malformed XML, the solution is usually disconnect. So, here again, the chat logs kind of from the horse's mouth. I feel like, as I was mentioning, depending on I barely scratched the surface on this, there's so much more to go into in the XCPs just, and constantly adding new material. So, these are the resources that I kind of found most useful in putting it together, and hopefully I will be able to get the proxy up on our website relatively soon. You can either look for it there or contact me at my personally mail address up there if for some reason it doesn't end up making it up soon. So, questions? All right, thank you.