VoIP The Next Generation of Phreaking Revision 1.1

Ofir ArkinManaging Security Architect

VoIP The Next Generation of Phreaking

Revision 1.1

© 2 0 0 2 @ S T A K E , I N C .

2

Agenda

Overview

An Introduction to VoIP

Challenges Facing VoIP and their relation to Security

Media Transport - Examining RTP, RTCP and Security

Signaling – The Session Initiation Protocol as an example

“What a call worth If you can’t speak Mr. Anderson?”

Examples with VoIP and Security

© 2 0 0 2 @ S T A K E , I N C .

3

“...It is no longer necessary to have a separate network for

voice...”

Overview

The fact that IP is the vessel for voice transmission, inherits the security problems that comes along with the Internet Protocol.

The security hazards are even more complex because of the nature of speech (voice quality), and other special conditions the VoIP technology needs to meet in order to fulfill its promise as a new emerging technology for carrying voice.

© 2 0 0 2 @ S T A K E , I N C .

4

OverviewSome security issues arise from Media Transport protocols (RTP, RTCP, SCTP) being used to carry voice, some security issues arise from Signaling protocols (SIP, H.323, MEGACO, MGCP) and their respected architecture (the placement of the “intelligence”, as an example) which are being used, and other issues arise from the different components that combine a VoIP architecture. We will also examine supporting protocols, such as Quality of Service (QoS) protocols. We can even name physical security as another source for concern.

VoIP has a wide range of deployment scenarios, hence a wide range of security

problems reflecting these scenarios.

© 2 0 0 2 @ S T A K E , I N C .

5

A Definition of VoIPWe can define VoIP simply as “the transport of voice traffic using the Internet Protocol”. Stating “using the Internet Protocol” associates the usage of the Internet in the mind of many people. But the matter of fact is that Internet Telephony is only a portion of VoIP, and VoIP has a broader definition. To remove any shreds of a debut we define VoIP as “the transport of voice traffic using the Internet Protocol utilizing any network”.

© 2 0 0 2 @ S T A K E , I N C .

6

Protocols Combining a VoIP Solution

Protocol Types:

Signaling – Protocols in which Establish, Locate, Setup, Modify and Teardown sessions.

Media Transport – Protocols which transmit the voice samples.

Supporting (Services) – DNS, Location Servers, QoS, Routing Protocols, AAA…

© 2 0 0 2 @ S T A K E , I N C .

7

Protocols Combining a VoIP Solution

SIP IP Phone

SIP IP Phone

Location Service

SIP Proxy

SIP Proxy

DNS Server

Media Transport

1

2

3

4

5

6

A request is sent (SIP INVITE) to ESTABLISH a

session

DNS Query for the IP Address of the SIP Proxy of the Destination

Domain The INVITE is forwarded

The Location Service is being queries to check that the destination IP address

represents a valid registered device, and for its IP

Address

The request is forwarded to the End-Device

Destination device returns its IP Address to the

originating device and a media connection is opened

© 2 0 0 2 @ S T A K E , I N C .

8

Signaling SIP (IETF) H.323 (ITU-T) MGCP (IETF) MEGACO

Media Transport RTP and RTCP (IETF) SCTP (IETF)

Supporting Services DNS Routing - TRIP (Telephony Routing over IP) Quality of Service – RSVP, 802.1q

Examples for Protocols Combining a VoIP Solution – It is a Zoo Station

© 2 0 0 2 @ S T A K E , I N C .

9

Why Replacing the Current Infrastructure of Telephony? – A Carrier PerspectiveTwo separate reasons:

- Technology is Advancing: Circuit switching is not suitable to carry anything else than voice, it does not qualify as a suitable technology for the new world of multimedia communications (Video, Email, Instant Messaging, the World Wide Web, etc.). Traditional Telephony cannot provide, for example, the types of features that are needed by a contemporary business in the advancing age of e-Commerce. - The $ Factor

Subscribers would still like to use the telephone for making and receiving phone calls, but they would also like to have the ability to use the telephone to interact easily with other applications, and to easily use new services.

© 2 0 0 2 @ S T A K E , I N C .

10

Why IP? Carrier Perspective – Lower Equipment Costs

Traditional Telephony:

Proprietary hardware, application software and operating system when purchasing a telephony switch. One Vendor usually supplying the entire equipment for the whole network The Vendor will also supply with training support and future development for its equipment. This will bind the operator with the supplier for a long term of time, since it is not cost effective to replace the equipment. It will also limit the opportunities for 3rd parties to develop new software applications for these systems.

