VoIP Security: Final LabGroup 26

Fall 2005 ECE4112 Henry Owen

Michael NorrisBrian DiRito

8 December 2005

1

ECE 4112 Internetwork SecurityFinal 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

2

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

3

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

4

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.

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.Abob.com 57.35.6.Baliceproxy.com 57.35.6.Cbobproxy.com 57.35.6.D

Where A, B, C, and D correspond to the appropriate IP addresses you choose.

5

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

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?

7

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

8

20 ./configure && make && make install 21 cd .. 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 capture4) Find the SIP Dialog Establishment packet in ethereal5) When you have found this packet, select it6) 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.

9

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-service8) 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.

10

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 bob@bobproxy.com. Initiate the call to Bob. You should see a Connected status and hear his voice.

11

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: bobDomain/Host: Bob’s proxy’s IP addressContact: *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.

12

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

13

ethereal - http://www.ethereal.com/

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?

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?

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?

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

18