VoIP Security - Final Lab | Internetwork Security | ECE 4112, Lab Reports of Electrical and Electronics Engineering

Download VoIP Security - Final Lab | Internetwork Security | ECE 4112 and more Lab Reports Electrical and Electronics Engineering in PDF only on Docsity!

VoIP Security: Final Lab

Group 26

Fall 2005 ECE4112 Henry Owen

Michael Norris

Brian DiRito

8 December 2005

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 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

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 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 RHEL 4 WS VM alice.com RHEL 4 WS Host bobproxy.com RHEL 4 WS VM Eve WinXP VM ` bob.com RHEL 4 WS Host

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.

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. 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. 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. 16 ln -s /usr/local/lib/libevent-1.1a.so.1 /lib/libevent-1.1a.so. 17 cd .. 18 tar xvfz vomit-0.2c.tar.gz 19 cd vomit-0.2c

4. Select the BYE method and use your information from Q4.1 to attempt to end the conversation.
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. 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? 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 [email protected]. Initiate the call to Bob. You should see a Connected status and hear his voice.

7) SCREENSHOT 6.1: Take a screenshot of the successful Sivus parameters.

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= 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/

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?

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?