© 2 0 0 2 @ S T A K E , I N C .

11

Why IP? Carrier Perspective – Lower Equipment Costs

IP:

In the IP world most of the equipment is standard computer equipment which is mass produced. This offers great flexibility for the purchasing party. One company can supply the hardware, another can supply the operating system, and another can develop special features. Several companies can be hired to supply different systems for the network.

Because of the distributed client server architecture of IP, operators have the ability to start small and grow.

© 2 0 0 2 @ S T A K E , I N C .

12

Why IP? Carrier Perspective – Lower bandwidth requirements

Unlike traditional telephony that is limited to the usage of the ITU recommendation G.711 based codec, and therefore transport voice at the rate of 64kbps, VoIP can use other sophisticated coding algorithms that will enable speech to be transmitted at speeds such as 32kbps, 16kbps, 8kbps, 6.3kbps, or even 5.3kpbs. Some VoIP based protocols are also able to negotiate an accepted coder scheme to be used, enabling the usage of more than one coder scheme and the ability to introduce new coders in the future.

Taking into account that a large portion of a carrier’s operational costs is it’s transmission capabilities, VoIP can significantly reduce bandwidth requirements to as little as one-eighth of what is used today in the circuit switched world, and therefore make a significant bandwidth and money savings.

© 2 0 0 2 @ S T A K E , I N C .

13

Why IP? Carrier Perspective

More business opportunities and revenue potential “Show me the money Jerry!” Introducing new services to Telephony subscribers The time-to-market of new services New Technology brings new comers to the market (good?) Integrating Voice and Data applications

© 2 0 0 2 @ S T A K E , I N C .

14

Why IP? User Perspective – Corporate Users

One of the fastest growing markets for VoIP is the enterprise LAN. More and more enterprise LANs are carrying both Voice, Video and Data.

More and more large organizations, especially in North America, are using IP based dedicated leased lines between different branches of the company to carry not only data but voice and video. Using this way, these companies are saving the costs of long distance calls using traditional telephony. The leased lines can also be used for video conferencing and for other usages that will bring significant cost savings for an organization.

© 2 0 0 2 @ S T A K E , I N C .

15

Why IP? User Perspective - Consumers

Consumers might have several other reasons behind the usage of IP to carry voice, rather than a Carrier Grade Telephony Operator, or a corporate user.

Lower Bandwidth Requirement – VoIP can use several sophisticated coding algorithms that will enable speech to be transmitted at speeds such as 32kbps, 16kbps, 8kbps, 6.3kbps, or even 5.3kpbs. VoIP based protocols are able to negotiate an accepted codec scheme to be used, enabling the usage of more than one coder scheme and the ability to introduce new codecs in the future. These abilities present the End-User of the ability to use the Internet and VoIP technology to make voice conversations with any other PC User connected to the Internet. This is also one of the usages of Internet Telephony.

© 2 0 0 2 @ S T A K E , I N C .

16


Significant Cost Savings - For consumers the introduction of VoIP not only brings more added value services when they use their telephone. It also brings the opportunity to have significant cost savings in the cost of phone calls. Today consumers can use an ordinary telephone to connect to an Internet Telephone Service Provider (ITSP).

The ITSP is using IP to provide low cost Voice/Fax connections through combinations of the Internet, leased lines, and the PSTN. All the ITSP has to do is to use an equipment to convert the voice to data, transport the data, and convert it back to voice. The cost reduction for the ITSP comes from the usage of the Internet as the voice transport vessel. The ITSP does not have to build a full blown telephony infrastructure.

© 2 0 0 2 @ S T A K E , I N C .

17


ITSPs also connect PC users to traditional telephony users. Here the costs savings are even more considerable both to the ITSP and for the consumer (the ITSP is not required to pay for interconnect from the User side). Using such an ITSP service can reduce phone call costs considerably.

For example, on calls made between the United Kingdom to Israel instead of paying 1.7GBP per minute with traditional telephony, paying only 0.055GBP per minute when using an ITSP.

© 2 0 0 2 @ S T A K E , I N C .

18

Challenges Facing VoIP

Speech Quality

Delay/Latency Jitter Packet Loss Speech Coding Techniques

Network Availability, Reliability and Scalability [Carrier] Managing Access and Prioritizing Traffic [Carrier] Security [All]

© 2 0 0 2 @ S T A K E , I N C .

19

Problems Facing VoIP – Speech Quality

