 analysis platform, which is built in conjugation to Wireshark. A little bit introduction. My name is Nishant Sharma. I work for Pentester Academy. Before being a security researcher, I was a developer. I was developing Wi-Fi access points for enterprises as well as the Wi-Fi security systems. I have a master's degree in Infosec and for last couple of years I have been presenting my research at Black Hat USA, Black Hat Asia, Demolabs, HITB and all the other venues. Here are my team members. Let me introduce them. Hello everyone. My name is Ashish. I work for Pentester Academy as a senior security researcher. Before joining Pentester Academy, I work for law enforcement agencies as a cybercrime investigator and I've been in this industry from last eight years. My work has been presented in Black Hat USA, Black Hat Asia, Defconn USA and this time in Defconn China to present Wireshark. Hello Defconn. My name is Jeswin. I'm currently working as a security researcher at Pentester Academy and my work has been presented at Black Hat Asia, USA and Defconn Demolabs and here I am to present Wireshark. So those of you who do not know about Pentester Academy, it's an online portal which is completely dedicated to security related courses. As it is online and it is subscription based, you can subscribe to it and you can access 40 plus of our courses which are completely focused on security. We also run attackdefense.com which is an online browser based cyber range. Once you sign up for this you can actually get access to thousand plus of labs which are spreaded over 65 categories. The reason for mentioning the attack defense here is because we even have a community section which is free for all. You guys can go and check those challenges out. You can play those for free. So now coming to the topic at hand, we are going to discuss Wireshark but before diving to the main tool, we are first going to cover the basics of Wireshark. Then we will see how to recover or reconstruct the Wipe call. After that we will take a look on the current state of open source tools that are out there that you can use and we will conclude the talk by introducing Wipeshark that is our contribution to the community and the field. When we talk about Wipe Telephony, this is the thing that is going to eventually replace PSTN completely. PSTN is your classic phones. You know you have your dedicated lines connected to exchanges. You pick up the phone, you dial the number. What it does in the back end is it reserves a circuit for you and after the call is complete, only then the circuit is destroyed. Because you are reserving this circuit, it is not that efficient. Another reason why this is not the best solution is because when you are doing all of this you have to do analog to digital conversion two times. So because you are Wipe, run on IP and so it can use packet switching. So that's the reason why most of the enterprises and now even telecom providers are moving toward your Wipe. We are not going to talk about proprietary protocols but only the open source standards that are in making and they are on the way to take over the industry as well. So we are going to talk about SIP in general. These are three protocols that you will learn about when we talk about the signaling protocols of Wipe. So Wipe has two major parts. One is the signaling and the other one is the media carrier. Signaling defines when the phone will ring, when you will disconnect the call, all of that control operation is done by signaling protocol. The actual voice or the video when you are making the call is then handled by the media carrier that is RTP in this case. So we are only going to focus on the first one here that is sorry that is the SIP and the other protocols are proprietary so we are not going to talk about them. SIP or the session initiation protocol is the signaling one. It's a text-based protocol and it supports your audio calls as well as video calls. So as I already mentioned when we say it supports these calls, it is only being used for the controlling. It cannot carry your data or media. It can carry your SMSs because they are text-based data right? So it can work there. It is important to mention that SIP by default is not secure. It does not provide any kind of transport layer security. So if you want to secure your SIP communication, you have to use TLS with it. So just like you do for HTTP right? You have to use SIP over your TLS. This is the model in which your VoIP telephony work especially in SIP case. When you join the network or when you join the system your phone will actually register to one of the servers, the VoIP servers and that is done by using the subscribe message. So after that is done if you want to place a call you will be pushing a message to the server and then that message will be forwarded to the target party. So that is how you will place a call. When any other party want to call you, you are going to get a notify message because you have subscribed to the service. This is a simple flow chart of a call between two parties. The first party when they initiate the call at an invite packet, SIP invite packet is sent. After the other party picks up it gets the acknowledge. After that your media transfer takes place and a buy packet is sent by the party who disconnects the call. So now these are the user agent servers which we can use any servers which you may like. In our case we have used Asterix because it's open source it has a very good documentation and that's the most popular one. So and to place a call we need a soft phone or a hardware phone right. So there are some commercial soft phones available and they do have a free version of that. We have used Microsoft to capture all the traffic right. So and we have used Asterix now. So what is Asterix now? Asterix now is the Asterix server which will handle all the backend stuff, signaling and calling etc. The free PBX will allow us to manage and control the Asterix server using the graphical interface right. To demonstrate different configurations we have taken the VoIP traffic capture in this simple setup. So this setup involves a scenario where there are two clients and a server and all of the VoIP traffic is going through the server. Now when it comes to VoIP setup to enforce security we can achieve that in different ways. For example in one case we can have SIP packets encrypted. In another case we can have RTP packet encrypted. So these are the four possible scenarios when it comes when we encounter VoIP traffic analysis. So the first one is SIP and RTP where both SIP as well as RTP packets are unencrypted. The second case is SIP over TLS and RTP and as the name suggests SIP packets are sent over TLS and RTP packets are unencrypted. In the third case we have SIP packets unencrypted and SRTP is used instead of RTP and in fourth case we have SIP packet sent over TLS and SRTP is used instead of RTP. So we'll take a look at the first case which is SIP and RTP. So now SIP SDP packets contain all of the information which is required to set up the RTP stream and if encryption is enabled the encryption key will also be present in the SDP packet. RTP packets provide the statistics and control information of the RTP session and RTP packets carry the media. So now Wireshark has a really beautiful feature which allow us to analyze the flow sequence of VoIP call. So this is how the flow sequence of a VoIP call between two client will look like. So starting from the invite packet start how the call was initiated till the end of the call. Wireshark also has an option to play the VoIP calls. So we can easily play using RTP player of Wireshark. So as he explained if you are using SIP plus RTP that's the simplest form that you can use. There is no encryption if you have the packet capture your Wireshark out of the box can actually reconstruct the call. You can play the call so you know life is good. But what if some part of the call is encrypted. So in the second scenario when you use SIP plus SRTP your RTP packets are now encrypted. So you can still see the SIP packets as you can see here. You can also observe the key that is being used by SRTP to encrypt the traffic. So we are talking about the media traffic here. So whatever you are saying whatever the video is going all of that is encrypted but you are able to see the key. But the problem is in this case now your Wireshark cannot decrypted. It can see the key but it cannot decrypt it. And if you look for RTP traffic instead of getting the RTP traffic you are going to see the SIP traffic. Now the issue is when you will try to reconstruct the call you will get something like this. So this is how an encrypted protocol will look like because you know the data is randomized. You should not be able to make any sense of waveform from it and you know this is doing it pretty well. We cannot tell what kind of waveform it is. What are other configurations? In other configurations you can protect your SIP by using the TLS and you can leave the RTP out. So in that case you won't be able to see SIP packets because they are over TLS. You will be able to see TLS traffic a lot. Now in this case even when RTP is not encrypted you are not going to see it. Why? Because your Wireshark actually relies on SIP packets to figure out which UDP packets are actually the RTP packets. So because now it cannot see the SIP packets it cannot tell the difference between the normal UDP packet or your RTP packet. But in this case if you observe the traffic you will find out that from one port there is a lot of UDP packets and if you follow the stream you should be able to make sense out of it. Once that is done you can use decode as function of Wireshark and by setting decode as to RTP you can still recover the call. There you go right? So this is the proper waveform and if you play it it will play. You will be able to see listen whatever was you know whatever was passed. Last is the super case of all right. You have your encrypted SIP and then you have your encrypted SRTP. So in this case because you know you are your Wireshark will not be able to see the SIP or the RTP it's a little hard. But the possibilities when you are using TLS in this case is either going to be one of two. Either your TLS handshake is going to use your Diffie-Hellman exchange or it is going to use your RSA-based handshake that is the private and public key thing right. So if it is using DHE, DHE is pretty secure you know if you have collected a passive traffic sample you cannot find out the key from it because DHE protects you against eavesdropping. But if you can do active MITM attacks you can actually target this too. But we are not covering the active side we are only talking about the passive side here. This diagram actually explains how DHE works. I'm not going to go into details but it is here so that you guys can refer to it later. Similarly you have your RSA based public and private key pairs which are used. So our observations when we were doing all of these experiments were that if DHE is used there is nothing you can do because we are only seeing the passive traffic right. We don't want to do the active attacks. When RSA is being used if you have the private key of the server that is being used for VoIP transaction you can actually go ahead and de-grip all of this and Wireshark has a functionality for this. But before that you have to understand which of the method is being used. So for that if you check your TLS handshake you should be able to see something like this or you can see here right. It will tell you if it is using the Diffie helmet. Similarly in case of RSA you will be able to see RSA handshake. So once that is done once you use your Wireshark to decrypted this traffic you can go ahead and decode SITP as well but if your SITP is not decrypted it will again look like this. So this is how it will look like in case of RSA. This is the field from where you will be able to tell if the RSA is being used or the DHE. Before performing any action we should be able to anticipate if it is going to succeed or not right otherwise there is no reason of you know doing blind experiments. So if DHE is there there is nothing we can do. So now coming to the SSL part if you guys have already decrypted SSL traffic you already know about it from the edit preference option if you look for the protocols if you go to SSL protocols it actually gives you an option to put a private key there if you do that it will decrypt the traffic for you and once the SIP is decrypted you can see the SITP key and by using other tools you can try to decrypt it. Now the issue is there are two tools here and I'll let my colleague explain it. SRTP decrypt one. SRTP decrypt is a tool to decrypt SRTP stream so this is the github repository and now let's take a look at how we can install SRTP decrypt. SRTP decrypt requires certain libraries to be pre-installed on the system and once we have installed these libraries we can clone the repository and use the make to compile it. Now this is a big limitation of SRTP decrypt that it do require a Linux system with built tools installed to use make. Once we are done with the compilation we'll have a ready to run SRTP decrypt binary. However this binary is not smart enough to figure the encryption key on its own so we do require to pass the encryption key as a parameter to the tool. We can find the encryption key in the crypto parameter of the SDP packet. We also have to make a note of the UDP ports which were used by the SRTP stream. So let's take a look at how we can use the tool. So since we already have the key and the input file we can directly feed it to the binary and it will generate an output in form of hex dump. This is how the hex dump would look like. We can then use wire shock to import the hex dump and recover the RTP packets. So we do have to specify the UDP port information here as well. So once the import has been completed what you'll notice here is the timestamp as well as the IP address both source and destination have been modified. This is because SRTP decrypt do not preserve the metadata and in SRTP decrypt the generated hex dump did not have any set packets. As a result wire shock is unable to figure out that a UDP packet is actually an RTP packet. So we'll have to manually decode UDP packet as RTP packet. Once we have decoded the UDP packets as RTP packets we can then perform stream analysis on it. And if we'll try to play the decrypted call what you'll notice here is the waveform is not visible. This is again because the metadata was not preserved by SRTP decrypt. However if you'll click on the play button you still be able to hear the voice. So as you saw the issue with this tool is first you have to need a Linux system. You have the Linux system now you have to install the build tools you have to compile it and after that only you can run it. And after going through this whole tedious process in the end again the metadata was not preserved and if you are into forensics and everything you know right IP addresses and timestamp is the most important thing so we cannot lose them. Another tool that we have is the lib SRTP. It was created by Cisco it is available it is open source just like the other tool it also needs you to use Linux. Once you have your Linux you can clone it and then you can do the configuring make it and after that it is ready to use. Now just like the tool that we discussed about the SRTP decrypt this tool also does not know how to decrypt it automatically so you have to feed it the key and this one is even complex than the other one because in this one you have to first filter out the stream that you want to decrypt. So whenever you are placing a wipe call whenever you are calling someone there are always two streams on one RTP stream whatever you are saying that data will go or that audio will go. On the other stream the other party whatever he is saying that audio will come. So in this case you have to first identify which stream you want to decrypt you have to then find the corresponding key copy that and pass that to your the tool. So this is the filtering part you filter it you export that stream as a pcap and now you can run it and by after doing that it will give you output in this format that is actually text so you have to again make it into a pcap format and for that we are using text to pcap tool so it is converting the timestamp that is in front of the packets that's all it is doing so when you use both of these in conjugation after that you are able to see the SRTP decrypted form and once that is there you have to then again decode it as your RTP and once you do that you can then see the waveform this right but also in this case you were not able to preserve the IP addresses or the timestamps so that's a big no-no and you already you have already seen the process right it was ideas and the idea of making this tool the wipe shark right it came when we were working on creating a new course for our company that was based on wipe security so we were actually using these tools and that's when we realized that there should be something which is easier than these which can be used by other people on platform of their choice right no one should be forced to use a platform which they don't like for some reason then there are other artifacts which are important when we talk about the security in wipe like your DTMF the messages and the then one more function that you need is the exporting call function which is then used to analyze the call in other softwares right so if you guys don't know about the DTMF so whenever you call your credit card company or whenever you interact with any kind of IVR system it asks you to press one two three on your dial pad right so that is DTMF so whenever you are pressing to something like this is going through the route if you're using boy if you're using your PSTN then obviously that's different similarly if you send SMSS or wipe your ship a protocol is is going to carry those and this is how it will look so now if you want to export the calls and if you want to do forensics on that you need to convert it into the waveform so my colleague will explain how to do that so now we want to convert the RTP stream to wave format so there is one online service which we can use and convert the RTP stream to wave we just need to upload our PK file and submit it for the process then it will convert the RTP stream to the wave and we can download it on a local system then we can play it using any media player such as VLC or Audacity right so if you are more concerned about our privacy right so we don't want to upload the PK up online so we there is a script on written in bash right and it uses t-shark and shock and that's the GitHub link it does the same job and that's the tool help option so we need to make sure that before we run the script we need to install t-shark and shocks on our system then we can run the script by passing as a first argument the pcap and in the second argument we can you know mention the output file name and if you can notice in the snapshot there's a two file generated right so that's our wave file and if you notice in the directory of the script so before and after running the script before we can't there is only two files right because we haven't run the script so after we run the script it there is a three file has been generated and we can actually play it using any media player as I just said and we can actually hear the call so enough of problems now let's talk about the solution that's the interesting part and that is our contribution to this field and that's where we bring in our tool that is wipe shark as you guys can guess easily that the wipe part came from wipe and the shark part is taken from wire shark because the tool is created in form of the plugins of wire shark now there's a reason and I'm going to explain it why instead of creating a separate tool why we chose to go with this route wipe shark can decrypt your wipe calls whenever possible so by that I mean whenever it will be able to see the decryption keys or the encryption keys in your SIP packets it will automatically decrypt it it can run on live traffic it has gpl license just like your wire shark so now the next question is do we really need it we talked about a lot of problems and some of them were the tools that we already have they are cumbersome to use not everyone can use them you have to install them then you have to go through the TDS process and then you can get the decrypted stream right another thing was these were restricted to Linux systems you have to use Linux because the TDS was so long the process was so tedious it is more likely for the users to make mistake because you have to select the right key then you have to select the right stream in some cases and after doing that they were not maintaining or retaining your metadata that is your IP addresses and the timestamp right another problem with those as you already saw is that the input that those tools take that is not live traffic that is a captured peak app that is passed to them after manual processing right so our wipe shark can do all of this and that's why we think it can actually help people who are doing boy panelist is up why why shark plugins because we all love wire sharks whoever is there in network analysis field he has seen it he has used it and he knows the kind of power wash up has right so we decided if we create other other tool just like the other tools you have to again install it and then it will become platform dependent and then we have to also take your because we are dealing in packets here right so packets can be in the magnitude of thousands and even you know hundreds of thousands so why not to use why shark specialty they have created work shark only for this purpose another reason is we want this tool to be extensible so instead of going for see or any other compiled language which was Lua Lua is a very user friendly language it's more of a scripting language with power of C so if you join any scripting language that you think like your python or something it has the power of C and it has the flexibility of python and even in case of python if you want to run it you need to you know and interpret it in this case if you are using it in wire shark plugins you just need to paste the plugins in the plugins directory in Lua itself you need not to compile it you need not to do anything it will run out of the box and because your wire shark is always independent so are our plugins it will run on Windows Mac you know Linux you name it on any platform on which you can run your wire shark our system will run wire shark plugins are basically of two types one is the listener one other one is a disector one we are using both in our toolkit and this is how the typical dissection takes place in wire shark you pass it packet it has a chain of disectors so if you have used wire shark you know what I'm talking about because when you get the packet you have these layered layers there right you have Ethernet layers then the IP layer then the TCP and then the above layer like HTTP or FTP for that matter so that is what exactly happening there so first whenever the packet is captured it is passed to wire shark the first plugin or the first part to get this packet is the outermost player so in this case it will be the Ethernet so Ethernet header will be processed there and the payload will be passed down to the second one second one in the chain so in this case you are chained plugins wall so our wire shark is also plugged in the chain like this it takes after once your UDP and TCP parser is done so from TCP and UDP parser phase it figures out if the packet is SIP RTP SIP or SDP it will pass it to the wire shark chain and then wire shark will do something which looks very complex here I'm not going to explain all of this we have a detailed research paper which will be available on the github repo you can go through it if you're interested in knowing the internal workings you can refer to this if you have any questions we will be reachable on mail also similarly this is the decryption routines for SIP traffic description and decryption and this is how you install wipe shark you just go to our github repo you copy it and just paste it in the plugins folder and to find the plugins folder just open your wire shark go to the help section from there you have to go to the about wire shark and folders so you will find personal plugins folder there just open that folder put our stuff there and it will work out of the box yeah you have to restart the wire shark not the whole system so once that is done suppose this is your SITP traffic right so now we have installed wipe shark this is your SITP traffic just go to edit preferences so if you guys have already decrypted Wi-Fi traffic or SSL traffic you know what I'm talking about you go to edit from edit you have preferences option from there in protocol section you have to look for wipe shark so that is the new entry that we have created once you install the plugin once you copy the plugins into the folder and once you tick the box there so there was this little box here this one right just tick it it is not ticked by default because you know if you don't want to decrypt it we also don't want to once you do that you click ok and there you go that's all you have to do to decrypt the RTP traffic and after that you can actually create waveform from it now coming to the other problem that we had we want to export the call in a popular format audio format right so that you can use your audacity or other tools on it so for that we have provided this option here from the tools menu if you go to the wipe section you will see the export wipe wave option and you can export it from there it will ask you if you want to define a custom location or the file prefix if you don't then it will use the default one and then it will export all the streams that are there in the pcap so we have also appended IP addresses of source and destination so that you can keep track of streams of your interest also when we were doing all of this one more thing that we wanted to be out there was something which can provide you summary of your wipe traffic so suppose you are capturing this traffic on a network router or switch right so now you're dealing with hundreds or thousands of calls so you want to know which people are placing the calls which numbers are there all of that is needed right so what we did we also created some more plugins which will do all of that for you so this one is the DTMF so anyone if he was using RTP which was the unencrypted version if he has passed anything on DTMF it will be logged and our plugin will show it in a pop-up right similarly you have your extensions so these extensions are actually the numbers so this one here the extension is the number if a username is associated with it that will also be shown with the IP address and also with the user agent user agent is the software that you are using to place the call now this information can help attackers in all of other ways also right so similarly we can see how many RTP packets were transferred which can help us to to quantify if it is an audio call or video call or how long it was right so all of the information that was needed from the security perspective that's the only thing that we have covered we haven't gone for the basic set then again when you connect to the server the SIP server you have to register to the server and just to make sure that no one can use your extension there is this password that you have to pass so if you want to brute force some users password just copy this string this one is hashcat compatible so you can just copy it and run hashcat on it and if the password is weak it will break we can also see the servers or the proxies that are being used for wipe the messages the SIP SMS which are which were passed and the last part of the toolkit is to detect attacks so suppose someone is running some attacks on your setup and you have the traffic capture you want to know if some of the wipe attacks are being launched first one is the brute forcing if someone is trying to brute force your password our plugin can actually detect that by checking the number of tries in a given threshold of time similarly invite flooding can be detected so invite flooding is like calling someone again and again so whenever you place a call an invite message is sent from the caller to the callee now think about it you send the same message like thousand times what will happen his phone will ring he will pick the phone up he will put the phone down the phone will again ring so it's kind of DOS or irritation attack right so it can detect that it can detect the message flooding if you are spamming someone on the wipe and it can also see if someone is trying to do active MITM on your calls on the local network it can also detect if any unauthenticated user is there so now we will see a little bit demo of how to decrypt the SITP protocol and how to export the calls using our tool can we have the demo please yeah so there we go first one is to decrypt the SITP traffic you have this capture here which has SIP plus SITP traffic so if you search for SIP you should be able to see the packets but when you search for RTP you will be able to see the SITP traffic that is the encrypted one so what we are trying to do here is we are trying to reconstruct the RTP stream to listen to the audio and this is how it will look because it is encrypted right so now what we can do in this case is from edit just go to the preferences part from there in the protocols we have to look for wipe shark so once they are just tick the small box and click okay now depending on the number of packets Vaishark will take its time and it will give you the RTP packets so now with a click of this button you have actually decrypted SITP and if you try to reconstruct the stream you should be able to see the waveform in its proper form and you can play it so that's the first part and that's the major contribution that we think we have done all a further is like the bonus then the second part of this demo is in which we are exporting the wave files for each stream so that is also very easy you just need to go to the tools option from there go to wipe all the tools all the plugins you can find there this is again asking you if you want to change the file prefix or if you want to change the location once that is done it will export all the streams to this location with the prefix provided so that was our demo all of these plugins will be there our research paper will be there on our GitHub repository that is this one it is already it's not up yet it will be up after the talk we have a tool visiting cards you can take those if you want and if you have any questions I will be taking those now any questions related to SIP RTP SITP anything is welcome so even if you think of something after the talk here is my email ID you can drop me a mail I will revert to the mail I'll be happy to help you with you know whatever question you have so that concludes our talk thank you for coming to our talk and thank you deafcon for giving us this opportunity thanks