
all right how's everybody doing I'm Anthony I'm going to be talking a little bit about uh voice over IP and our implementation in the 2015 information security Talent search at RIT uh when I built this presentation I really wanted to make it appealing to a wide range of audiences so I'm going to do a little bit of a an intro to void talk about our competition talk about how we integrated VoIP into the into the competition how that turned out for us and then try and bring it around back for all the Security Professionals here about how we can kind of apply what we did to to the real world so real quick about me I graduated from the Rochester
Institute of Technology in 2014 this past may I was responsible for Designing deploying The Voice infrastructure that we had at ists is here I'm an asterisk and VOIP guy in my free time and in my my uh my real job I'm a network operation specialist at Harris Corporation previous experience at uh working the network operations at Wegmans anybody know what Wegmans is oh that makes me sad it's uh grocery chain up north uh it's the best grocery store in the world and I know that sounds ridiculous but there's two types of people people who know that Wegmans is the best in people who are wrong so if you're ever up north be sure to stop in
and then I've also worked for Meraki now owned by Cisco their Cloud networking group so um I'll get started here real quick talk about the competition for people who don't have any experience with security competitions at all and even if you do maybe a little bit of a refresher so the information security Talent search is an annual competition we have every year at RIT this was our 12th competition and there's three teams pretty much what you'd expect out of a security competition red red white and blue I was on the white team the infrastructure guys the people who build and operate the competition this year on our red team we had a pretty good lineup
of professional penetration testers we had Security Experts from box Mandy and FireEye Raphael Mudge the guy who created Armitage and Cobalt strike is a yearly member of the security team or of the red team and then your blue teams or your competitors your student teams who were actually given an I.T infrastructure to defend what makes ists unique and what we try to integrate into our voice infrastructure is that blue teams are allowed to attack each other so anybody here done CCDC um so with CCDC you're defending against a red team but in but it's a complete free-for-all on ists which allows us to do uh some really fun things so if you don't have any experience with
um a security competition you're basically given an I.T infrastructure that you're tasked to defend a lot of common Services uh email HTTP DNS all that all that stuff and then while you're defending it you have to keep your services off to score to score points so that they continue scoring and then you're also given injects things like implement syslog or Webmail or or Implement https if you're just given an HTTP setup and then those will score those will earn you points and then on top of that you have more offensive challenges in ists because I said blue teams can attack each other so things like own another team's box and set up a Minecraft server or own another team's
box and Patch it for them or we had some really good crypto challenges this year um and and things like that so all these things and then whoever has the most points at the end of the end of the weekend comes out at the top so where exactly do we fit in voice and voice over IP into that when we're kind of approaching it this year well last year we did VoIP is kind of a last minute thing um and this year we kind of decided that we wanted to start out right and build something that that really looked good and it worked good so we fit in voice because it really is anybody who works
in Enterprise I.T one of the most important services that your it department is going to deliver voice and email either one goes down people are screaming and it's also typically not a very well understood service in a medium-sized business it's very common for assist admin to be told well you're good with the computer system here's this voice system it's been running for 30 years go for it and then it breaks and you see a post on our sysadmin saying well I've had this voice system I have no idea how it works it's been running for 30 years what do I do now and typically the answer is well you know cry and then you get the same thing with
implementing voice over IP um it's typically not a well understood thing so we kind of wanted to approach that in the competition because it's probably not something a lot of students have seen in other competitions and you have a lot of vulnerability both in void protocols by fall and especially in voice configurations which I'll be talking about further so this is the fake topology that was handed to the teams a couple of weeks beforehand I'm not going to spend a lot of time on this because this is the fake topology and they had to discover the real topology I didn't have any drawings of the real topology but it's largely similar to this but there wasn't
actually a software to find radio in there we had a couple of teams freaking out the night before who thought there was so um with kind of the competition Basics out of the way I want to talk a little bit about voice over IP and give an introduction for anybody who maybe doesn't have any any voice experience so whenever you discuss a VoIP architecture you're looking at two protocols from a protocol standpoint you're signaling and your transport signaling will handle call setup teardown routing in most cases digit passing although occasionally that is rarely these days done in the transport protocol and the two big players in signaling are h.323 and sip with a movement very strongly
right now towards sip because it's a very easy protocol to understand it's HTTP like it's text-based easy to recognize if you're looking at Wireshark h-323 is absolutely miserable to look at in a packet capture they're pretty much took the ISDN protocols and stuffed them all into a packet so you have like 400 headers and it's it's a mess and then your transport protocol carries actual encoded audio or video data RTP is the king of Transport these days and it'll usually use a particular it will always use a particular codec g711 mu law commonly called you law being one of the most common with others existing and transport travels on high numbered UDP ports its sister protocol the
real-time transport control protocol rtcp will do call statistics collection things like Jitter delay all of that you'll also see uh skinny skinny client control protocol and media Gateway control protocol is signaling protocols in Cisco in Cisco land commonly but um and really a big move towards sip these days in that realm so this is an extremely simple example of what you might see in a voice architecture you have your two phones which will signal with your call server to do things like registration authenticating to the to The Voice network and then when they want to place a call they'll signal through your call server and then the call server will set up the call and the
call server will step out of the call commonly and allow media to flow directly between the two endpoints now like I said this is very simple every architecture is going to be very is going to be different some companies interested in doing call recording may have their voice servers proxy all of the media so they can record calls you may have a statistics collection server in there you may have totally separate server just for registration and authentication but this will work kind of for purposes of people who don't have any any voice experience at all they give you an overall idea and this is largely what blue team's architecture looks like in the competition so we talk
about vulnerabilities protocol wise in VoIP the lack of strong authentication and the fact that these Protocols are playing text are really the biggest ones it's very easy to enumerate sip extensions to obviously excuse me sniff traffic if it's plain text you can or dial you can do things like that pretty easily um and then for RTP for your media streams if you're able to capture an art and an unencrypted RTP stream you can just reconstruct entire voice calls you can also inject packets to inject false audio into a call again by the nature of the fact that these are weekly authenticated or in the case of RTP no authentication by default or unencrypted and then specifically an area we focus
on a lot in the ists is the fact that configuration is challenging um in a lot of vendor TurnKey Solutions when you say okay we're going to do Cisco voice we're going to do a via voice or something security is a check box is really big so you'll check the box that says secure calling or whatever and you know do some minimal configuration follow the vendor's guide and it all works but we really kind of see a move toward things like wanting to you know buy solutions that aren't just made by one vendor so maybe we like a particular soft phone on the computer better than we like the vendor solution and so that creates challenges and
configuration for administrators [Music] um and then one of the biggest areas we focused on in ists was vulnerabilities in configuration of voice services and we did this ridiculously we did some really crazy vulnerabilities in the dial plans but you know in real life some of the most common things I see are um conference Bridges and voicemail being weekly secured using you know some arbitrary you know using the phone extension and the phone extension as the password for voicemail and if you have features on your voicemail occasionally you can use that an attacker can use that as a pivot point so they can get into your voicemail and pivot outwards and make international calls extremely especially the conference bridge is
extremely common attack Vector because they'll set up a conference bridge at some extension it's publicly available because it's designed to be a conference bridge and you know the password will be one two three four with no lockout because management will get angry if they type it in wrong three times and now they're locked out so a very common thing so we kind of focused on this a little bit in ists in terms of the the way configurations of voice systems can be vulnerable now for actually securing voice um conceptually it's pretty straightforward you just want to authenticate and encrypt your traffic sip the most common way to do that for your signaling is just putting it on top
of TLS or on top of IPC you can also use S mime but sip TLS being the most common now your sip becomes TCP instead of UDP and you have pretty much fairly straightforward security the configuration is what is almost always the most challenging part of this because it's not necessarily standardized across vendors now in terms of media the actual voice and video data the way we approach security for that is there are several different ways there's a spaghetti soup of rfcs on how to implement signaling excuse me media security and there's usually there's two main approaches you either exchange a key within the signaling packet So within like the session description within the Sip packet or you exchange a
key directly within the media stream within the RTP stream it's really exciting the exchanging the key I'm partial to zrtp which exchanges the key right within the media stream and the reason is that you have to assume that your signaling channel is secure if you're doing key exchange in your signaling in your signaling traffic unless you're using something like diffie-hellman uh zrtp does use a femoral Diffie helmet to provide encryption of the media stream but what's interesting so a good example is LIN phone is a freely available um open source soft phone agent user agent for sip Network and um it will do you can check the srtp box in it and it will do a key exchange but
it does a plain text key exchange right in zip packet and if the Sip isn't encrypted it doesn't complain about it it just exchanges it right over the network and you can rebuild entire call streams based on that extremely easy to do [Music] um so I also want to talk real quick because we focused on this very heavily and this is the platform we used in ists is asterisk so digium the company that creates asterisk it's a free open source um PBX it's uh digium describes it as a box of Legos for people who want to create Communications applications and I focus on the application word there because typically we're not just talking about two people calling each other
anymore we're talking about Voice driven applications things like paying your bills online things like managing an account I'm sorry paying your bills online paying your bills over the phone things like managing account over the phone all kinds of things like that so you have an interface of your voice system to other back-end systems and asterisk is very modular which is one of the reasons we used it in ists you just configure what you need and don't configure what you don't it's pretty straightforward we use the Sip Channel driver and asterisk because we were doing Sip and we used a couple of specific dial plan applications to implement different vulnerabilities and it was pretty straightforward and your
main config duration files here they're all going to be located in slash Etsy asterisk but you're looking at zip.com to do the Sip configuration configure your endpoints your phones and then the extensions.com which is that dial plan I was discussing that describes how calls are routed throughout the voice infrastructure um and the dial plan and asterisk is very rich there are a lot of applications to do pretty much whatever you want and if there isn't an application to do what you want you can you can write your own so that was very beneficial to us so with that out of the way take a moment to discuss the architecture rebuilt for the competition [Music] so it was a pretty um straightforward
Hub and spoke architecture last year I I stated um we kind of one of my friends did voices a last minute add-on to the competition so the night before somebody was like hey we have all these phones we should do something with them and he had this awful full mesh sip topology going that they were you know troubleshooting all day on game day and I said so this year we started real early and I said you know I said Anthony you're you're pretty good at asterisk all right sure so I came up with the the way we would do it so basically every blue team had an asterisk box we installed the asterisk service alongside of a regular
scored box so it wasn't a dedicated phone system um I think it was on the server that was being scored for SSH access and um so we just installed it right on there every blue team paired up with the white team server and then the white team managed call routing throughout the architecture so if team one called team seven that that call routing was handled by white team but you had to keep your Blue Team box up obviously to receive and place calls and then each team had a physical phone so this is what that looks like it's pretty much exactly what you'd expect a hub and spoke architecture to look like both white Team and Red Team had their
own phones and those we hung them directly off of the white team call server and then each blue team had their one phone which they could certainly add more phones if they wanted if they wanted to use a soft phone or something and then their phone paired up with their server and their server appeared up with ours so with that said our approach toward vulnerabilities that we wanted to build in was to create these glaring asinine vulnerabilities that would kind of give competitors an idea of where to look for vulnerabilities in a voice system so typically the box that a blue team receives on game day is filled with ridiculous vulnerabilities I know this year notably on this particular box
every time you executed the service command like service asterisk start or service asterisk stop it would spawn a netcat listener um one of my last year they recompiled the SSH name into not use encryption at all so your entire any SSH going was totally unencrypted and I remember if they were talking about recompile they had to recompile and everything this year on the web server if you sent the web server and HTTP delete request it would drop your firewall it would reset your root password and it would um I think it would also spawn a spawn a listener as well so is ridiculous it's probably not things you're necessarily going to see in the Enterprise but the idea is we have
students we want to give them an idea of what kind of stuff they should be looking for you know looking at netstat output looking at you know things like that to see um what might be actually going on in their box so I was thinking about this and I was setting up asterisk you know I realized that asterisk will execute system level commands you just change this this uh live dangerously and set it to yes in your asterisk configuration and then if you set your asterisk user to run his root you're basically you can execute commands right from the dial plan as a root user so that was the technical premise of our of how we
approached doing voice security and or doing void vulnerabilities for the competition and that allowed us to do some really uh some really fun things so you know once I realized that I was originally just going to build a functional voice architecture but once I realized we could do some more fun things I said okay let's come up with an approach to make teams think a little harder about their voice architecture so there were three um ideas I had I wanted to build in some kind of really obvious vulnerability that even somebody without any asterisk experience at all could probably figure out and notice and say hey that shouldn't be there I wanted to build in
one thing that they just couldn't control and then I really wanted to do something less obvious but way more fun things like you know the voice equivalent of sending an HTTP delete request to reset the root password so excuse me the first one I had which was the one that should be obvious is the white team extensions were used to provide technical support to Blue teams so if they had any sort of issue with with their topology or this was all virtual topology so if they had a hypervisor issue they need a hypervisor password reset something like that they would call White team so I built right into their dial plan just a very simple
IP tables Dash F to flush their firewall every time they called us to help in the words of one of the competition organizers white team doesn't do work for free so [Music] this is obvious this is easy to fix if you literally just look at the extensions.com file I mean there's an iptable f and you should probably wonder why any configuration file on your system is dropping the firewall so I kind of wanted to build that in because people should probably notice it one would hope the next one that they didn't have any control over I built with an asterisk Q on the white team server every time they called a white team for assistance we would randomly
route calls over to the red team the professional hackers and that was funny because I was I was standing around on um on the day of the competition on the first day and one of the red team members wandered over to me he was like you're never going to believe this but somebody just called and said hey can you reset one of our boxes I said sure what's your hypervisor password and they gave it to me yes it made me so happy and in the event that both white Team and Red Team were busy you got to listen to the serenading sounds of Where The Hood At by DMX is you're on hold music that was that was the Easter egg I
worked in at four in the morning when we were putting together the competition um and at least two people got Where The Hood At which made me unnaturally happy but um now the final extension the r equivalent of an HTTP delete request was a system management hotline that each team had which is basically a voice response system like when you call to uh to you know to pay your credit card and it had options to do things like drop your firewall spawn a netcat listener add an extra user um and to really make teams miserable it would give you some long obnoxious extension to punch in and then say oh you got to put it in binary so they had
to convert you know like 935 000 to Binary and then sit there and type in one zero zero one so so we're testing this the night before with my friend you know we're testing everything we're sitting in the lab and he's he's you know he's listening to it and he's going okay one zero [ __ ] hangs off picks it up again so I was you know so my friend's doing that I'm like good that's exactly what I was going for because I want them to hate their lives so so that made me really happy and this is actually what that looks like specifically this entire thing is scripted I'll talk a little bit more about that but you can see there
are your um the the evil extension in this case would be for team two and if anybody in the architecture dialed zero two eight three it would sit there and read them this whole option set of menus to this whole menu of things you could do to the system and then those are the decimal and binary equivalents of the numbers they'd enter in and you got to pay to get a netcat listener we really made that one miserable so I had like I had it in the billions at one point but I was running into some problems I was like all right let me scale back a little bit and and not be that not be
that terrible to everybody so so it was a lot of fun and the way we implemented it was actually really straightforward I mean as I said the dial plan is where you define your call routing and how extension passing is handled and how how entries are handled so we just we just made changes to the extensions.com file um I kind of took a little bit of effort to hide things a bit you know I threw some includes in there so people who were just glancing at the file wouldn't notice um and that was the case with that menu I just described that was just a hidden include I gave everything kind of inconspicuous file name so hopefully
people people wouldn't notice them and I scripted the whole thing so every single blue team had a totally unique evil extension and they had a whole unique set of um had a whole unique set of binary extensions to enter in which is pretty cool I think because you know with something like a lot of other vulnerabilities it's vanilla so once you discover it on your server or somebody else is you can use the same thing against everybody but this really kind of required teams to work for it if they wanted to um if they want to discover it now the script is available on GitHub I'm acre Telly if you decide to look at the code it should work on any any Linux
system running asterisk please do not judge my scripting abilities by the quality of this code I wrote it because I was like trying to automate my testing process and then I eventually it just kept growing and growing and growing I said well this kind of sort of works we might as well use it and uh if you go back here there's literally no error checking in the script anywhere so it just assumes puppies and rainbows and everything works fine which occasionally is not the case and it'll it'll throw disastrous errors but it does work and you can kind of get an idea of how we how we implemented things um so if you don't have any asterisk
experience which I'm going to assume a lot of students may not these aren't things you're going to necessarily pick up on right away so they're going to kind of require you to dig in a little bit into the asterisk platform to find them so that was really what we were going for so here's a describe a little bit about the actual implementation this is uh the extensions.com file and right on the second line here um it's exactly what I was saying when dropping the firewall so anybody who took a moment to look at one of the two config files that really matter on an asterisk system should immediately pick up on the idea that we're dropping the
firewall every time they call somebody and should be able to remove that and then right down at the bottom is that istsmenu.com include and that's uh where we hid the hid the main menu for that Trojan menu that I described and if you look there right above right here this is the actual extension zero two three seven that would have been used to launch that menu um so to dig in a little bit to the actual code in the menu we have we'll look at right here prompt six the sixth prompt was to spawn a netcat listener so the asterisk system would say the prompt which I had a couple of friends of mine record and then it would
say a number 953 757 and then it would tell you to enter in binary and then it would wait for you to do that and then once you did enter it in binary so once you entered this miserable string of ones and zeros um it would it would execute this script that we had written which was basically just a shell script to um to spawn a netcat listener and it would say goodbye to you because it's a polite voice system and then um you would be able to get a new uh you would be able to find a netcat listener next year's idea is to actually make it more interactive and say okay change the root
password what do you want to change it to and let them enter it in and then do things like that but this worked for our purposes this year and it was a lot of fun to do so the question you might wonder is why exactly did we do these kind of ridiculous things that you may not see every day in an Enterprise I kind of doubt you're going to see anything like this floating around your voice system although you know I don't know I don't know what you guys are doing for boy so we kind of we focused Less on the void protocol vulnerabilities and more on configuration and the main reason uh behind that is to kind of raise
awareness that and I'm going to talk about this more a little later but to raise awareness that misconfiguration and the way you handle calling is a pretty serious vulnerability in a voice system and so we kind of wanted to bring teams bring that into the minds of teams who may not have any voice experience at all um and this is especially true in voice over IP and sip because you're not just dealing with entering numbers into a phone anymore you're dealing with packets and if you're reading data from those packets if you're reading headers and sip if you're reading the caller ID and things like that and then you're using that within your Voice driven
applications that can present in a tax service so that was kind of our goal another reason I didn't Focus as heavily on VoIP protocol vulnerability this year is because as I mentioned implementation really is hard and we were using these via phones and there was like basically nothing that we could do I mean we couldn't put certificates on them to do SRT um excuse me sip TLS we couldn't really get them to do srtp I don't think um so those were kind of some of the problems we ran into so how did this all turn out how did it work out for us um in the competition well from just an operational perspective the script
worked great setup was smooth everything worked it was a beautiful thing um by three in the morning we were done setting up the voice stuff and I decided to lay down on the couch and take a nap and I woke up at 4 30 and everybody was standing around the rack of equipment we had because the sand had a problem so they spent the next four hours trying to fix that but the voice stuff worked so go go team VoIP and it was Rock Solid over the course of the weekend we had 306 calls placed total uh no architectural issues call routing worked exactly as we expected it just worked well and I had a couple people come up
to me and say man last year you know because we we did voices this last minute thing they were like man it worked really well this year and that that made me happy and by the end of the by the final day so it's a Saturday Sunday competition by the final day we only had two blue teams who were still peered up with us because everybody else's boxes were so hosed that they weren't even really considered with getting voice to work they were couldn't even log into them so they had they had bigger fish to fry from the perspective of vulnerabilities by about 2 p.m on Saturday the first day of the competition nobody except red
team had really picked up on the fact that there was an entire system Management console hanging off of the voice system so we made it a bit more obvious and that allowed teams to start using them against each other and that was very telling to me because it was basically proving the theory I had before starting the competition is that I'm willing to bet that if we put a voice system in front of everybody they're going to have no idea what to really do with it except cross their fingers and hope their phone works um so the fact that nobody really picked up on this entire set of vulnerabilities we built right into the voice system uh
was kind of telling me in terms of um in terms of where people's voice knowledge lies which I thought was kind of you know kind of good um and kind of bad so I'll talk a little bit more about that but moving forward to next year we would like to record and time stamp all calls um we certainly did not do that this year because we didn't tell competitors we were recording them so that would be very illegal so there certainly isn't a collection of phone calls on my laptop um I want to get call statistics I would really like to get nice charts and graphs and pretty things like that there are tools that will do this for asterisk
and at four in the morning on Saturday I was standing there setting up one such tool and I was just hammering things into my computer and I'm like I'm not getting anything done I'm too tired so I took a break from that and that's when I had mentioned we had we had an issue with the sand so I wasn't able to get back to that after I after I took a nap but one of the unfortunate things that happened because of that is I turned off um comma separated value CSV CDR collection call detail record collection so we ended up with that without any sort of parsable um without any sort of possible information on what call is replaced and
we certainly cannot use the file names from call recordings it did not happen because they didn't happen so uh moving forward I'd also really like to see some better voice injects and voice challenges I would like to focus a little more on protocol security implementation I would like to tell teams hey we want you to implement sip TLS in your peering relationship between blue and white team and that was actually something I lab and tested before the competition and just didn't really have enough time to to build a good operational way to do it so that's on the that's on the um the agenda for next year and I'd love to see a little more um a little more uh better voice
challenges and voice bucket list items and chat and injects and things like that and I would really really like to make voices chord service because it really should be it's an integral part of any it organization anybody will work for and I would like some of the scoring to be based on that and it presents a unique issue to score voices of service in a security competition because most services like DNS you can just query them and it'll return if it Returns what you expect you say okay great but voice we have to query to see okay you're listening on your support grade are you actually talking to the white team server which would represent your
service provider in the real world does your call routing actually work so I have some ideas of how I want to do that probably do things like run checks on the YTM server to see who's peered up who's not and if they're peered try and run some test calls and and things like that so I do have an idea of how I want to do it I just have to talk to the scoring engine guys who write that and hopefully we'll be able to do that next year um moving toward the future as I mentioned um protocol vulnerability stuff they really like to get better phones because these Avaya phones are pain in the ass
to deal with and that's not because they're bad phones it's because the idea right now in voice and unified Communications is vendor lockdown on the system so you buy an Avaya system and you put it in your rack and all your phones work um so you're not you know they're not really designed to talk to asterisk they will do Sip and they will talk to it but they're not really there's there's a lot of caveats we run into um ubiquity networks if anybody's familiar with them they make fairly cheap access points and stuff they have these beautiful beautiful Android based phones that are basically this nice desk phone that runs a full Android stat and
runs full Android on it I'm like these would be awesome because we could do Android exploitation on it and we could do voice over IP stuff on it so I don't know if anybody wants to throw a lot of money at some really cool people let me know um but that's on the agenda and then I really do would like as I mentioned do some instant messaging do some unified communication stuff kind of integrated in more to what you might see in a medium to larger sized Enterprise so this is all fun this is all cool but where exactly do we build this into the real world um well this demonstrates a couple of things
um as I mentioned voice isn't always a well understood service and your voice applications can be very vulnerable they may not be as exciting as the vulnerabilities we built they're probably not going to be because I doubt as I said I doubt anybody has a Trojan ibr menu hanging off their voice system but the reality is that we're moving towards communication-driven applications we're doing things like paying our bills via phone we have been for a while and we have to ask ourselves a question are those applications secure are the relationships that your voice system has with those applications secure with those back end systems secure a good example there's a file in the asterisk source code called readme
seriously.bestpractices.txt and it takes this example right here that I have this 500 and sip slash and all that crap and it's basically going to the idea that signaling packets are packets that you're ingesting text Data if you're ingesting that into your applications you have to make sure you're doing proper input and output sanitization because in this case this would not only dial extension 500 but it would also tell the Sip Channel driver to dial an external call so like I said we're not just dealing with numbers anymore and that's very important um so this poses some serious challenges for administrators and implementers of voice systems um we have a publicly facing voice system that's interfacing
with internal systems we have to make sure we're auditing that correctly we have to make sure that we're not just you know scanning the Linux box and saying yup looks good but are we actually auditing The Voice applications like we may audit any other externally facing application like a web application for example so those are important considerations for as we move toward communication driven architectures so and then in the case of protocol security we have to ask how are we implementing that how are we implementing it in a mixed vendor environment is our current implementation if it's one vendor scalable to the idea that in five years we may say hey I'd really like to get
this soft phone by another vendor will that work with our system if you're using security as a checkbox is that what is it actually doing what does that mean you know sniff packets is you know if you're checking security is it just doing sip encryption signaling encryption or is it encrypting your media as well and how and does that work for you so that's that's important and then as you pair up with the outside world to make external calls is people typically move toward buying sip trunks now instead of standard telephony trunks how is your provider implementing security are they doing sip TLs are they doing um you know are they taking the proper measures to ensure that your voice
traffic is secure and this is very important because people have a certain expectation of privacy with voice that they may not with other systems because they've been using voice forever and they just assume that their voice system is going to be secure so these are important so some takeaways I'd like to bring to anybody here who's either a competition organizer or a competitor of a security competition if you're an organizer build voice in your competition do cool stuff with it it's a lot of fun and it could really present a learning opportunity for your competitors for a service they might not be that familiar with build good injection challenges that push teams to do things like secure their voice system
to integrate their voice system with other systems that they're responsible for and then make your vulnerabilities cool because that's obviously the most fun part let's be real um and you know also integrate voice in the spirit of the competition so we would since it is and I since each team blue team does represent an I.T Department we called them and we pretend to be users and then we'd be confused and ask them for tech support help and then get really belligerent with them there's a great video of me on Facebook from a couple years ago just screaming and insulting some team and trying to get them to calm me down and they did and they did a good job and they scored well
for it so you know use use the actual voice stuff too don't just use it as a vulnerability platform for your competition and then take advantage of things like asterisk or free PBX or any of the number of hundreds of smart cell phone clients that exist out there if you're uh if you're organizing a competition if you have any questions my contact info is in the slide I'd be happy to help you build a really cool voice architecture for your competition now if you're a competitor know your voice system because everyone is different asterisk is different from free PBX which is different from God forbid Cisco call manager Express which is different from every God in the
world forbid any sort of Avaya platform it'd be insane if they gave you that in a competition environment just because it'd be so expensive to do so know your system and know the clients you're going to be using soft phones will use predefined ports for um for RTP in some cases cell phones and voice software have specific vulnerabilities so um there was an email last night on one of the SEC mailing lists about it was a couple days ago about how asterisk is open to a to um accepting arbitrary certificates for sip TLS if you put a null byte it's vulnerable to a null byte um vulnerability in in SSL so you know know the system know the platforms you're
going to be using because they are just software platforms that may have their own vulnerabilities and get offensive do things like War dialing scan the Sip Network play with some of the tools Cali's got a lot of built-in tools um scapey has built-in signaling abilities so do stuff like that and then of course you know learn I really enjoyed this I got into doing voice stuff about a year ago on my own just because I took a void class at school and really kind of went above the coursework because I thought it was really interesting stuff so that's what I encourage you to do and as I mentioned tools and tactics there's a fantastic article on the backtrack Linux site
about assorted vulnerabilities their implementations and then assorted tools that you can use to execute attacks against those specific voice vulnerabilities this is a great article describes tools for extension enumeration for call capture and Playback which you can actually do right in Wireshark and then Metasploit has some sip functionality some sip modules built in as well as some platform specific exploits for you know like asterisk or free PBX or something so to kind of wrap up I would really like to thank and provide links more specifically because these slides will be online um RIT sparsa the security practice and research Student Association blue white and red teams of information security Talent search 12 and then the department
of computing security to for peaking my interest in this topic and with that thank you for listening and I'd love to open up to some questions and comments I think I was told I have uh 10 minutes left so yeah um what's your opinion of like more commercial systems like Best Buy like Puma so I'm not I've never used Uma um I think typically I'm if I'm doing something in an Enterprise I would always be skeptical of something I pick up at Best Buy um you know a lot of the common way to do voice in an Enterprise right now is to buy like a Cisco system or a bias system and then pay atrocious amounts in
licensing but I think if you're willing if you have somebody who's willing to be a subject matter expert in a system like asterisk or a platform like free PBX and is kind of willing to go the extra mile you can get it running a good a good Enterprise voice architecture running on something like that and those kinds of systems you know the free software is particularly conducive to like I said building Voice driven applications in your Enterprise so and that's not really the answer you're looking for I'm just not too familiar I've just never used it but anybody else cool well thank you for your time appreciate it hope maybe you learned a little something today my contact info
is on here my uh these slides will be on my site and um yeah let me know if you have any questions and enjoy the rest of the enjoy the rest of your b-sides and go eat lunch