Speech quality is affected by many different technical attributes. We can name, for example, the codec used, system latency, jitter, packet loss, and other.

Usually the codec chosen will be an industry standard. Therefore latency becomes one of the most important attribute affecting voice quality.

© 2 0 0 2 @ S T A K E , I N C .

20


Latency/DelayWith VoIP we define latency as the interval it takes speech to exit the speaker’s mouth and reach the listener’s ear. This definition is also known as “one way latency” or “mouth-to-ear latency”. Typically latency is measured by milliseconds. The sum of the two one-way latency figures is also known as the round trip latency. ITU-T recommendation G.114 specifies that in order to have a good quality of voice, the round-trip delay should not exceed 300ms.

© 2 0 0 2 @ S T A K E , I N C .

21


We can name several reasons for delay with VoIP that are inherited from the usage of IP based networks:

Packetization/Voice Coding and Transmission Delay – The time it takes to pack and send a voice sample. Handling Delay – The time it takes to process a packet. Queuing Delay – The time it takes to be queued. Convergence Delay – The time it takes to convert VoIP based traffic to its PSTN equivalent and vise versa.

© 2 0 0 2 @ S T A K E , I N C .

22

Problems Facing VoIP – Speech Quality: Jitter

We can define jitter as delay variation. If we experience a delay in a conversation, there are methods to adjust this delay, provided that the delay is not too big. If the delay varies than adjusting the delay becomes a harder task.

© 2 0 0 2 @ S T A K E , I N C .

23

Problems Facing VoIP – Speech Quality: Packet LossIn order to have a high speech quality we need that little to none of the speech samples being transmitted from the speaker to the listener will be lost. However, with data networks it is expected, and common, to have packet loss. One of many reasons might be a congest network, and so on.

With voice, we cannot use traditional retransmission mechanisms when packets are lost, since voice is delay sensitive. These retransmission mechanisms will introduce additional latency to the process (UDP vs. TCP). Time is needed to determine that a packet was lost, and time is needed to retransmit the missing packet.

With VoIP we can suffer packet loss up to 5% of the traffic exchanged. But still the packets which were lost cannot be successive packets. If a packet is missing the listener’s system must carry on without that packet.

© 2 0 0 2 @ S T A K E , I N C .

24

Problems Facing VoIP – Speech Quality: Packet Loss

Packet loss may affect codecs differently, since codecs compress the audio data in different ways. A codec which do little compression will loose a smaller portion of the audio compared to a codec which is using an advanced compression scheme to use less bandwidth. Therefore the affect on the voice quality will also be different.

Another problem we can raise is the out of sequence arrival of voice sample carrying packets. We need to ensure that speech is received at the other end as transmitted. Otherwise packets will be presented to the listener out-of-order, or discarded…

A way to deal with some of these problems is the usage of Quality of Service (QoS) based mechanisms (where you can…).

© 2 0 0 2 @ S T A K E , I N C .

25

Problems Facing VoIP – Speech Quality: Speech Coding Techniques

If speech sounds synthetic, the latency prevention, bandwidth reduction and packet loss minimization techniques will be useless. The speech coding technique selected should reduce bandwidth while still maintaining a good quality of speech. We can make a rough statement and claim that the lower the bandwidth requirements of a certain codec, the lower the voice quality produced. Also, a better voice quality is usually using a more complex algorithm and therefore more processing power is needed.

This does not mean that there are no codecs which produce a good quality of speech without high bandwidth requirements.

© 2 0 0 2 @ S T A K E , I N C .

26

Voice Quality with Internet Telephony

With Internet Telephony voice quality issues are the most problematic to overcome. The problem is that the Internet is not a network where one can prioritize traffic or preserve bandwidth. We can name packet loss, congestion, delays, and reliability as other venues of troubles for voice quality, which adds to the overall problem of voice quality with Internet Telephony.

We need not forget that with the Internet, which is a packet switched network, packets may take different routes to a destination. This means that voice samples may arrive out of order at the receiver side. It also increases the chances of packet loss.

© 2 0 0 2 @ S T A K E , I N C .

27

Problems Facing VoIP – Network Availability, Reliability and Scalability Carrier Grade Telephony networks are available 99.999% of the time. This means a downtime of only 5 minutes per year. Carrier Grade Telephone operators who wish to rely on VoIP based technology to offer telephony services are required to have the service available exactly as it is today – 99.999% of the time. Every time you will wish to use your VoIP based telephony service, you will have to have a service when picking up the telephone’s handset (a dial tone and the ability to complete a call).

