 Okay, so before we start, who doesn't know what voiceover IP is? Excellent. Anybody not know what fuzzing is? Excellent. Yes, I forgot to shave, thank you. Look at it. Fuck off. Okay, the mouse cursor is staying. All right, so we're gonna start off with a bit of background info on voiceover IP, previous research into voiceover IP security. Then I'm gonna do an introduction to Viper, description of some of its features, couple of demos, assuming I could actually see with the screen resolution. Some results, then Q&A. All right, so about me, from Ireland, just finished a Bachelor of Science, Bachelor of Masters, and that's my site, if you wanna check it out. Okay, so I'm pretty sure everybody knows this, but just to make sure we're all kinda on the same playing field, voiceover IP, rooting voice data over the IP network, pretty obvious. You can use it in tandem with a traditional phone network, or you can just use voiceover IP on its own. There's a lot of companies that we're all familiar with involved in this, so Cisco, Nortel, Lavaia, and a lot of smaller ones. And there's loads of different devices involved, you've Proxies, Registars, Gateways, phones, loads of crap. Okay, so voiceover IP is getting more and more popular apparently, according to Computer Economics, is there to be believed. About 50% of large businesses are using it in some form in 2008, so it's becoming a much more popular target. So voice is so popular, pretty obvious. Apparently, you can get a 20% reduction in costs after you've paid for all the devices and crack. You get location independence, and you get a bit of independence from the telcos as well. Okay, so the protocol is involved. There's a lot of them, basically. The reason I'm just showing this is because really automated testing with all these protocols, you know, you don't want to be getting, like say if you've all these protocols and then you've all these devices that implement all these protocols, manually ordering them, not fun. Okay, so VoIPer, I concentrated on SIP and SDP to begin with, and then moved into IAX and H.2323. So just to make sure we're all in kind of the same level here, SIP sponsored by the ITF, it's an open standard. It looks a little bit like HTTP, kind of. It's human readable, and SIP itself is used for command control, so basically initializing the session and then other protocols take care of handling data transfer and that kind of stuff. SDP is carried as a content inside of SIP. It's used for negotiating the codecs for audio, video, and it's been extended for fax over IP. Again, it's human readable, and in combination with SIP, you know, you can use both of these for a lot of stuff, not just voice over IP, it's been used for instant messaging and a few more different things. Okay, so this is what a typical SIP SDP request looks like. Human readable, as I said, so the top part there is the SIP part, and after the line break, it's the SDP part. Okay, so then just H.233 quickly. It's ITU sponsored. It's pretty much the dominant protocol in backbone voice networks, and kind of large influence environments like, say, call centers, that kind of stuff. It's an umbrella recommendation, basically, so it includes lots of other specifications for everything from security to registration, admission status, that kind of stuff. So unlike SIP, H.233 can specify an entire voice over IP deployment. Okay, so voice over IP, really, it really is a good thing for hackers. I mean, it's taking your voice network and you're moving it into environment where we have all the tools that we've been using for years. It's the same transport protocols like TCP IP, same environments. The standards are much easier to get a hold of than, say, most other telephony standards. And the devices themselves, like you can just go and download a lot of the more popular voice over IP devices or trials and that kind of stuff. You can test them. And most of the stuff I found in the trial software is in the regular, say, professional software as well. So thanks for that. So this is something that I kind of came across at the start when I started the testing. A lot of people are kind of just saying, okay, so what can you really do with a voice over IP phone? Maybe you're gonna be able to knock it over. That's maybe it. But these devices, they're running really complex operating systems. They have full TCP IP stacks. They're running web servers, TF2VD clients, loads of cool stuff that really, if you had a standard phone sitting on your desk, you're not really gonna have to worry about it. So a few possible kind of attack scenarios. So kind of the standard stuff. Those targeted C-level attacks or whatever is something that some Russian group were doing a while ago with basically just getting addresses, contact details of high-level people and then specifically targeting them, kind of like spearfishing basically. Or if you get sales people ringing you and they're like, yeah, I'll call you back, then just knock over their phone. So there's two kind of, I suppose this is one way, looking at two possible viewpoints and looking at a previous voice over IP security research. Attacking the kind of the design of it. So the authentication, authorization, encryption, that kind of stuff. And there's been a load of research done in that for quite some time. And then attacking the protocol implementation, like the actual device themselves. So you're going for code execution or denial of service if you can't get that. And there's been a good bit of research in that area as well. So attacking the design pretty much, it's almost identical in terms of methodology to every other kind of TCP, IP protocol attacking that. So you have enumeration, scanning, cracking accounts, man the middle attacks. And the threats are pretty, they're easy enough to manage in the same way as anything else. So you can do this with pretty much any tools. So you can use like Nmap, just scan for open SIP ports, HGT2 3 ports, anything like that. Then just write a, you know, you can use tools like SIPvicious then to crack accounts. Like that is really, really good. You can like scan like 50 or 70 accounts a second or something. You can also map the networks. You've got Voice Hopper then, which is pretty cool. It's for say, some hotels and things like that. They'll use a VLAN to segregate, say their phones from their data network. And that's a really great idea. And Voice Hopper takes care of that, or VoIPop even. So then attacking the implementation is pretty much what VoIPer is about. So it's basically, it's fuzzing the devices, but attempting to do it in like a completely automated way. So the point of VoIPer basically is, you know, you start it and you go away and you come back and you've a list of bugs and it can reproduce them for you. So there's a couple of tools that have done stuff like this. So Protos, their SIP suite was probably the first one. It pretty much, it just tested the invite request, but it was really good. It pretty much killed everything when it came out. But nowadays, it's kind of, it's kind of old. It also does kind of pretty rudimentary crash detection. So after every request, it sends a valid request. If it doesn't get it the response it expects, it tells you it died. Okay, KIF is something from a research group in France, I think, and they've posted loads and loads and loads of vulnerabilities to a bug track. And until a couple of months ago, it wasn't available, but now it is. If you send them an email and then they send you a contract and then you print the contract and sign the contract and post back the contract and then they don't send you the software. So that's fun. And then Interstate was presented last year. What that does, instead of fuzzing like headers like you normally would, it fuzzes, so the state of the protocol. So it tries to put the device into a known state and then it sends kind of unexpected, but valid request to try and knock it into invalid state. The guys from KIF did something like that and they actually, they were able to put a phone into a state where they'd send a request, but then they'd send another one straight after it. And instead of the phone ringing, it'd go into basically an eavesdropping mode and it'd start listening in the room without ever ringing. So that was kind of cool. And then you've got code, Nomecon, MewDynamics and that kind of stuff. And those, their tools are really good, but they're really expensive as well. So all of these, they're pretty much, they're pretty successful at finding bugs and voice over repeat implementations, but there's a few drawbacks to all of them. And those are them, it's pretty much either they're difficult to acquire or they're expensive. So things like Protos are quite hard to extend because you don't really, you don't get a fuzzer, you get a collection of tests basically. And then the thing I really wanted to concentrate on, VoIPer was I really wanted full automation. I didn't want to have to sit there and wait for it to crash and then restart the device and then wait for it to crash because some of these devices are like, you'll see the results. So VoIPer basically, just a quick overview of VoIPer's cross-platform. At the moment, there's like 10 different fuzzers for SIP and SDP in it. I've extended it to cover IAX as well, but I haven't released that because it's not quite stable. And I'm hoping to work in a few more protocols. Okay, there is, on top of the fuzzers, then you've, there's a lot of logging kind of target management, crash recreation. And the name of the game really is full automation. So the fuzzers themselves, there's about 10 of them and that number's an underestimate there. There's probably, there's maybe 50,000 requests in each fuzzer. And it's kind of a case of all the knowledge is kind of encapsulated in the fuzzer. So you just basically run the command line tool or the GUI client, start it up and then go away. The IU Sully as a fuzzing framework behind it, so that's really cool. It provides kind of like debuggers and crash detection and that kind of stuff. And it does provide obviously enough a way to get your fuzzer quest from your fuzzer as far as the target. But really for what I wanted, I wanted kind of to be able to interact with the client and the servers in kind of a, say a stateful protocol aware way. So I ended up basically writing a pretty rudimentary SIP core kind of SIP client to deliver the requests. The fuzzers they pretty much look like what you expect from Spike or Sully or that kind of thing. So that's an example of one there, the content length. That example header there causes a professional level of business grade, really grateful to crash. So the SIP core itself then is just basically it's a SIP library. What it does is, here there's this kind of a standard kind of SIP interaction. You're sending an invite, then you're sending, you're waiting for a response, then you decide you don't want to call them anymore. So you send a cancel, you wait for those responses and then an act is sent. Protos can fuzz the first invite. So can many other tools, but with Viper basically you can fuzz the first invite and then you can map out the protocol in such a way that you know that when a 180 ring arrives you'd send a cancel, then you wait for those two responses and then you fuzz the act. So you can fuzz theoretically the whole state space of SIP. And I thought that was a really good idea at first but it's not and it took a long time. So this is what kind of the protocol mapping would look like. It's kind of a bit cryptic at first but once you kind of get a hang of it it's pretty easy to define any kind of tests really. So you're sending a valid invite, then you're waiting for a 1XX response, sending a valid cancel, waiting for a 2XX response which you just ignore and then when you get a 4XX response you fuzz the act. And you can do this to define kind of pretty much any type of interaction you want. You could send like 10 correct invites and then say a few acts if you wanted to fuzz the state of the protocol kind of like interstate or KIV. So the crash detection, this is really important for if you want full automation. Like fuzzing when it first came around everyone was like hey automated crashes and that kind of stuff. That isn't really very good if you know you cause one crash right at the start and then you can't automatically restart the target. So there's two types provided. Protocol based crash detection basically what that does is similar to Proto so it sends your fuzz request and after every fuzz request it sends something that should elicit a response. And if it doesn't then it's probably crashed. Or sorry that's protocol based. And then process based is basically using the using what comes with Sully and some stuff I wrote to you attach to the process and then when an exception is detected you obviously report that it's crashed. That's a lot more reliable than protocol based but it only works if a debugger script has been worked or written for the system you're running the client on. So at the moment there is support for Windows and Linux and OSX. But if you're testing like a hard phone you're gonna have to stick with protocol based for the time being. And with that you get pretty detailed reporting of the crashes. So Sully uses a Pi DVD G to attach so you get like all the registers at the time. You get a kind of some areas on the stack that might be interesting, that kind of stuff reported. Target management is basically taking the output from the crash detection. And once that crash has been detected it reports it logs it and then it restarts the device. Basically this allows you to as we were saying you start the fuzzer, you go away, you don't have to interact with it anymore. You come back to a list of files that caused a crash, a list of reports and you can work from there. This is really useful first. A lot of the open source SIP clients they've got a lot of denial of service problems so they'll fall over a lot. But it's not particularly interesting so kind of null pointer dereferences that are kind of tricky to do anything with and that kind of stuff. And as I said for this you need a script running on a target device so if you're running a hard phone or you're testing a hard phone then this isn't gonna be possible. And crash recreation, this is basically once the crash has been detected enough information is logged about that crash that you can come along afterwards and recreate and there's a script provided that'll say take any file that caused a crash and turn it into kind of a standalone proof concept. So that's pretty handy. Okay demo time. So this, what's it? This works? Yes it does. Okay this is kind of a, it's a software PBX basically. You shouldn't make note of the company we'll come across them again in a few minutes. It's made by a company called NCH. They make really good software. So basically this is the process monitor. You just specify say a crash file, the process to attach to and this time out is if a crash occurs it'll wait that amount of time for telling the fuzzer you can keep fuzzing because a lot of these devices they can take like 10, 15 seconds before they're in a state to be tested again. So you start that. Jesus. Can you never see that? Horror specifying here is those are all the fuzzers that are available in the current version. There's a GUI for Windows that's probably gonna crash and burn. Yeah I wouldn't recommend using this on anything that isn't Windows. I suck at GUI coding. Okay so on the command line you just specify the dash i is the target, dash p is the port. There's three levels of crash detection so level three is basically it uses the process-based script to attach. Then this is the path to the target we're testing so that'll be used to restart it and then this is where we're gonna store any crash information. So start that. Jump over here. Killed that. Okay so it's found it. Okay that was quick. So as you can see crash was detected straight away there and that would give it 10 seconds to restart the, it's gone way up in the corner and it's crashed again. So as you can see if you don't really have automated crash detection and restarting here you can be sitting there for quite some time you know clicking stuff and restarting stuff and generally cursing and shouting. Is it going to go again? Oh it's gone again. So yeah let's just shut that up. As you can see back here you just get some output on what happened. And then in this directory we get all the crash log files. Basically you can use this crash replay tool then to just replay those and narrow down the causes of crash and that kind of stuff. This is basically what's in those files. So you can see here this rather wonderful device takes our word for the content length, which is nice. Okay and that's pretty much it. So during the testing I focused on clients because I figured servers or SIP servers especially like asterisks and that were pretty much tested to death and I hadn't really seen much done on kind of the more popular clients. So Akigas pretty much installed on a lot of Ubuntu and Debian desktops. Gizmo 5 was pretty popular. And then Twinkly basically took because it uses kind of an interesting way to parse the crests. And then I took the bottom one because it was pretty much the first thing you get when you Google for Windows or the SIP business phone or something. So these are the results of the testing. These crashes basically are organized say by the number of crashes and then each bar is broken down into the actual fuzzer that calls the crash. When I actually ran these tests I only had the five fuzzers. But the interesting thing about this is that the variation in the crashes in terms of the fuzzer is very small. So as you can see the purple and the blue make up the vast majority of the crashes. And when I started out writing VoIPer I thought okay to find the crashes I'm gonna have to test the most obscure features. So I sat down and went through the whole RFC and I took out like this 40 something different lines and I thought okay these are gonna be the ones they're gonna find the crashes. And it turns out pretty much either they're not implemented or they're implemented to such a level that they could never actually cause any serious damage because they basically just say I'm not here. So all the crashes were from the really common kind of SIP headers or the vast majority of them were anyway. So you might notice that one client is missing from there. That's the NCH business talk. And there it is in all this glory. They crashed several hundred times, which was nice. Oh and they don't respond to emails when you tell them that kind of stuff. And neither did the gizmo guys, they just closed your ticket. But a key and twinkle are really good. So what time is it? Anyone? 21 past? I talked too fast. So the testing conclusions, basically everything crashed, everything I came across crashed. Every single device had a crash net that could be caused by a single packet. So basically the user doesn't even need to answer the phone. They can just, as long as the phone's enabled then it can be crashed or you can get code execution. The vast majority of the bugs were no pointer to references, but everything except for twinkle had memory corruption, exploitable memory corruption issues. And yeah, NCH, don't use them for anything. Don't go near them. Just stay away, bad, bad, bad. So, coming to the end of development of VoIPR, I'd realize I'd spent many, many hours on it. And the reason for that really is because I decided to write a generational fuzzer, which means you map out the whole protocol in something similar to like spike or solid or peach or something like that. And it takes really, like it takes absolute ages to do that, especially if you wanted to do to the level I did. So kind of, I wonder how many of the bugs I found I would have actually found if I'd just gone with a mutational fuzzer. I did kind of some quick testing. I wrote a quick mutational fuzzer for IAX2 and it crashed live IAX in about 23 seconds or something. So maybe I won't go down the route of a generational fuzzer for that. And I also thought that I'd cover the whole RFC because I figured if I wanna find some bugs, I'm gonna have to find a part of the protocol that hasn't been tested before. And really, that's what took the most amount of time and it returned virtually no bugs at all and for the obscure cases and the coroner cases. So the vast majority of classes or crashes even were in the common field. So the good, really, once you start the Viper, unless there's something really weird going on, you can just start it and go away and come back to a list of crashes. And it works with any SIP, SDP-compliant device. You just start it up and bugger off. I gave it to a guy who works for a company that I can't name and he basically, he started up against their internal stuff, came back to, I don't know, 20, 30 different crashes. He didn't need to know how it worked. He didn't need to know how SIP or SDP worked around that, so that's pretty cool. And it's all open source as well, so anybody can basically take and do what they want with it. The version that's on Sourceforge at the moment is kind of old and I was gonna upload the new version this week, but I'm afraid of the network. Okay, so the first guy there, he took it and he basically tested it to death on load of bugs. Anybody else I wanna thank who helped out with the beta testing, there's a lot of people and then those two networks there, those guys there that donated a lot of stuff and like time and hardware and that kind of stuff. So that's pretty much the end of it. I kind of rushed through it, so I'm sorry about that. But those links there, the first one's my side. The second one is a wiki for this, so there's a lot of tutorials and there's a video demo and that kind of stuff there. And the bottom one, you can actually go and get the code. It should be up, I'm not home for another week, so give it a week and the new version will be up. So, questions. So the question is, have I tested against any of the simple implementations? No, there's the answer to that. I would, or sorry, okay, the question, have I any plans to support Cisco Skinny? Is that it? I would if someone would give me the hardware to play with. So if anybody wants to give me the hardware to play with, then I will. Ah, thanks. So the question is, have I tested against any border control type things? No. I haven't, but the first guy I tanked there has, and he said he found problems in some implementations. I can't give the names of the companies, obviously. But, I think it was. Skype wouldn't really be a bundle of fun to try and test because I'll say it's the protocol itself that's encrypted. I think somebody did talk at Black Hat two years ago about that, and that's a world of pain I don't really want to get into. No, I didn't, I wasn't aware of that. Nope. Okay, I think that's it. Thanks very much, guys.