Your SlideShare is downloading. ×
voip1.doc
voip1.doc
voip1.doc
voip1.doc
voip1.doc
voip1.doc
voip1.doc
voip1.doc
voip1.doc
voip1.doc
voip1.doc
voip1.doc
voip1.doc
voip1.doc
voip1.doc
voip1.doc
voip1.doc
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
324
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. VoIP Security: Final Lab Group 26 Fall 2005 ECE4112 Henry Owen Michael Norris Brian DiRito 8 December 2005 1
  • 2. ECE 4112 Internetwork Security Final Lab Addition: VoIP Security Group Number: _______________ Member Names: _________________________     _________________________ Date Assigned: ________________________ Date Due: ________________________ Last Edited: ________________________ Please read the entire lab and any extra materials carefully before starting.   Be sure to  start early enough so that you will have time to complete the lab.  Answer ALL questions  and be sure you turn in ALL materials listed in the Turn­in Checklist ON or BEFORE  the Date Due.   Goal: The goal of this lab is to explore the issues with Voice over IP security. The student should have a working knowledge of basic VoIP security problems upon completion. Summary:   This lab will configure two workstations to run basic client-to-client VoIP software. The student will create a call between the clients, intercept the traffic, and recover the conversation. The student will also explore denial-of-service from a third- party. Background and Theory: Voice over IP is increasing in popularity. The economics and feature-set make VoIP attractive to many enterprise customers. This trend appears to be continuing. However, VoIP security is still wide-open. No widely used authentication or encryption schemes have been adopted. VoIP Signalling: In order to establish a communication session, a signaling protocol is required. Depending on the type of the communication network, different signaling protocols should be used. In the public switched telephone network (PSTN), for example, signaling series 7 (SS7) controls the establishment of calls and configuration of intermediate switches. Without SS7, PSTN networks could not establish an end-to-end virtual circuit. Voice over IP, like the PSTN, requires a signaling protocol. It runs over packet-based networks and SS7 does not apply. Two common signaling protocols have been developed 2
  • 3. and deployed: Session Initiation Protocol (SIP) and H.323 by the IETF and ITU respectively. Cisco has also proposed their own standard called Skinny that differs a little bit from the first two. All three protocols establish an initial communication session and were designed for many types of applications. Voice, video, instant messaging and any real-time application were the primary envisioned applications. VoIP deployments often have to interface with the existing PSTN. Several protocols have been proposed that attempt to standardize this. Media Gateway Control Protocol (MGCP) is the most common. At a high level, it negotiates between the signaling gateways on the PSTN and the call agent on the VoIP network who converts the packet stream into a circuit. This lab will not focus on this portion of VoIP. Most VoIP deployments utilize a proxy agent in the signaling phase. The proxy agent would be the call manager or authority for a specific domain, e.g. gatech.edu would have their own proxy. The users of each proxy establish their present address and location with the proxy server. When someone wants to call a user, they contact their own proxy who communicates with the recipient’s proxy agent. The proxy agents know the address of the recipient and forward the invitation request. At the end of the protocol negotiation, the proxies step back and the clients communicate directly. Transport Layer: Unlike the signaling protocols, the transport of VoIP traffic has generally standardized on the Real-time Transport Protocol (RTP). RTP is connectionless like UDP (and in fact uses UDP in its implementation) but provides additional services like packet ordering and timestamping. These features make it more suitable than UDP for voice date. RTP works in conjunction with an out-of-band control protocol called RTP Control Protocol (RTCP). RTCP provides feedback about the performance and quality of the RTP stream. Stream Interception and Reassembly: Signaling and transport are both performed using plaintext protocols. No confidentiality or authentication has been integrated into SIP/H.323 or RTP. While some extensions to these protocols provide encryption, the majority of applications utilize plain SIP/H.323 and RTP. Any adversary who can gain access to the transmission can reassemble the conversation. Voice compression and decompression (CODEC) complicates conversation reassembly a little bit. The adversary must recognize and understand the type of CODEC used. This is not too difficult as most applications advertise this information for capability and marketing reasons. G.711 is the simplest CODEC used in VoIP calls. It is a 64 kbps stream of 8 bit samples taken at 8000 hertz. There is no compression or decompression performed. Consequently, it will be easiest to reassemble. For compatibility, nearly all devices will support this 3
  • 4. CODEC. Prelab Questions: None. But make sure you understand SIP and RTP Lab Scenario: This lab will build two VoIP clients who will communicate with each other across the simulated network. For convenience, we will be using open- source software to communicate and another lab machine as a client. This lab could easily be modified to practice against hardware VoIP phones, such as Cisco’s or any other vendors. A Cisco conversation session dump has been recorded and provided courtesy of Vomit’s authors. The student will investigate and contrast this VoIP implementation with the one they will run. Each client will require their own machine since they both need full access to the soundcard. The student will be required to checkout an additional hard drive (or be provided another client by the TA). The hard drive will run RHEL4 Workstation with the default software plus the Gnome Development Libraries. The first machine will be called Alice for simplicity. Alice will initiate all the calls. The call receiver will be referred to as Bob. Our simulated eavesdropper will be called Eve. Eve will actually just run on Alice’s machine. The fourth party will be Mallory, our malicious attacker, who will be a Windows XP virtual machine. Two additional machines will be configured as SIP proxies. They will run under VMWare on the host machine. The SIP proxies handle user registration and forward requests unto the appropriate client. This facilitates users being able to switch offices or phones without reconfiguration. In addition, a common technique is to allow users to roam out of the office and have their calls forwarded to their cell phones. This mechanism is not authenticated with plain SIP. So an attacker is able to change or remove registrations in this scheme. This introduces a serious vulnerability we will demonstrate. The lab is composed into six parts. In the first part, the students will build the clients and install linphone, a VoIP client. This section is quite tedious and could be done by the TA. One idea would be to build two or three stations (of 2 clients each) that the students will use for the lab. Otherwise, each student group will need two sets of speakers and headphones. In the second part of the lab, the students will eavesdrop on a conversation. They will use this to develop a working understanding of the protocols involved. Ethereal will be utilized to analyze traffic protocol and patterns. Next, the students will reassemble their conversation and play it back to the TA. Conversation reassembly will be performed using the Vomit utility. Vomit reassembles G.711 encoded VoIP conversations. The student will next perform a denial-of-service on an active VoIP conversation. The attack will send BYE packets to one half of the communication. The attacked client will 4
  • 5. terminate the session and drop the conversation. This vulnerability exists because there is no authentication mechanism built into SIP. The final sections will build and utilize SIP proxies running SIP Express Router (SER). The clients will register with their own SER and establish sessions through each other’s proxies. The eavesdropper will capture the contents again, analyze, and reassemble the conversation. The student will answer several questions about SIP and the proxies roles in this communication. An attacker, Eve, can construct arbitrary SIP packets and attack the proxies and clients. One such attack will be demoed in the last section, but there are many more possible. This attack will remove all registrations for a user from the target proxy. This renders the user unreachable. Both this attack and the earlier denial-of-service are the tip of the iceberg in an unauthenticated VoIP deployment. aliceproxy.com bobproxy.com RHEL4 WS VM RHEL4 WS VM ` ` alice.com bob.com RHEL4 WS Host RHEL4 WS Host ` Eve WinXP VM Section 1: Building the Clients and Connecting First, you will get a new hard drive issued to you from the TA. Install Redhat Enterprise Linux 4 Workstation as you did in the beginning of the semester. For convenience, we will modify our /etc/hosts files. Add four entries: alice.com 57.35.6.A bob.com 57.35.6.B aliceproxy.com 57.35.6.C bobproxy.com 57.35.6.D Where A, B, C, and D correspond to the appropriate IP addresses you choose. 5
  • 6. Getting the soundcard, microphone, and speakers working varies from computer to computer. In the lab, the onboard soundcard is sufficient. RHEL4 WS generally detects these cards fine. To try sound playback, run aplay /usr/share/sounds/KDE_Logout.wav and you should hear it playback. Try the built in sound recorder to make sure you can record. If you cannot, run alsamixer from a shell and make sure the microphone is enabled. This is generally enough to get sound working, but Redhat has some excellent documentation if you continue to have trouble. The client we will be using is linphone. One of its dependencies are the gnome libraries. Open the Rehdat utility by clicking the Applications menu and System Settings -> Add/Remove Programs. Select all the Gnome Development Libraries to install them. You will be prompted for the CDs. Once they are installed, proceed with installing the tools specific to this lab. Install linphone under Alice and Bob. Directions are contained on the source media but will also be presented here: 2 mkdir labtest 3 cd labtest/ 4 cp -r /media/LEXAR_MEDIA/labstuff/linphone . 5 cd linphone/ 6 ls 7 tar xvfz libosip2-2.2.0.tar.gz 8 cd libosip2-2.2.0 9 ./configure && make && make install 10 cd .. 11 ls 12 tar xvfz speex-1.0.5.tar.gz 13 cd speex-1.0.5 14 ./configure && make && make install 15 cd .. 16 tar xvfz linphone-1.1.0.tar.gz 17 cd linphone-1.1.0 18 ./configure && make && make install Start linphone on both Alice and Bob by executing linphone at the shell. On Alice, enter Bob’s IP address in the SIP address field and click Call. Bob should hear a ring and should answer the call. The linphone client should look like the screenshot below but with the appropriate IP address for Bob. 6
  • 7. You should be able to perform you first direct VoIP call. We will use this basic procedure in Section 2 but will also capture the session. Section 2: Intercepting/Analyzing Direct Traffic Start ethereal on Alice’s machine. Capture all traffic from eth0. Start another call between Alice and Bob as you did in Section1. Talk for a few seconds and then go ahead and terminate the call. Stop the capture but leave ethereal open. Look for the SIP signaling phase in ethereal. Familiarize yourself with the protocol procedure. SCREENSHOT 2.1: Take a screenshot of Ethereal showing the signaling phase. Investigate the SIP packets in some depth before answering the first question. Q2.1: What signaling protocol does linphone use (from the protocol analyzer)? Is this a binary or ASCI protocol? Look further down into the call traffic. You will notice that this protocol is the workhorse of VoIP (for this application). Identify what protocol this is and answer the following questions. Q2.2: What transport protocol does linphone use? What controlling protocol did this utilize? SCREENSHOT 2.2: Take a screenshot of the first Sender Report. 7
  • 8. You will notice that this transport protocol does not return any acknowledgements. This is similar to UDP, but this transport protocol has several additional features. These can be seen in the ethereal traffic. Q2.3: What does this transport protocol offer that UDP does not? Why might these be useful to VoIP applications? Save the ethereal capture for use in the next section. Now we will analyze another VoIP implementation. Copy the ciscophone.dump file from the installation source. Load it in ethereal. Take a look at how Skinny works. SCREENSHOT 2.3: Take a screenshot of the Skinny signaling phase. Q2.4: How does Skinny differ from SIP? Section 3: Reassembling the Conversation Most VoIP implementations do not utilize any encryption or authentication. Linphone and the SIP Express Router (in Section 5) do not either. Because of this, it is possible to use our captured traffic to reconstruct the unencrypted VoIP session. Luckily, a utility is available to make this task easier. The utility is called Vomit and is freely available. To build Vomit, copy the four relevant tarballs from install source. Extract both libraries and install them. Then proceed to build Vomit and finally waveplayer. These directions should guide you through the process: 1 cd labtest/ 2 ls 3 cp -r /media/LEXAR_MEDIA/labstuff/vomit . 4 ls 5 cd vomit/ 6 ls 7 tar xvfz libdnet-1.10.tar.gz 8 cd libdnet-1.10 9 ./configure && make && make install 10 cd .. 11 ls 12 tar xvfz libevent-1.1a.tar.gz 13 cd libevent-1.1a 14 ./configure && make && make install 15 ln -s /usr/local/lib/libdnet.so.1 /lib/libdnet.so.1 16 ln -s /usr/local/lib/libevent-1.1a.so.1 /lib/libevent-1.1a.so.1 17 cd .. 18 tar xvfz vomit-0.2c.tar.gz 19 cd vomit-0.2c 20 ./configure && make && make install 21 cd .. 8
  • 9. 22 ls 23 tar xvfz waveplay-20010924.tar.gz 24 cd waveplay-20010924 25 make && make install 26 cd .. Now that vomit is built, we need to recover the conversation from our dump file. Run vomit against the source and pipe the output to the waveplayer. ./vomit-0.2c/vomit -r CAPTURE.DUMP | ./waveplay-20010924/waveplay-20010924/waveplay -S8000 -B16 -C1 CHECKOFF 3.1: Get a TA to sign-off that you have completed this section by playing them your conversation. Section 4: Disconnecting a Client Boot a Windows XP virtual machine (you should have one from a previous lab). Copy the Java Runtime Environment and the Sivus installer from the install source (CD or fileserver). Now run the JRE executable and install the runtime environment necessary for Sivus. After finishing, execute the Sivus installer. Now you will start a packet capture (in ethereal on Alice’s computer) and new VoIP session between Alice and Bob. 1) On Alice’s machine, start Ethereal to capture all traffic from eth0. 2) Perform the call establishment procedure from Section 1 again. 3) After call begins, stop packet capture 4) Find the SIP Dialog Establishment packet in ethereal 5) When you have found this packet, select it 6) SCREENSHOT 4.1: Take a screenshot of the dialogue establishment packet. 7) Leave the VoIP conversation open You will notice that this packet contains all the fields that are required to uniquely identify a SIP session. A SIP session can be terminated by constructing a BYE packet using these fields. In fact, you are about to do just that. Q4.1: What fields do you think are relevant for uniquely identifying a conversation packet? With this information, you can now attack the ongoing VoIP conversation. You will start ethereal to analyze what you did after the attack. 1) Start ethereal on Alice’s machine again. 2) Start the sivus program on your Windows virtual machine. 3) Go to SIP->Utilities->Message Generation tab once sivus loads. 4) Select the BYE method and use your information from Q4.1 to attempt to end the conversation. 9
  • 10. 5) Click Start to launch the attack. 6) You will know you are successful when the VoIP conversation terminates. 7) Return to Ethereal and find the packet responsible for your denial-of-service 8) SCREENSHOT 4.2: Take a screenshot of the Sivus-constructed packet in ethereal. Q4.2: What fields did you find were sufficient to terminate the VoIP session? Q4.3: How can SIP be secured to prevent this type of attack? What mechanisms must be in place to do so? Section 5: Building and Using SIP Proxies You will install the SIP Express Router (SER) software in this section. You will create two new VMWare images for two new RHEL4 WS virtual machines. Follow the same directions as Lab1 on the first image. If you already have a RHEL4 WS VMWare image, you may use Redhat’s utility to add them. It is accessible under Applications->System Settings->Add/Remove Aplication. You will need the CDs in either case. Copy the SER source from the install location (CD or fileserver). Extract the source and build it. 1 ls 2 cp -r /media/LEXAR_MEDIA/labstuff/ser/ . 3 cd ser/ 4 ls 5 tar xvfz ser-0.9.4_src.tar.gz 6 make 7 ls 8 cd ser-0.9.4 9 ls 10 vim INSTALL 11 make 12 make install You will clone the image you just installed SER under. After installing SER, power down your machine. Right-click the image name tab and select Clone. This clone will be the second SIP proxy. Now start both VMWare images. Assign the machines unique IP addresses and start ser in a shell. Both machines should now be running a SIP proxy. SCREENSHOT 5.1: Take a screenshot of ser running on one of the virtual machines. Q5.1: What port and protocols does ser listen on? 10
  • 11. Now we will configure the clients to use the proxies. There is a simple registration process. Load linphone and click Go->Preferences and select the SIP tab. Add a new SIP proxy and fill the form in. You will now capture the SIP registration process and establish a call using the proxies. 1) Start ethereal on Alice. Capture all traffic on eth0. 2) Restart both linphone clients on Alice and Bob. The client should notify you at the bottom of the application when it successfully registers with the proxy. 3) In Alice’s Sip address field, enter bob@bobproxy.com. Initiate the call to Bob. You should see a Connected status and hear his voice. 11
  • 12. 4) Answer the call on Bob’s end. Speak for a few seconds and then Hangup the call. 5) Stop the packet capture but leave ethereal open. 6) SCREENSHOT 5.2: Highlight the registration packet in the ethereal capture and take a screenshot. Q5.2: Describe the registration procedure in your own words, based on your captured traffic. Q5.3: What mechanism, if any, did you observe that authenticated the registration? What would be required to forge a registration? Section 6: Registration Denial-of-Service As you saw in Section 5, SIP user registration is unauthenticated. The user registration removal mechanism is also unauthenticated. This portion of the lab will guide you through constructing a packet that will remove all the registration bindings from the SIP proxy. 1) Start ethereal on Alice. Capture all traffic on eth0. 2) Open sivus on your Windows virtual machine. 3) Go to SIP->Utilities->Message Generation tab once sivus loads. 4) Set the following fields to their non-default values: Called User: bob Domain/Host: Bob’s proxy’s IP address Contact: * Expires: 0 5) Click Start to send the packet. 6) Now attempt to call Bob from Alice via Bob’s proxy. You will be notified that the user is not available. 7) SCREENSHOT 6.1: Take a screenshot of the successful Sivus parameters. 12
  • 13. 8) Stop the ethereal capture but do not close it. 9) SCREENSHOT 6.2: Take a screenshot of the ethereal capture. Q6.1: What would be required for the SIP proxy to prevent this attack? Q6.2: What scenarios can you envision that utilize this attack? Section 7: Future Lab Additions Several lab additions are possible. 1) Utilize various types of VoIP equipment. The student should perform the same call establishment, interception, and conversation recovery procedure on several vendors’ products. Specifically, a pair of Cisco VoIP phones and a call manager would be interesting. The lab format could be similar to the wireless security lab where students signed up for a time to do the lab with a pair of configured equipment 2) There are several other SIP exploits possible. SIP user registration can be hijacked. For example, an unauthenticated SIP proxy could be running customer support for a company. An attacker could hijack the accounting user and redirect all calls to his address. The attacker could then gain confidential information from the customer. 3) Deploy and utilize stronger authentication features. This may require software licensing or additional hardware purchases. There might also be a few open-source software products that can do this (Asterisk comes to mind). Perhaps integrate the SIP proxy into other common access control servers (a AAA serve like Radius or Kerberos). 4) Integrate VoIP into parts of a VPN lab. Since most companies deploy VoIP on top of a secured network, it might be interesting to perform the conversation reassembly demo after breaking into a VPN. Section 8: Tool URLs linphone - http://www.linphone.org/?lang=us&rubrique=1 libosip - http://www.gnu.org/software/osip/ speex - http://www.speex.org/ vomit - http://vomit.xtdnet.nl/ libnet - http://libdnet.sourceforge.net/ libevent - http://www.monkey.org/~provos/libevent/ waveplayer - http://sore.totto.to/~ysonoda/FreeBSD/ports/ ser - http://www.iptel.org/ser/ ethereal - http://www.ethereal.com/ 13
  • 14.  Answer Sheet Lab 11 Group Number: _______________ Member Names: _________________________     _________________________ Section 2: Intercepting/Analyzing Direct Traffic Q2.1: What signaling protocol does linphone use (from the protocol analyzer)? Is this a binary or ASCI protocol? Q2.2: What transport protocol does linphone use? What controlling protocol did this utilize? Q2.3: What does this transport protocol offer that UDP does not? Why might these be useful to VoIP applications? Q.4: How does Skinny differ from SIP? 14
  • 15. Section 3: Reassembling the Conversation CHECKOFF 3.1: Get a TA to sign-off that you have completed this section by playing them your conversation. Section 4: Disconnecting a Client Q4.1: What fields do you think are relevant for uniquely identifying a conversation packet? Q4.2: What fields did you find were sufficient to terminate the VoIP session? Q4.3: How can SIP be secured to prevent this type of attack? What mechanisms must be in place to do so? 15
  • 16. Section 5: Building and Using SIP Proxies Q5.1: What port and protocols does ser listen on? Q5.2: Describe the registration procedure in your own words, based on your captured traffic. Q5.3: What mechanism, if any, did you observe that authenticated the user registration? What would be required to forge a registration? Section 6: Registration Denial-of-Service Q6.1: What would be required for the SIP proxy to prevent this attack? 16
  • 17. Q6.2: What scenarios can you envision that utilize this attack to collect sensitive information? How long did it take you to complete this lab? Was it an appropriate length lab? What corrections and or improvements do you suggest for this lab? You may cross  out   and   edit   the   text   of   the   lab   on   previous   pages   to   make   corrections.   What  corrections and or improvements do you suggest for this lab? Please be very specific  and if you add new material give the exact wording and instructions you would give  to future students in the new lab handout. You need to be very specific and provide  details.   You   need   to   actually   do   the   suggested   additions   in   the   lab   and   provide  solutions to your suggested additions. Caution as usual: only extract and use the  tools you downloaded in the safe and approved environment of the network security  laboratory. Turn­in Checklist Answer Sheet Screenshots TA Checkoff o TA:_______________ Date:_________ 17

×