The VoIP core network is required to be resilient and redundant. For other parts of the network, it depends on the network architecture and infrastructure. There are numerous problems of availability at the edge of the network. These problems relate to the way the last mile in a VoIP based telephony network is built.

© 2 0 0 2 @ S T A K E , I N C .

28

Problems Facing VoIP – Network Availability, Reliability and Scalability A Carrier Grade VoIP network is required to be scalable and to support hundred of thousands of concurrent connections/calls as it is today with circuit switched telephony networks. A VoIP based network also needs to maintain the ability to grow with demand and to be scalable. As was mentioned in previous sections, a VoIP based network is able to start small and expend as demand for bandwidth and service increases.

IPIP

POTSPOTS

FaxFax

ModemModem

PCPC

Gateway

a/b

a/b

a/b

100BaseT

100BaseT

100BaseT Switch

© 2 0 0 2 @ S T A K E , I N C .

29

Problems Facing VoIP – Network Availability, Reliability and Scalability

© 2 0 0 2 @ S T A K E , I N C .

30

Problems Facing VoIP – Managing Access and Prioritizing Traffic With VoIP based networks Voice, Data, and Video share the same network. Voice and Data has their own quality requirements, and must not be treated the same way within the network.

Bandwidth must be preserved to Voice, so whenever a subscriber wishes to place a call he will be able to do so, and the appropriate bandwidth will be assigned to its call. If large data transfers occur at the same time, priority must be given to the voice traffic over the data traffic. So voice traffic will not be queued back, and latency and packet loss will occur. This means that the most critical traffic, voice, will not be affected from a congested network.

In order to be able to prioritize traffic and reserve bandwidth VoIP based networks will have to use quality of service (QoS) based solutions.

© 2 0 0 2 @ S T A K E , I N C .

31

Problems Facing VoIP – Security

The wide availability of IP does not only contribute to the VoIP technology widespread, but also inherits the security hazards along with it.

The fact that data and voice share the same network is the root of some of the security problems associated with VoIP. The fact that IP is the vessel for voice transmission, inherits the security problems that comes along with usage of the Internet Protocol. The security hazards are even more complex because of the nature of speech within VoIP networks, and other special conditions VoIP needs to meet. We can mention resource starvation attacks, session hijacks, and session manipulation, as examples of attacks on VoIP based networks resulting from the usage of IP for transporting voice.

© 2 0 0 2 @ S T A K E , I N C .

32


Old school security problems are not the only security problems which VoIP is facing. Some security issues arise from media transport protocols being used to carry voice, some security issues arise from signaling protocols and their respective architectures (the placement of the “intelligence”, as an example) which are being used, and other issues arise from the different components that combine a VoIP architecture. Even supporting protocols, such as quality of service protocols have their security issues. We can even name physical security as another source of concern.

© 2 0 0 2 @ S T A K E , I N C .

33


We need not to forget another major factor which is the fact that signaling and voice are sharing the same networks. Because most of the VoIP based signaling protocols are used in-band, another venue for trouble is opened.

VoIP has a wide range of deployment scenarios, hence a wide range of security problems reflecting those scenarios.

© 2 0 0 2 @ S T A K E , I N C .

34


Another concern with VoIP based networks is that an end-user maintains the ability not only to place a call, and interact with his own switch, but has the ability to interact with some other parts of the infrastructure as well. This includes other networking devices combining the network, protocols being used whether media transport protocols or signaling protocols, the TCP/IP protocol suite, etc.

Some of the VoIP based protocols gives an end-user a broader options to interact with the network, not only using features, but also because the intelligence is at the edge (the telephone itself).

Those risks put in danger network availability, and voice quality. Not even mentioning other issues such as fraud, and phreaking.

There are a lot of constraints a carrier grade VoIP based operator needs to put on his VoIP based network in order to eliminate some of these risks.

© 2 0 0 2 @ S T A K E , I N C .

35

VoIP Security – What is at stake?

Everything…

From IP Phones to Core Routers through Media Gateways, SIP Proxies, Gatekeepers, Location Servers, Routers, Switches, VoIP based Firewalls…

Any Equipment combining a VoIP infrastructure of some sort.

Any Protocol used whether a signaling protocol (SIP, H.323, MEGACO, MGCP) or used to carry the voice samples (RTP, RTCP). Taking advantage of the protocols themselves is in my opinion the name of the game.

Any TCP/IP protocol used

© 2 0 0 2 @ S T A K E , I N C .

36

VoIP Security – Physical Security

With a 4th Generation Carrier the Last-Mile is the main concern:

The main concern is with Access to the Physical Wire (and to equipment). If achieved all is downhill from there (this holds true for any architecture using VoIP as well).

Equipment is likely to be stolen Routers and switches are nice decorations for a room.

Physical Tempering - “Cut the cord Luke”

© 2 0 0 2 @ S T A K E , I N C .

37


Voice

Voice

Data

Data

Packet Shaping for QoS (DiffServ)

My Hub (is your Hub)

Bypassing simple packet shaping mechanisms.

Getting into the Voice VLAN: End-of-Game.

© 2 0 0 2 @ S T A K E , I N C .

38


IP PhoneIP Phone

PCPC

IP PhoneIP Phone

PCPC

100BaseT Hub

100BaseT Switch

100BaseT Switch

100BaseT Switch

100BaseT

100BaseT

100BaseT

100BaseT

100BaseT

100BaseT

Eavesdropping can be done easily if there is access to the wire, with no specialized equipment other than a hub, a knife, and a clipper.

-Between the IP Phone (or Customer Premises Gateway) and the Switch-Between two switches

With both scenarios we bypassed any QoS mechanism used.

© 2 0 0 2 @ S T A K E , I N C .

39

VoIP Security – Physical SecurityFree Phone Calls

An “Advantage” Over Phreaking of this sort because the eavesdropper can also have free calls without the knowledge of the subscriber…

Using Call-ID to differentiate between calls destined to the phreaker to the calls destined to the owner of the line.

I am representing the physical

address of the IP Phone

I am representing the physical

address of the Switch

© 2 0 0 2 @ S T A K E , I N C .

40

VoIP Security – Availability

Availability & Redundancy

No Electricity No Service. “G, here goes our Carrier Grade availability…”

Costs of redundancy, and UPSs for every switch and router at the last mile…

Denial-of-Service - Even more easy with VoIP, since you really do not need to be that smart and use too much traffic, but still you can cause outage in the whole network, a neighborhood, or a building, or on a single end-user.

© 2 0 0 2 @ S T A K E , I N C .

41

VoIP Security – Availability

To perform a denial-of-service you might use several venues:

Flood (G what is new with that?) Abuse the protocols themselves – Introduce denial-of-service conditions taking advantage over the protocols used to do VoIP (examples later).

The type of devices one might target are, for example:

IP Phones (Easy) Routers, Switches (depends on the equipment) Signaling Gateways, Media Gateways, SIP Proxies… (Easy-Medium) Any device in the path a call takes from a caller to a called party

© 2 0 0 2 @ S T A K E , I N C .

42

Media Transport – RTP

4 bitVersion

4 bitHeaderLength

8-bit type of service 16-bit total length ( in bytes )

16-bit identification3 bit

Flags 13-bit Fragment Offset

8-bit time to live( TTL ) 8-bit protocol 16-bit header checksum

32-bit source IP address

Options ( if any )

32-bit destination IP address

16-bit Destination Port

20 bytes

8 bytes

0 8 16 314

16-bit Source Port

SSRC

16-bit UDP Length 16-bit UDP Checksum

Timestamp

Sequence NumberPTCC MXPV

CSRC

Identifies the source of an RTP stream

Used by a receiver to

detect packet loss (also can be used to restore

packet sequence). Indicates the instant at

which the first byte in the RTP payload was

generated. The timestamp is used to place RTP

packets in a correct timing order

© 2 0 0 2 @ S T A K E , I N C .

43

Media Transport – RTP Security Issues

Denial of Service

The Way RTP Handles SSRC Collisions Sending command using SSRC of another participant of a session. Result – The ability to drop users from a certain session

Claiming SSRC of a user Result: Transmission will stop, new selection of SSRC needs to take place and the transmission should resume.

Why shutdown when we can have some fun? – Same SSRC, higher sequence number, higher timestamp. The fake content will be played before the real one. This means that from now on we will be able to play what ever we wish to this side of the conversation since all the next transmissions of the other side will look “old” to the receiving party…

© 2 0 0 2 @ S T A K E , I N C .

44


Dodge this - Changing of audio encoding during a session. This can be used to temper with Voice Quality, either using a low quality codec, or using a higher quality codec that will jam the pipe.

Encryption

DES – Breakable (like other technologies and products…)

If SIP is used the DES Key is sent in the clear with SDPs “k” parameter…

Actually introducing more delay and jitter, so who wants to use this anyway?

© 2 0 0 2 @ S T A K E , I N C .

45


Mix This You Foo (Tricking “Mixers” to mix whatever from wherever)

64kbps 128kbps

128kbps 128kbps

Mixer

64kbps 64kbps

64kbps 64kbps

Mixer

Too much to handle for one IP Phone when receiving traffic from 3 sources at

64kbps

Different link speeds connected to a conference

© 2 0 0 2 @ S T A K E , I N C .

46


Changing a used codec in the middle of the session – sometimes happens automatically when the network suffers from congestion. By forging a voice codec change, not only reducing quality of voice, it might also introduce other problems as denial-of-service, crash of end systems, etc.

Eavesdropping – Since RTP identifies the codec being used (statically) or either using a “dynamic” identified codec it is easy to reconstruct the voice sampling (even in real time).

© 2 0 0 2 @ S T A K E , I N C .

47

Media Transport – RTCP Security Issues

Forging Reception Reports

Reporting more Packet Loss – Might lead to the usage of a poor quality codec with an adaptive system. Report more Jitter - Might lead to the usage of a poor quality codec with an adaptive system.

Denial of Service

RTCP “BYE”, not in sync with the Signaling protocol. The Signaling protocol is not aware that there is no exchange of voice samples any more…

© 2 0 0 2 @ S T A K E , I N C .

48

SIP (Session Initiation Protocol)

“The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. These sessions include Internet multimedia conferences, Internet telephone calls and multimedia distribution. Members in a session can communicate via multicast or via a mesh of unicast relations, or a combination of these”.

Taken from RFC 2543

© 2 0 0 2 @ S T A K E , I N C .

49

SIP Design & Methods

A client-server based protocol modeled after HTTP Building Blocks are Requests and Responses

The Methods are:

INVITE – Session Setup Initiate Sessions Re-INVITEs used to change session state

ACK – Confirms INVITE sessions BYE – Terminate Sessions CANCEL –Pending session cancellation OPTIONS – Capability and options Query REGISTER – Binds Address to Location

Clinet Server

Request

Response

© 2 0 0 2 @ S T A K E , I N C .

50

SIP Components

SIP UAC – SIP User Agent Client

SIP UAS – SIP User Agent Server

UA – UAC + UAS

SIP Proxy – Relays the Call Signaling without maintaining a state (although able to). Receives a request from a UA or another Proxy Server, and forwards or proxies the request to another location (The ACK and BYE are not required to go through the SIP Proxy Server).

SIP Redirect – Receives a request from a UA or a Proxy. The Redirect Server will return a 3xy response stating the IP address the request should be sent to.

SIP Registrar – Receives Registration requests, and keeps the user’s whereabouts using a Location Server.

© 2 0 0 2 @ S T A K E , I N C .

51

SIP Response Codes

Characteristics similar to HTTP:

1xy Information or Provisional (Request in progress but not yet completed):

100 Trying 180 Ringing 181 Call Forwarded

2xy Success (the request has completed successfully):

200 OK3xy Redirection (another location should be tried for the request):

300 Multiple Options 301 Moved Permanently 302 Moved Temporarily

© 2 0 0 2 @ S T A K E , I N C .

52

SIP Response Codes

4xy Client Error (due to an error in the request, the request was not completed . Can be retried at another location):

400 Bad Request 401 Unauthorized 482 Loop Detected 486 Busy Here

5xy Server Failure (the request was not completed due to error in recipient. Can be retried at another location):

500 Server Internal Error6xy Global Failure (request was failed and should not be retried again):

600 Busy Everywhere

© 2 0 0 2 @ S T A K E , I N C .

53SIP IP Phone

SIP IP Phone

DNS Server

SIP Proxy

SIP Proxy

Location Service

SIP IN

VITE

DNS Query for the IP Address of the SIP Proxy of the Destination

DomainFW: SIP INVITE

100 Try

ing

100 Trying

The Location Service is being queries to check that the destination IP address

represents a valid registered device, and for its IP

Address

FW: SIP INVITE

180 Ringing

180 Ringing

180

Ringin

g

200 OK

200 OK

200 OK

ACK

ACKACK

Both Way RTP Media

BYE

200 OK

SIP Architecture

© 2 0 0 2 @ S T A K E , I N C .

54

SIP Security – INVITE Example

INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP here.com:5060 From: BigGuy <sip:[email protected]> To: LittleGuy <sip:[email protected]> Call-ID: [email protected] CSeq: 1 INVITE Contact: <sip:[email protected]> Content-Type: application/sdp Content-Length: 147

v=0 o=UserA 2890844526 2890844526 IN IP4 here.com s=Session SDP c=IN IP4 100.101.102.103 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000

Predicted Values

Another hard to guess value

© 2 0 0 2 @ S T A K E , I N C .

55

SIP Security – Denial-of-Service

Simple Denial-of-Service against SIP when Using UDP Since UDP is asynchronous protocol, if one can guess the target network a caller is sending its SIP signaling over UDP to, sending an ICMP Error Message such as Port Unreachable, Protocol Unreachable, Network Unreachable or even Host Unreachable will terminate the signaling and the call in any state.

Using “CANCEL”s (see next 2 examples)

Using “BYE” (anytime)

© 2 0 0 2 @ S T A K E , I N C .

56

SIP Security – Denial-of-ServiceA is not making calls

A: SIP IP Phone

B: SIP IP Phone

C:Attacker

INVITE

CA

NC

EL

“The CANCEL request cancels a pending request with the same Call-ID, TO, From, and Cseq…”

© 2 0 0 2 @ S T A K E , I N C .

57

SIP Security – Denial-of-ServiceA is not receiving calls

A: SIP IP Phone

B: SIP IP Phone

C:Attacker

INVITE

CANCEL

© 2 0 0 2 @ S T A K E , I N C .

58

SIP Security – Call Tracking

Defined as logging of the source and destination of all numbers being called.

Capturing the DTMF among all the other voice traffic one will capture, will give the eavesdropper sometimes more information that can range from voice mail passwords (voicemail system number, mailbox number, and password), calling card information, credit card information, or any other data entered using DTMF.

With SIP we need to track the INVITE message. It will contain the source and destination of the call (With H.323 the H.225 call setup message which initiate a call, has the call source and call destination as part of the message). You can also log the time of the call, duration (start time of the invitation minus the release of line), and other useful bits and bytes.

© 2 0 0 2 @ S T A K E , I N C .

59

SIP Security – Call Tracking (Example)

INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP here.com:5060 From: BigGuy <sip:[email protected]> To: LittleGuy <sip:[email protected]> Call-ID: [email protected] CSeq: 1 INVITE Contact: <sip:[email protected]> Content-Type: application/sdp Content-Length: 147

v=0 o=UserA 2890844526 2890844526 IN IP4 here.com s=Session SDP c=IN IP4 100.101.102.103 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000

© 2 0 0 2 @ S T A K E , I N C .

60

SIP Security – Call Hijacking

INVITE is sent, the attacker sending a 3xy message indicating that the called party has moved, and will give his own forwarding address.

A: SIP IP Phone

B: SIP IP Phone

C:Attacker

INVITE

301 Moved PermanentlyINVITE’

© 2 0 0 2 @ S T A K E , I N C .

61

A: SIP IP Phone

C:Attacker

SIP Registrar

SIP Security – Call Hijacking

Registering address instead of other.[If requires authentication might use another type of attack]

I am user A and here is my IP Address

© 2 0 0 2 @ S T A K E , I N C .

62

SIP Security – SIP Authentication

Two Ways: UA to UA UA to Proxy/Registrar

Authentication Mechanisms: Basic Digest PGP (not any more)

Challenge Response Based

Responses can also be authenticated although not widely used

© 2 0 0 2 @ S T A K E , I N C .

63

SIP Security – SIP Authentication

When using Digest authentication one might use a reflection attack to gain unauthorized access to the network.

A different secret is needed to be used in each direction

© 2 0 0 2 @ S T A K E , I N C .

64

SIP Security – Encryption

Is not a magic solution for everything.

Signaling Encryption is “designed” to hide information from eavesdroppers. But still some information needs not to be hidden.

The other end might be able to see all the routing information and send it back to the caller (G, here goes another bright idea to the toaster).

© 2 0 0 2 @ S T A K E , I N C .

65

SIP Security – Encryption – Hide the Route Luke

IP Phone A

IP Phone B

Target – Hide the routing information (via header)

Problem – IP Phone B will need to route back to IP Phone A. Will be able to see all routing information before it sends responses to his local proxy.

SIP Proxy

SIP Proxy

SIP Proxy

SIP Proxy

© 2 0 0 2 @ S T A K E , I N C .

66

SIP Security – Encryption

It consumes time, and introducing another delay. Problem will be when users will be over charge for calls for the small delay it will introduce.

Law enforcement agencies will not permit this in a carrier, since they need to perform wiretapping, which is another criterion in being a carrier (the conversation will not be encrypted at least in part of it’s traversal).

ITSPs cannot encrypt – Over Delays

© 2 0 0 2 @ S T A K E , I N C .

67

SIP Security – Signaling & Media Transport

One of the functions of an H.323 gatekeeper is to provide authorization for each call to proceed. One of the authorization parameters is a parameter called allowed bandwidth which dictates to the H.323 terminals what is the bandwidth the gateway will allow them to use without sending a bandwidth request to the gatekeeper. SIP is using the same codecs as H.323, since they both use RTP and RTCP. SIP is able to throttle the sending rate in order to deal with network congestions, but it does not have a provisioning function like H.323 have with its gatekeeper. Therefore SIP is not able to control the bandwidth used for the call. This also suggests that RTP and RTCP take more liberty with SIP based implementations than with H.323 implementations.

© 2 0 0 2 @ S T A K E , I N C .

68

SIP Security – Signaling & Media Transport

This means for example that with SIP not only we can make the line congested, we can also fake reports, or even switch to another bandwidth consuming codec that will not fit the link between the two ends, and therefore its usage will raise the packet loss – and we will have a lower quality, or even a poor quality of voice.

SIP is not aware what happens at the Media Transport layer. This means that if we change the codec we are using through RTP, SIP will not be aware of this.

© 2 0 0 2 @ S T A K E , I N C .

69

SIP Security – Fooling Billing

SIP Proxy server is usually the one which is producing Call Detail Recording (CDR) for billing. This is because the SIP Proxy server is able to force all the signaling an end point is sending to go through the SIP Proxy server. This means that setup and tear-down signaling messages will go through the SIP Proxy server, so CDRs will be produced correctly.

In order to do so the signaling need to go through the SIP Proxy. This is not true when we are dealing with the actual transportation of the media. This means that there is no provisioning on the RTP/RTCP packets.

© 2 0 0 2 @ S T A K E , I N C .

70


A simple way to fool this mechanism is to hide the SIP signaling in RTP or in RTCP messages. This of course suggests that both ends to the communication will use modified applications that will understand how to parse the modified RTP/RTCP packets. One example for a modified RTCP packet might be one with a unique Packet Type field.

In this example case the SIP Proxy will not see any signaling exchanged between the two ends of the communication, although audio will pass between both ends and a “call” will proceed. Of course no billing information will be available.

© 2 0 0 2 @ S T A K E , I N C .

71

This example emphasis the need to understand who comes first, the chicken or the egg. In our case signaling comes first only than we need to allow RTP packets to be exchanged. This is a restriction which need to be put in any VoIP system based on the SIP protocol.

We can introduce this condition in a carrier VoIP based network as well. This will cause a total chaos


© 2 0 0 2 @ S T A K E , I N C .

72

This means that:

No user should be able to get to another user (unless calling him). The Default Gateway needs to be your local SIP Proxy (or who ever it is with your solution) No service will be available unless someone is authenticating (But you do not expect people to authenticate before using the service…).

Therefore it is more than a simple headache…

SIP Security – Thoughts

© 2 0 0 2 @ S T A K E , I N C .

73

SIP and Firewalls – Just to Illustrate the Problem

Today not working that well with VoIP protocols.

Especially NAT introducing a lot of problems, since IP addresses of source and destination might be in different parts of a message (not only in the IP header)

Signaling must control the opening of Media Stream “holes” in the firewall. If not free phone calls might take place. a.k.a. SIP Over RTCP/RTP or any other Signaling over RTCP/RTP.

Who was first? The Signaling or the Media Transport? The CANCEL or the INVITE? Etc.

© 2 0 0 2 @ S T A K E , I N C .

74

SIP Security – Other Issues

Intelligence at the End Point (There is no such thing as “Trusting the Client” or “Client Security”). Predicted information - Some of the field values information is 100% predicted accept for the call-id. Call-id needs to be selected randomly, so this will not be anticipated as well.

Fraud – What about putting our own Neighborhood SIP Proxy?

Path the Signaling and Media Streams takes

Supporting Protocols and Services QoS – DiffServ is easy to forge. 802.1q might follow the same path. DNS

The equipment/call managers is not aware of authorized phones.

Ofir ArkinManaging Security Architect

VoIP The Next Generation of Phreaking

Questions?

VoIP The Next Generation of Phreaking Revision 1.1

Documents

Transcript of VoIP The Next Generation of Phreaking Revision 1.1