DEGREE PROJECT IN ELECTRICAL ENGINEERING, SECOND CYCLE, 30 CREDITS STOCKHOLM, SWEDEN 2016
A reverse proxy for VoIP Or how to improve security in a ToIP network
GUILLAUME DHAINAUT
KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF ELECTRICAL ENGINEERING KTH Royal Institute of Technology Master’s Programme in Network Services and Systems - ANSSI
Guillaume Dhainaut 921006-5950 [email protected]
A reverse proxy for VoIP Or how to improve security in a ToIP network
Master’s Thesis Stockholm, February 24, 2016
Supervisors Pierre Lorinquer ANSSI Fabien Allard ANSSI Examiner Panagiotis Papadimitratos ([email protected]) KTH Abstract
The need for security is crucial in Telephony over IP (ToIP). Secure protocols have been designed as well as specific devices to fulfill that need. This master thesis examines one of such devices called Session Border Controller (SBC), which can be compared to reverse proxies for ToIP. The idea is to apply message filters to increase security. This thesis presents the reasons of SBC existence, based on the security weaknesses a ToIP network can show. These reasons are then used to establish a list of features which can be expected from a SBC and discuss its ideal placement in a ToIP network architecture. A test methodology for SBCs is established and used on the free software Kamailio as an illustration. Following this test, improvements of this software, regarding threats prevention and attacks detection, are presented and implemented.
Sammanfattning
Behovet av säkerhet är av avgörande betydelse i telefoni över IP (ToIP). Säkerhet- sprotokoll har utformats samt särskilda enheter för att uppfylla detta behov. Detta examensarbete undersöker en av sådana enheter som kallas Session Border Controller (SBC), vilket kan jämföras med omvända proxyservrar för ToIP. Tanken är att tillämpa meddelandefilter för att öka säkerheten. Denna avhandling presenterar orsakerna till SBC existens, baserat på de säkerhets svagheter en ToIP nätverk kan visa. Dessa skäl används sedan för att upprätta en förteck- ning över egenskaper som kan förväntas av en SBC och diskutera dess ideal placering i en ToIP nätverksarkitektur . En testmetodik för SBC är etablerad och används på fri programvara Kamailio som en illustration. Efter detta test, förbättringar av denna pro- gramvara, om hot förebyggande och attacker upptäcka, presenteras och genomförs.
i Acknowledgements
This research was supported by ANSSI (French Network and Information Security Agency) in Paris. They offered me helps and materials. I owe my gratitude to Pierre Loriquer and Fabien Allard which were my ANSSI supervisors and helped me throughout this thesis by giving me advice and idea. I would also like to thank Colin Chaigneau and Valentin Houchouas, my colleagues at ANSSI, for their helps in areas of which they were experts. I am thankful to Panagiotis Papadimitratos, my supervisor at KTH, for his helpful advice about the report. Finally I thank Alice Tourtier for her help and support.
ii Contents
1 Introduction1 1.1 Goal of the thesis...... 1 1.2 Contribution...... 2 1.3 Outline...... 2
2 VoIP Technologies3 2.1 SIP...... 4 2.1.1 Messages...... 4 2.1.2 Elements of a SIP call establishment...... 6 2.1.3 Exchange examples...... 8 2.1.4 Security Mechanisms...... 9 2.2 Media session protocols...... 11 2.2.1 Codecs...... 11 2.2.2 RTP...... 12 2.2.3 SRTP...... 13 2.2.4 RTCP...... 14 2.2.5 SDP...... 15 2.3 Other protocols...... 16 2.3.1 VoIP protocols...... 16 2.3.2 Service protocols...... 17 2.4 Unified Communications...... 17
3 Security on a ToIP infrastructure 19 3.1 Security issues in ToIP...... 19 3.1.1 Risks...... 19 3.1.2 Common ToIP attacks...... 21 3.1.3 How to make secure ToIP...... 23 3.1.4 Limits...... 25 3.2 Session Border Controller...... 27 3.2.1 Principle...... 27 3.2.2 Differences with existing devices...... 29
4 SBC features 30 4.1 Internetworking...... 30 4.2 Media...... 30 4.3 QoS...... 31 4.4 Security...... 32 4.4.1 Upstream protection...... 32 4.4.2 Common attack protection...... 34 4.4.3 Downstream protection...... 36
5 SBC Architecture integration 39 5.1 At the border of ToIP architecture...... 39 5.1.1 Presentation...... 39 5.1.2 Limits...... 40 5.2 At the Center of ToIP architecture...... 40
iii 5.2.1 Presentation...... 40 5.2.2 Limits...... 40 5.3 Combination...... 41
6 SBC Security Test 42 6.1 Methodology...... 42 6.1.1 Test environment...... 42 6.1.2 Features announced...... 42 6.1.3 Fuzzing...... 43 6.1.4 Dos/Flood...... 43 6.1.5 TLS quality...... 44 6.1.6 Common SIP attacks...... 44 6.2 Test of Kamailio...... 45 6.2.1 Test environment...... 45 6.2.2 Results...... 47 6.2.3 Conclusion...... 51
7 Improvements 52 7.1 Permissions module...... 52 7.1.1 Logic...... 52 7.1.2 Implementation...... 53 7.2 CDR analysis...... 53 7.2.1 Logic...... 53 7.2.2 Implementation...... 56 7.2.3 Tests...... 56
8 Conclusion and future work 60 8.1 Accomplished work...... 60 8.2 SBC conception...... 60 8.3 Future work...... 61
A Loop amplification Attack 66
B Kamailio configuration files 67
C Asterisk configuration files 70
iv List of Figures
1 ITU-T protocol set...... 3 2 VoIP IETF protocol set...... 4 3 Example of a SIP INVITE message...... 5 4 SIP Registration process...... 8 5 SIP Call process...... 9 6 SIP Digest authentication example...... 10 7 RTP header as defined in RFC 3550 [1]...... 13 8 Example of a SDP description...... 15 9 Example of DoS attack with INVITE messages...... 22 10 Security measures at the network level...... 25 11 Example of SBC placement...... 28 12 Use of a B2BUA to transcode audio flow...... 28 13 SBC action to allow high frequency registration...... 33 14 Internal architecture with a SBC at the border of the ToIP network.... 39 15 VoIP flows with a SBC at the center...... 40 16 Internal architecture with two SBCs at the border and at the center of the ToIP network...... 41 17 Test environment of Kamailio...... 47 18 CPU and RAM usages versus message intensity during DoS attacks.... 49 19 Learning period in time...... 55 20 Example of a user profile...... 57 21 Call hour distribution for a user...... 58 22 Receiver Operating Characteristic for the call classifier...... 59 23 REGISTER messages of a loop amplification attack...... 66 24 Example of the flow of a SIP amplification attack from RFC 5393 [2]... 66
v List of Tables
1 Main SIP request methods...... 5 2 Main SIP response codes...... 5 3 Main audio codecs...... 12 4 Codecs understood by some SIP systems...... 31 5 Overview of the security features...... 43 6 Security features implemented in Kamailio...... 48 7 Kamailio DoS results...... 49 8 FPR and TPR results...... 58
vi Abbreviations and Acronyms
ANSSI French Network and Information Security Agency B2BUA Back-to-Back User Agent CA Certificate Authority CAC Call Admission Control CDR Call Detail Record CoS Class of Service CPE Customer Premises Equipment CPU Central Processing Unit CVE Common Vulnerabilities and Exposures DHCP Dynamic Host Configuration Protocol DNS Domain Name System DoS Denial of Service DDoS Distributed DoS DTLS Datagram Transport Layer Security DTMF Dual-Tone Multi-Frequency ERP Enterprise Resource Planning FPR False Positive Ratio FTP File Transfert Protocol HTTP Hypertext Transfer Protocol HTTPS HTTP Secure IAX Inter-Asterisk eXchange ICE Interactive Connectivity Establishment IETF Internet Engineering Task Force IP Internet Protocol IPBX Internet PBX IPsec Internet Protocol Security ISDN Integrated Services Digital Network ISUP Integrated Services Digital Network User Part ITU International Telecommunication Union ITU-T ITU Telecommunication Standardization Sector LACK Lost Audio Packets Steganography LAN Local Area Network LSB Least Significant Bit MAC Media Access Control MITM Man in the middle MIKEY Multimedia Internet KEYing MTU Maximum Transmission Unit NAT Network Address Translator NTP Network Time Protocol OS Operating System PBX Private Branch Exchange PC Personal Computer PKI Public Key Infrastructure PSTN Public Switched Telephone Network QoS Quality of Service
vii RAM Random Access Memory RFC Request for Comments ROC Receiver Operating Characteristic RTCP RTP Control Protocol RTD Round-Trip Delay RTP Real-time Transport Protocol S/MIME Secure/Multipurpose Internet Mail Extensions SBC Session Border Controller SDES SDP Security Description for Media Streams SDP Session Description Protocol SIP Session Initiation Protocol SIPREC SIP Recording SIPS SIP Secure SPIT Spam over Internet Telephony SRC Session Recording Client SRS Session Recording Server SRTP Secure Real-time Transport Protocol SS7 Signalling System No. 7 SSL Secure Sockets Layer STUN Simple Traversal of UDP through NAT TCP Transmission Control Protocol TFTP Trivial FTP TLS Transport Layer Security ToIP Telephony over IP TPR True Positive Ratio TURN Traversal Using Relay NAT UA User Agent UAC User Agent Client UAS User Agent Server UDP User Datagram Protocol URI Uniform Resource Identifier VLAN Virtual LAN VM Virtual Machine VoIP Voice over IP
viii 1 Introduction
The concept of Voice over IP (VoIP) appeared in the early 90s. At that time, the Internet was emerging and people proposed the idea to make the phone calls pass through the Internet network. To do so, they could not reuse the old telephone systems but they had to develop new protocols to make the calls on top of the TCP/IP networks. We had to wait until the end of the 90s to see instantiations of such protocols produced by IETF and ITU-T, respectively SIP and H.323. Nowadays, the general public is used to proprietary software such as Skype which is the incontestable leader with its 300 million users [3]. Telephony over IP (ToIP) represents the whole system which use VoIP, including IPBX and phones. Passing from the old Public Switched Telephone Network (PSTN) to ToIP brings several benefits. First, it helps reducing the cost of each call, both for international calls and local calls. Then, the convergence of the telephony network and computer network brings other features such as video, data transfer or messaging, that can be used from any connected device like computers and smartphones. The adoption of this technology by the market has been quite fast. For example, the penetration among US businesses has passed from 12% in 2004 to 79% in 2013 [4]. Some experts predict that the VoIP market will continue to grow to reach $82.5 billion services revenue in 2018, against $69.6 billion in 2014 [5]. This evolution of telephony has also increased the crucial need for security. ToIP inherits the security issues of IP based systems in addition to its own vulnerabilities. Contrary to the old PSTN system, physical interaction is not needed anymore to attack a system and anyone connected to the Internet can exploit a vulnerability of the network, from spying, to spoofing and toll frauds. At the early days of ToIP, most companies neglected security in their infrastructure because they were not aware of the risks involved. A report produced by the consultancy company Nettitude [6] shows that attacking a ToIP system is very attractive because of the money attackers can make (with toll fraud for example). Nevertheless, with the increasing number of attacks, companies started to secure their infrastructure, for example using secure versions of the protocols.
1.1 Goal of the thesis
This thesis will look at the security aspects of a ToIP network architecture inside a company and specifically examine the security brought by the Session Border Controllers (SBCs). The main goals of this thesis are:
• To provide a state of the art of the security features offered by the SBC imple- mentations and to compare them to threats internal or external to an IP telephony infrastructure,
• To develop a method for SBC testing and experiment it on a free solution,
• To propose changes in existing solutions and implement some, as time permits.
Even if a focus will be given on security in this thesis, the other functions a SBC can provide will also be briefly presented to cover all the aspects of a SBC. The objective is to give the readers an overview of the features that may be offered by a SBC. Indeed,
1 knowing what a SBC can actually do on a ToIP network will help to understand the critical aspect of this new element.
1.2 Contribution
This thesis work explains why a SBC is needed inside a ToIP network. The security provided by the SBC is analyzed in regards of the threats and new SBC features are presented. This thesis also gives a security test methodology for SBC and applies it to Kamailio [7] which is one of the most used SIP servers. This thesis also presents improvements on Kamailio to prevent toll fraud.
1.3 Outline
The thesis is organized and structured linearly. First, in Section2, it will be described how ToIP actually works and give the necessary knowledge to understand the rest of the thesis. Then, in Section3, the security issues a ToIP architecture might encounter will be introduced by describing the risk associated along with the common attacks. This presentation will bring us to the introduction of the SBC inside our network. After, Section4 will present the features we can expect from it and how it will improve our whole system, based on the problems shown before. The question of its integration in our infrastructure remains and we will reflect on it in the following Section5. In Section 6 a SBC test methodology will be created and used on the open-source SBC Kamailio. Finally in Section7, some implementations of new features for SBCs will be presented with a permissions module and a program to detect suspicious calls.
2 2 VoIP Technologies
Some background knowledge about VoIP and security is necessary. In this section, the protocols that are commonly used in VoIP will be presented. A VoIP ecosystem needs two parts: the signaling part to establish the call between two users, and the media transport part to carry the data from one user to the other once the session has been established. There are two sets of protocols mainly used today: the ITU-T set shown in Figure1 and the IETF set shown in Figure2. Both use the same protocol for the media transport but they differ on the signaling protocol used. The ITU-T set is called H.323 and is composed of several different protocols for the signaling part (H.225, H.245 and T.120). A large part of it comes from the protocol H.320, used in Integrated Services Digital Network (ISDN) which comes from the traditional telephony world. It made the transition easier and it explains why H.323 was the main protocol used in the early 2000’s. H.323 is a binary protocol and is complex by nature.
Control Data Media Control
Audio H.225 Video H.225 (Q.931) H.245 T.120 RTCP (RAS) RTP/ SRTP
TCP UDP
IP
Figure 1: ITU-T protocol set
The IETF is inspired by the Internet protocols and is text-based. It is composed of the Session Initiation Protocol as a signaling protocol and the Real-Time Transport Protocol (RTP) as a media protocol. SIP is media agnostic, it can be used to establish any type of session whereas H.323 is restricted to voice and video and cannot be used to support the new requirement of companies. SIP has become the main protocol used and almost all the new VoIP architectures are made using the IETF set, whereas the number of H.323 deployment is decreasing [8]. Consequently, this thesis will focus on the IETF set.
3 Media Signaling
Audio SDP Video RTCP SIP RTP/ SRTP TLS
UDP UDP/TCP
IP
Figure 2: VoIP IETF protocol set
SIP operates at the application layer and is agnostic of the transport layer used to carry it. It can be used with UDP, TCP or TLS with no change in the messages. VoIP communications need very low delays to be close to real time and, at the beginning, most implementations used UDP to carry SIP. However, the improvement of the Internet connection quality and the use of VoIP in mobile environments changed this habit and now a lot of implementations use TCP to transport SIP messages whereas media messages are still carried over UDP. During the first messages, the Session Description Protocol (SDP) is used inside SIP for exchanging the media parameters that will be used for the RTP session. When the session is established between the users with SIP, another set of protocols is used for the media part. The media flow is carried over RTP. RTP is a protocol on top of UDP for real time transfer that provides helps for jitter compensation, packet loss and detection of out of sequence arrival. RTP is used in combination with RTCP which provides statistics and control information for the associated RTP session.
2.1 SIP
SIP is a signaling, presence and instant messaging protocol developed to set up, modify, and tear down multimedia sessions between two or more users. It is an open standard that was defined in the RFC 3261 [9] and updated since by several other RFCs. It is a text-based protocol (in contrast to binary protocols), meaning that all the messages exchanged are in text and that makes it really easier to read and understand. It reuses many elements of the Hypertext Transfer Protocol (HTTP) and the Simple Mail Transfer Protocol (SMTP). Indeed, like for HTTP, the messages can be classified into request and response messages. It also uses Uniform Resource Identifiers (URIs) to identify resources as SMTP. sip:[email protected] is an example of such URI.
2.1.1 Messages
The SIP messages include request messages and response messages. The first line of a SIP request includes the name of the method that identifies the request and the first line of the response message includes a number called response code. The main request methods are shown in Table1 and the classes of response code are shown in Table2.
4 SIP message Description INVITE Used to establish media sessions between user agents REGISTER Used to notify a SIP network of its current contact URI (IP address) BYE Used to terminate an established media session ACK Used to acknowledge final responses to INVITE requests CANCEL Used to terminate pending INVITE or call attempt OPTIONS Used to query a system about its capabilities
Table 1: Main SIP request methods
Code Description Action 1xx Informational Indicates the status of the call prior to completion 2xx Success The request has succeeded. The original sender must send an ACK if it was for an INVITE 3xx Redirection The client should retry the request to another server given in the response 4xx Client error Request has failed due to the client. It must retry with a correct message following indications in the response 5xx Server failure Request has failed due to the server. Client may try another server 6xx Global failure Request has failed. Client should not try again with this server or any other
Table 2: Main SIP response codes
A full SIP message is shown below in Figure3. It is first composed of a line with the method or the response code, the user’s URI and the version of SIP. This first line is followed by several header fields and a body.
INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 67.152.23.12:5060;branch=z9hG4bK8c4b Max-Forwards: 70 From: "Bob"
(SDP not shown)
Figure 3: Example of a SIP INVITE message
Some header fields are mandatory (To, From, CSeq, Call-ID, Max-Forwards and Via) while the others are optional, even though they can be very useful. The main ones are:
5 • Via: Records the SIP route taken by a request and is used to route a response back to the originator
• To: Indicates the recipient of the request
• From: Indicates the originator of the request
• Max-Forwards: Indicates the maximum number of hops a SIP request may go through
• Call-ID: Must be unique and identifies a call between two users
• CSeq: Contains a decimal number that increases for each request
• Contact: Conveys a URI to identify the resource requested or the request originator
• User-Agent: Conveys information about the system originating the request
• Content-Type: Indicates the Internet media type in the message body
• Content-Length: Indicates the number of octets in the message body
There are more than 110 different SIP header fields defined in RFCs [10]. Anyone can define a new SIP header if it is useful for his system and some headers have been created by the main vendors to provide new features. However, the main problem with custom headers is the lack of interoperability between systems from different vendors.
2.1.2 Elements of a SIP call establishment
In this section the behavior of standard SIP elements and their role in a ToIP network is examined.
User Agent
SIP-enabled end devices are called user agents (UAs). They can be separated into two categories:
• A User Agent Client (UAC) is a logical entity that sends SIP requests
• A User Agent Server (UAS) is a logical entity that receives the requests and returns SIP responses
Most SIP implementations behave as both client and server. They can send messages to establish a call and at the same time they listen for any incoming call.
SIP Phones
SIP Phones are the very end points of calls. Their main tasks are to make calls and to receive calls. They can run on computer like Linphone, Ekiga or Skype (such software are called softphones), or separate IP phones with dedicated hardware like Cisco phones, Avaya phones or Mitel phones.
6 SIP Gateways
A SIP gateway is an application that interfaces a SIP network to a network using another signaling protocol such as the public switched telephone network (PSTN) or a network running with H.323. A gateway terminates the signaling path and can also terminate the media path. It can sometimes be decomposed into a media gateway (MG) for the media part and a media gateway controller (MGG) for the signaling part.
Proxy Servers
A SIP Proxy Server receives SIP requests from a user agent or another proxy and transmits them. Just as a router forwards IP packets at the IP layer, a SIP proxy for- wards SIP messages at the application layer. A proxy is only allowed to modify messages following the limitations of the RFC 3261. A proxy server can also extend the security by doing authentication (details in Section 2.1.4). Kamailio [7] is one of the most known free SIP proxy.
Registrar Servers
A Registrar Server accepts REGISTER requests from clients. When it receives a message, it updates the location database to make the contact information from the request available to the other SIP servers of the domains. A registration server usually requires the authentication of the client sending the REGISTER.
Redirect Server
A Redirect Server responds but does not forward the request. It uses a database to lookup users and sends a 3xx response directing the client to contact another URI to reach the user.
Back-to-Back User Agent (B2BUA)
A Back-to-Back User Agent receives SIP requests, rewrites them and sends them out as new requests. Some B2BUAs behave like proxies but do not follow the same rules as they can rewrite the From, Via, Contact and Call-ID headers. They divide the call into two call legs so they can manage each side of the call. Since all flows pass through a B2BUA, it is aware of the state of every call and can perform call control to add new features like voice messaging for example. The most famous free implementation of B2BUA server is Asterisk [11] and it is used by more than one million communication systems [11]. FreeSWITCH [12] is another famous free implementation. In addition, they can both act as an IPBX and a media gateway, and thus manage the entire ToIP of a company.
7 2.1.3 Exchange examples
Now that the foundations of SIP have been described, as well as the elements of the network and the messages exchanged, two important examples of SIP exchanges can be described: the registration and the establishment of a call.
Registration
Figure4 shows the registration process. The UAC sends a REGISTER message to the registrar which responds with a 200 OK message. Each UAC has to register itself to a registrar if it wants to receive calls. With this information, the SIP proxy can redirect the call to the right IP address. If the UAC does not do it, when the SIP proxy will receive a call for it, the proxy will not be able to transmit the call. The registrar might ask the UAC to authenticate itself.
Alice Registrar
REGISTER
200 OK
Figure 4: SIP Registration process
Call Establishment
Figure5 shows a call between Bob and Alice. She wants to call Bob who is registered to another domain. First, she sends an INVITE message to her SIP proxy which will transmit it to the proxy of Bob’s domain. After transmitting it, the SIP Proxy sends a 100 Trying message to Alice to make her know that her message has been processed. When the second SIP Proxy receives the INVITE, it knows where to find Bob (because Bob registered himself before) and transmits the INVITE to Bob. As for the first proxy, the second proxy responds with a 100 Trying message. Bob’s phone receives the INVITE and starts to ring. It sends a 180 Ringing message that will be transmitted back to Alice. When Bob picks up his phone, it sends a 200 OK response that will be again transmitted to Alice. She receives the 200 OK and sends in response an ACK to Bob through the proxies. At this time the session is established, each machine of the user knows the IP address of the other. Thus, they can start to send audio or video between them with RTP protocol. When one wants to end the call by hanging up the phone, it sends a BYE message to the other that will respond with a 200 OK message to make the BYE originator knows that the message has been well received (with UDP the message might be lost). The process can be much more complex in a production environment because of all the other elements on the way.
8 Alice SIP Proxy SIP Proxy Bob
Alice calls INVITE INVITE 100 Trying INVITE 100 Trying 180 Ringing 180 Ringing 180 Ringing 200 OK Bob answers 200 OK 200 OK ACK ACK ACK
Media Session (RTP)
BYE
200 OK
Figure 5: SIP Call process
2.1.4 Security Mechanisms
The telephony architecture in a company is a critical element that has to satisfy the fundamental concepts of security. SIP comes with some mechanisms to provide authenti- cation, confidentiality and integrity that have been defined since the RFC 3261 [9].
Authentication
Three methods have been described to provide authentication for SIP:
• Digest authentication: It is based on HTTP digest mode [9]. A SIP server or UA can challenge another UA to resend a request proving knowledge of a shared secret, which is used to compute a MD5 hash of several parameters (from, to, method, nonce, realm) that will be send in a new message. An example of transaction is shown Figure6 with a registration. The UAC sends a message, the UAS responds with a 401 Unauthorized message or with a 407 Authentication Required message which contains a nonce (to prevent replay attacks) and a realm (to identify the system being accessed) that will be used to compute the MD5 hash. The new message will be the same with a response header field containing the parameters and the hash. If the hash is correct the request will be processed by the UAS. This method only provides a way for the server to authenticate the client, not the opposite. The HTTP digest authentication is considered as weak and vulnerable [13] and some propositions of improvement have been made [14]. One should avoid to base his entire authentication system on it and use one of the other mechanisms below in addition.
9 • TLS client authentication: SIP can be used on top of TLS to employ the au- thentication process of TLS. If the X.509 server certificate is signed by a certificate authority recognized by the client, the certificate can be used to authenticate the public key of the server and later to authenticate the server within the TLS hand- shake. The server can also request a client certificate for mutual authentication. However it is rare that the clients also have a certificate so the server can use the digest authentication presented above once the TLS session has been established.
• Identity: Proposed in the RFC 4474 [15]. A new SIP header field, Identity, is inserted by a proxy server when forwarding a request. The proxy first authenticates the request to make sure it is being sent by the identity in the from header field. If so, some parts of the request are signed and the signature is included in the Identity header field. An Identity-Info header field indicates the link to the certificate used to sign the message. When a UA or a proxy receives a request it can get and check the certificate following the link in the Identity-Info and check the signature in the Identity. If the signature is correct, the From URI is authenticated. As for TLS, Identity needs a PKI for the certificate management.
Alice Registrar
REGISTER
401 Unauthorized
REGISTER (with MD5 hash)
200 OK
Figure 6: SIP Digest authentication example
Confidentiality and integrity
The SIP messages are rarely sent directly from user to user and pass through interme- diates. These intermediates may want to change the SIP messages to sanitize them for example. With the use of end to end encryption or entire message signature, messages will not be alterable anymore by intermediates. As a user is not aware of all the ToIP elements on the path, it is strongly not recommend to use them. SIP provides three common ways to provide confidentiality and integrity:
• S/MIME: It permits to encrypt or sign the message body (usually SDP) in a user- to-user way. It was first designed for email sending but it has evolved, and now it has been adapted for HTTP and SIP. It is based on certificates and thus requires a Public Key Infrastructure (PKI). The messages are sent with the body encrypted with the public key of the recipient and signed by the private key of the sender. The key exchange mechanism is described in the section 23.2 of the RFC 3261 [9]. Even if S/MIME has been defined in a RFC, no implementation of it is widely
10 used today, probably because it requires the same system as TLS while offering less advantages. In addition, it does not protect the SIP headers of the messages and does not provide protections against replay attack or messages order modification.
• IPsec: The Encapsulating Security Payloads (ESP) protocol is the component of IPsec used for confidentiality as the whole packet payload is encrypted. It operates at the IP layer and provides a secure connection between two hosts. In most cases, IPsec is done directly by the OS or kernel layer: applications are unaware if they are using IPsec or not. Thus, IPsec is often used to establish a secure canal between distant sites. Contrary to S/MIME, the protection is done at the network layer. Thus, all the application data are protected (integrity and confidentiality) and not only the SIP payload.
• SIP over TLS: As for many other application protocols, it is possible to use TLS to authenticate and protect the messages from a MITM. It operates between the appli- cation layer and the transport layer and can run on both TCP and UDP transport protocol (DTLS), but is mainly used over TCP. The validation process of the cer- tificates is described in the RFC 5922 [16]. It provides confidentiality and integrity and works on a hop-by-hop basis. Most implementations use this solution.
2.2 Media session protocols
First, the audio or video flow encoding will be described. Then its transmission over the network will be detailed, as well as the parameters exchange and the transport protocols involved.
2.2.1 Codecs
Before thinking of sending the media flow through the network, a system first has to decide what it actually wants to send. The microphone or camera gives the system a digital signal that is quite large. Telephony works in real time so the signal needs to cross the network as quickly as possible. To help speed up transmission, mathematical coders- decoders called codecs were built to encode a signal for transmission and then decode it for viewing. The objective of these codecs is to reduce as much as possible the size of the signal while keeping the quality as good as possible with a computational complexity low. This problematic is major for service providers and cloud companies as they need to satisfy a maximal number of users with the less resources. Thus they finance a lot of research in this area to find better codecs. With VoIP, the systems have to be sure that the endpoints of their media flow have the decoders to read it. Before sending the media flow they have to agree on the codec to use. This capacity is given with the SDP protocol (described in Section 2.2.5) during the signaling part of the call. Today, VoIP phones understand several codecs, to have at least one in common with the other side, and to be able to choose the best codec depending on the bandwidth available and the desired quality. Table4 shows the main audio codec used with their characteristics. The G.711 codec is very old and is the basic codec for most implementations. Even if two phones are very different, a user can almost be sure that they will both support G.711. With the increase
11 of network transmission, data storage and video calls, several other interesting codecs have been developed. Some are free and can be used by anyone in his applications.
Sampling Codec Year BW (kHz) BR (kbps) Patents Comment (kHz) G.711 1972 3.3 64 8 Not anymore Reference codec G.722 1988 7 48, 56, 64 7 Not anymore High quality G.722.1 1999 7 24, 32 16 Royalty-free Lower complexity G.722.2 2003 7 6.60 to 23.85 16 Yes Lower bitrate G.7223.1 1995 3.3 5.3 and 6.3 8 Yes Required in H.323 AMR 1999 3.2 4.75 to 12.2 8 Yes Standard speech codec GSM/UMTS G.726 1990 3.3 16, 24, 32, 40 8 Yes Used in international trunks G.729 1995 3.3 8 8 Yes Low bitrate G.719 2008 20 32 to 128 48 Yes High quality, flexible rate selection iLBC 2004 3.3 13.33, 15.2 8 Open format Part of WebRTC project Opus 2012 4 to 20 6 to 510 8 to 48 Open format Good quality with low complexity
Table 3: Main audio codecs
2.2.2 RTP
The VoIP system will encode the signal using one of the codec above to obtain the data it is willing to send to the other party. However, sending it directly over UDP will be too uncertain as there is no information at all about the packets sent. If there are some loss or delay, the end user won’t be able to rebuild the flow. This is why VoIP needs an intermediary protocol to carry the media stream. The Real-time Transport Protocol (RTP) defined in the RFC 3550 [1] is a network protocol for delivering audio and video over the network with facilities for jitter compensation and detection of out of sequence arrival in data. RTP works on top of UDP (and not TCP) because systems can tolerate some loss in the packets in favor of delay. A RTP packet is composed of a header and a payload to carry the data. The RTP header is shown in Figure7. The headers have the following meanings:
• V: The version of the protocol, currently 2
• P: Indicates if there are padding bytes at the end of the RTP packet
• X: Indicates the presence of an extension header
• CC: Contains the number of contributing sources (CSRC) identifiers
• M: Marker for the application level
• PT: Indicates the RTP payload type
• Sequence number: Number to determine packet sequence and detect packet loss
• Timestamp: Indicates the Internet media type in the message body
• SSRC: Identifies the source of the stream, randomly chosen
• CSRC: List of contributing sources for a stream that has been generated from multiple sources
12 • Extension header: Possibility to add new header fields
0 2 3 4 8 9 16 31 V P X CC M PT Sequence number Timestamp SSRC identifiers
CSRC identifiers ...
Extension header ...
Figure 7: RTP header as defined in RFC 3550 [1]
The encoded media signal is placed into the payload of the RTP packets. The sequence number ensures that the packets can be reordered and the timestamp ensures that a loss does not perturb the reconstitution of the media stream. The protocol is independent of the media it carries, that means that a new multimedia format can be transported with RTP just by defining a new RTP payload type. There is no security at all in RTP, everyone can see the flow and modify it. This is why a new protocol, SRTP, has been built based on RTP to provide the security services needed.
2.2.3 SRTP
The Secure Real-time Transport Protocol (SRTP) [17] is used to secure the exchanges made with RTP. The header is in clear but the payload is encrypted. With a key exchange protocol, the two parts exchange a key from which will be derived the necessary keys for the RTP and RTCP sessions. The RFC does not specify a key exchange protocol and several have been defined for this use:
• ZRTP (RFC 6189 [18]): A shared secret and the security parameters are exchanged using Diffie–Hellman key exchange. Then each user has a Short Authentication String (SAS) that it can share to the other, orally, to check if they have the same and no MITM has altered the key establishment. The ZRTP exchange uses the same port as the RTP traffic that will follow. • MIKEY (RFC 6189 [19]): This is a key management protocol designed to per- form key exchange and negotiate cryptographic parameters on behalf of multimedia applications. The MIKEY messages are transported inside the SDP part of the signaling exchanges, encoded in base64. Thus, it relies on the security of SIP (with TLS or IPsec) to provide security for RTP. • DTLS-SRTP (RFC 6189 [20]): It used DTLS to exchange keys for the SRTP media transport. It is a very secure way to process because it does not rely on the security of SIP and reuse the TLS protocol. But this requires a PKI contrary to ZRTP.
13 • SDES (RFC 6189 [21]): As for MIKEY, security parameters and keys are sent as an SDP attribute of the initial SIP messages.
Even though several mechanisms exist and have been implemented, SDES is the most common way of doing SRTP today because of its simplicity. However, the security it provides is based on the one provided for SIP. As the keys are sent in the SDP message, SIP needs to be encrypted and authenticated. This is the weakness of SDES, and the reason why one should prefer DTLS-SRTP for example.
2.2.4 RTCP
The RTP Control Protocol (RTCP) is an associated protocol of RTP. It has been defined in RFC 3550 [1] and is primarily used to provide feedback on the quality of the data distribution. Mainly, RTCP aims:
• To monitor the quality of services with information such as the packet counts, packet loss, delay variation or round-trip delay time.
• To carry a persistent transport-level identifier for an RTP source called the canonical name or CNAME. The SSRC identifiers might change and the CNAME helps to keep track of each participant. It can be used to associate multiple media streams (for example to synchronize audio and video).
• To keep track of the number of participants by looking at the RTCP packets received.
• To convey minimal session control information, for example participant identifica- tion to be displayed in the user interface.
RTP uses an even port number and RTCP uses the next odd port number. RTCP, as RTP, is independent of the underlying transport protocol. RTCP packets are transmitted periodically, at a recommended minimum interval of 5 seconds. Several RTCP packets can be combined in the same UDP datagram. RTCP has several types of messages:
• SR: Sender report for transmission and reception statistics from participants that are active senders (i.e. who send media to the others)
• RR: Receiver report, for reception statistics from participants that are not active senders
• SDES: Source description items, including CNAME
• BYE: Indicates end of participation
• APP: Application-specific functions
As RTP, RTCP has a secure version known as Secure RTCP (SRTCP), very similar to SRTP. It provides the same security features to RTCP as the one provided by SRTP to RTP.
14 2.2.5 SDP
To make the recipients know what the phone is sending with RTP, VoIP needs a protocol to share the media parameters and make the users agree on them. The Session Description Protocol (SDP) have been created for that purpose. It has been defined in RFC 4566 [22] and is a format for describing media sessions such as transport addresses, transport protocols, port numbers and media details. It works in conjunction with SIP and is sent in the body of the initial SIP messages. As SDP is just a format for session description, it can also be transported via SAP, RTSP and HTTP. The SDP part of the SIP message is indicated with the value application/sdp in the header field Content-Type. The form of each field is structured as
• The type of media (video, audio...)
• The transport protocol (RTP/UDP/IP, H.320...)
• The format of the media (H.264 video, G.722 audio...)
• The remote address for media
• The remote transport port for media
A SDP description is shown below in Figure8. It can be split into three parts: the session description, the time description and the media description.
v=0 o=MxSIP 0 1 IN IP4 192.168.51.38 s=SIP Call c=IN IP4 192.168.51.38 t=0 0 m=audio 3000 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=rtpmap:110 PCMU/16000 a=rtpmap:111 PCMA/16000
Figure 8: Example of a SDP description
The SDP description is part of a SIP INVITE message to establish a call between two softphones. The meaning of the different types shown in the SDP message are:
• v: Protocol version number, currently 0 • o: Originator and session identifier. The format is:
• s: Session name
15 • c: Connection information for the media. The format is:
In figure8, IN represents the Internet, IP4 means that the address used is an IPv4 address and 192.168.51.38 is the IP address the receiver has to send the media flow.
• t: Time the session is active. The format is
• m: Media name and transport address. The format is
• a: Media attributes line. The example is composed of the audio codecs proposed with their characteristics.
SIP has two different ways of sending the SDP and making the two sides agree on the parameters the call will use:
• Early offer: In the first way, the call originator makes the first offer and the call recipient chooses the parameters. The first INVITE contains the SDP offer and the called party chooses and responds in the following 200 OK message.
• Late offer: In the second way, the call recipient makes the first offer and the call originator chooses the parameters. The first INVITE contains no SDP part and the called party will make the offer in the 200 OK message. Then the calling party will choose and respond in the following ACK.
2.3 Other protocols
The protocols presented before are not the only ones crossing through a ToIP network. First, there are some other VoIP protocols that systems can use. Then, the IP phones often offer services, like directories, using non VoIP protocols.
2.3.1 VoIP protocols
Some other protocols have been created for VoIP, some are proprietary and popular among general public (like Skype and Teamspeak) whereas others are free and imple- mented in some open source project (like IAX and Jingle).
Skype and TeamSpeak
Skype [23] is the most popular VoIP software in the world. A lot of people use it to make video calls or to call telephone numbers from the Internet. However, Skype uses its own protocol called Skype protocol which has not been made publicly available. TeamSpeak [24] is another proprietary VoIP software used to speak on a chat channel like for a telephonic conference call. It is mostly used by gamers for online multiplayer games. As for Skype the protocol hasn’t been made public (and remains secret).
16 Jingle and IAX2
Jingle [25] is an extension for Jabber to add VoIP features. Jabber is an open protocol based on the XML language. It is decentralized and works in the same way as email services. It is very close to the protocol used by Google Talk and can also easily be converted to SIP with specific gateways. There are a few clients and IPBX (like Asterisk or FreeSWITCH) that can use Jingle. The Inter-Asterisk eXchange 2 (IAX2) is a protocol that can be used for any type of streaming but is mainly designed to support audio calls. It has been designed by the creators of the IPBX Asterisk and has been published in RFC 5456 [26]. It is supported by Asterisk of course, but also by other IPBX and softphones. Compared to SIP, it minimizes the bandwidth used and provides a native way to traverse NAT. However, it is less flexible than SIP and new features have to be added in the protocol specification.
2.3.2 Service protocols
IP Phones, like the ones used in companies, are complex devices which offer a lot of features other than just VoIP. First, the whole boot process is quite complex and requires several steps. When the phones boot they use DHCP to acquire an IP address, then they might use NTP to acquire the time used on the network. Then most of the commercial phones download their configuration files using the Trivial File Transfert Protocol (TFTP), FTP, HTTP or HTTPS. Then, they might look to the upgrade server in case of software upgrade, again with TFTP, FTP or HTTP(S). All these operations might require the use of the DNS protocol. At this point they can proceed to the SIP registration and are ready to make and receive calls. Secondly the phones can provide services and applications working remotely. For example, a lot of phones can use XML applications. These applications are running on a server that receives HTTP(S) requests from the phones and responds with files using the XML format. It can be used for directories, calendars, speed dials, notes...
2.4 Unified Communications
Unified Communication is the new industry term used to describe the set of com- munication services intended for companies. It includes several products, with the aim to integrate them into one single software and interface that will manage everything, to increase efficiency and ergonomy. This interface should be accessible from every devices a company may have (smartphones, computers, tablets...). The main components are:
• Calendar: To manage meetings and deadlines
• Messaging: To send emails, SMS, fax, voicemail
• Telephony: To make audio and video calls directly with a physical phone or from the computer
• Conferencing: To schedule meetings, check the availability of the guests, make the conference online with audio and video flows from everyone
• Presence: To know the presence state of a colleague (idle, in call, in meeting...)
17 • Collaboration: To work on a file from everywhere with several people at the same time
• Data: To store the files online and access them from everywhere
This is a new business growing fast and several companies are working on solutions. VoIP occupies a key place in Unified Communication. It is still one of the major media of communications used in companies and the flexibility of SIP allows the implementation of new features that will be integrated into the whole Unified Communication system.
18 3 Security on a ToIP infrastructure
Since the telephony has moved on IP networks, the attack surface has increased be- cause of its reachability. Before VoIP, when people were using analogical systems, the attack were mainly physical. Someone could have access to the wired line and install copper straps to intercept the signal and listen to someone. This interception could alter a little the quality of the call by adding some poor contacts which will lead to crackling and even interference. However, to do this procedure the person needed a physical access and the security measures to prevent it were pretty clear. There was also no authenti- cation and users could not be sure of the identity of the person who was calling them. Today, since ISDN and now SIP, all the devices are reachable from anywhere and they have evolved, they are computer with all the common security issues involved. The traffic passes in the same cable as the others services and users do not have the control of all the devices on the path. As for emails, the telephony infrastructure is a very critical element for companies. If someone gained access to a device on the network, he could make premium calls resulting to a huge bill for the company. No one is protected and every company should be careful about it. One of the conceivable security step is to add a specific device at the border of the ToIP network that will have the same role as firewall or reverse proxy for the traditional Internet services. Such devices are called Session Border Controllers (SBC). They will be presented in Section 3.2 after having a look at security in ToIP in Section 3.1.
3.1 Security issues in ToIP
In the first part of this section, the security risks of ToIP will be showed along with the related common attacks. Then, how to make ToIP as secure as possible will be discussed. Finally the limits of these actions will be explained.
3.1.1 Risks
Unavailability
An attacker could try to make the whole system unavailable. It can be done by finding bugs in devices, or more simple, by doing a DDoS attack on an infrastructure making the servers flooded by all these packets. The consequences will first be economical for the company. If the employees cannot make call anymore it will lower there productivity and even prevent them to work. It can also be very harmful with emergency calls like for police officers and firefighters.
Corruption
If an attacker has a MITM position and has access to the media flow he could insert or delete audio parts in the call. It can be used to give false information to someone. Indeed, the target will think these information are true because part of a certified conversation between him and the other. For example, a program of an attacker could change the answering machine message of a bank, asking for the user account password after the
19 identification process of the beginning. The user is sure he is talking with the bank answering machine so he won’t think of an attack here.
Non-confidentiality
This is one of the major risks. If someone can listen to all of the conversations of a company because they are not using SRTP, it could compromise the whole company. It can also be used to steal user names, passwords and phone numbers. In the early days of VoIP systems, no one was using SIPS and SRTP to secure the communication and it made ToIP an attractive target for hackers.
Impersonation
An attacker could try to make calls pretending to be someone else. Indeed, if the recipient does not know the voice of the person, he will look at the name or number written on the phone to identify the person calling. The main goal here is to ask for confidential information or to make the recipient do a task for him.
Toll fraud
This is the major issue for small companies which do not have secret information an attacker might want to steal. The CFCA 2015 report about fraud loss [27] shows that the surveyed companies have lost more than 15 billion dollars with toll fraud. It can be done with international calls or premium numbers calls. A classical way to do it is to have access on a phone or the IPBX and use it to make automatic calls.
Harassing calls and SPIT
It is easier to generate automatic calls with VoIP than with traditional telephony. Everyone with a computer and a SIP trunk account can make or use a program to generate calls to random numbers. These calls can play an advertisement, they are called Spam over Internet Telephony (SPIT) in this case, or harass someone. This problem is not yet comparable with the email spam, however the increase of VoIP may induce the increase of such behaviors. Researchers have been working on the SPAM detection, based on call frequency, low call completion and low call duration average. Their works have been published in the RFC 5039 [28].
Propagation
If an attacker gains access to any device of a ToIP infrastructure, it could be the entry door for all the IT infrastructure. From the server or the phone he controls, he could try to reach computers or other servers on the network. A company could have a perfect security on the computer side of the infrastructure, it can be totally ruined if they do not apply the same security level in the ToIP infrastructure.
20 3.1.2 Common ToIP attacks
When an attacker wants to attack a ToIP infrastructure it has several known tech- niques to do it [29]. I will suppose that the basic protection with SIP digests is in place. Otherwise, anyone can pretend to be someone else intercepting every calls and making all the calls he wants.
Banner grabbing
At the beginning of the attack, the attacker may want to gather information about the targeted system, like the software running on the servers and phones. Using this information with a Common Vulnerabilities and Exposures (CVE) can lead to security issues. The SIP messages follow the model of the HTTP messages so there is a user-agent header and a server header which carry the software used and its version. In addition, the SDP part has also a User-Agent field. Their utility can be discussed because the SIP protocol is an open standard so, in theory, it’s not useful to know the recipient’s software to be able to communicate with him. An attacker could simply know the software by sending an INVITE message and looking at the fields in the response.
User enumeration
Then the attacker may want to list the users of the service, to impersonate them later, or to call them for SPIT. To find them, he can try to send REGISTER, INVITE or OPTIONS messages and look at the responses. The response will be different, regarding if he asks for a regular user or an unknown user. It can tell him if a user exists or not.
Password cracking
When the attacker has found some usernames, he can try to find their associated pass- word. He can do it by performing a brute-force attack (trying all the password possibili- ties) or better a dictionary attack (trying only the most likely). He will send REGISTER messages, wait for the authentication query, and try a password in the response. If the password was not the right one, he will receive another authentication query. Otherwise, if the password was good, he will receive a 200 OK message. Once he found a good password, he can use it to impersonate the user or to do toll fraud.
DoS
The most famous attack to make a system unavailable is a DoS attack. It consists on flooding the services in order to make them unavailable. This attack can saturate the network links (volumetric attack) or make the server CPU reach 100%. The system will be unavailable for the legitimate users who will have their requests lost in the massive amount of flooding requests as shown below in Figure9. There are several flooding techniques at every layer. The protection (excepted for the volumetric attacks) is to make a selection in the received packets in order that the server does not process every packet and keeps its
21 resources available. However, finding a way to do it efficiently is a very difficult problem and there are active researchers on this subject because most of the hosting providers want to provide such protection. For the VoIP services, the most common way is to send a lot of INVITE messages. The server will process the message and it will consume resources, affecting its performances [30].
Attacker
millions of INVITE messages
INVITE
INVITE INVITE
Figure 9: Example of DoS attack with INVITE messages
Illegitimate BYE
Another way to block VoIP for a domain is to send illegitimate BYE to close the calls. Indeed, if no security protocol have been used for SIP, there is no authentication between the UAC Even if the messages pass through a proxy which authenticates the sender with a digest. A UAC will accept all messages on the condition of having the right identifiers for the dialogue: the two tags and the call-id. Thus a MITM could want to stop the conversation by sending a BYE with the corresponding fields to both side of the call. It can be done to prevent someone or a company to make calls during a period of time.
Fuzzing
If an attacker finds a message that can crash the SIP stack of the devices, it will instantly stop all the communications. The literature [31] proposes five categories of malformed packets:
• Incorrect Grammar
• Oversized Field Values
• Invalid Message or Field Name
• Redundant or Repetitive Header Field
22 • Invalid Semantic
The main goal of this attack is to crash the system, or exploit a software flaw such as a buffer overflow, to execute arbitrary codes.
Amplification
The SIP protocol has a vulnerability named “loop amplification attack”, shown in RFC 5393 [2]. It can be leveraged to cause of small number of SIP requests to generate an extremely large number (up to 271) of messages. To achieve it, an attacker needs two registrar services and two addresses in each one. It limits the possible applications of this attack. More details are given in AppendixA.
Steganography
Once an attacker took control of one device, he might want to transfer data outside, like calls logs, voice samples or documents from another computer of the company. To do it without being detected, he could want to hide it inside the RTP flow of a call. Calls in VoIP can use a quite high stable bandwidth that could allow an attacker to transmit data. Several known techniques have been discovered by researchers:
• The Least Significant Bit (LSB) technique is a common way to do steganography. It consists of hiding data in the bits with the least importance so that the difference is almost unnoticeable for a listener.
• The redundancy bits technique is similar to the previous one. Most codecs include redundancy bits that can be used to check on the data received. Hiding data in these bits is possible. If the transmission medium is good, the flow will fail the redundancy check at the recipient side but the audio will still be the same after the decoding phase.
• The RTP extension header uses the possibility of adding RTP headers to hide the data inside it.
• The LACK (Lost Audio Packets Steganography) technique hides the information into delay packets. If the packets have enough delay they will not be interpreted for the audio restitution but still received by the recipient. These packets still belong to the same media flow and to the conversation. Thus, they can pass some surveillance mechanism. At the end, the recipient can reconstitute the original data with all the delayed packets.
These methods and others have been previously described in literature [32]. For example, a one hour call using G.711 audio codec consumes more than 200Mb of data. Using the LSB, an attacker can pass dozens of megabits of hidden data.
3.1.3 How to make secure ToIP
The risks for a ToIP architecture have been described in the previous part. A few of them were already present in the analogical telephony network but, again, the surface of
23 attack has increased. To prevent these attacks to happen, several measures have to be taken on both network level and system level.
Network Level
VoIP runs in top of the traditional IP network, so known protocols can be applied to make the layers 1 to 4 secure. First, at the physical level, the equipments have to be protected to prevent someone to get an access to it. That means that a company should not put phones in public area of its buildings. They must have a good building security to prevent a stranger to have access to some offices with VoIP systems. If someone can have access to a phone he could modify the firmware to turn the phone into a spying tool. He could also make calls to premium numbers to make some dollars or make calls using someone phone to spoof his identity. Then, the ToIP network and the computers network have to be separated to reduce the risks of propagation. It can be done physically or logically with the use of separate VLANs. Using VLAN is easier and most companies use this solution to separate ToIP. However, it is possible to jump from the computer VLAN to the ToIP VLAN [33], making such protection not as secure as a physical separation. With a dedicated network the computers of the company won’t be reachable with the phones and reciprocally. However, such an approach might be quite difficult to apply with the Unified Communication systems used by some companies. Another difficulty with this approach is of course the cost of it. Some companies won’t pay the infrastructure cost to increase security. Then at the layer 2, 802.1X is necessary with mutual authentication such as EAP- TLS. It will prevent someone, who does not have a correct signed certificate, to plug his own device into the network to infect other systems. Anti ARP-spoofing techniques must also be applied to prevent a user on the network to send spoofed ARP packets to receive the RTP flow intended to someone else. This can simply be done with the use of static ARP tables but this does not scale to a large network. On the system OS, unsolicited ARP replies that might come from an attacker can just be ignored. The switches could also implement protection, based on the knowledge of the network given by the DHCP requests/responses. At the layer 3 IPsec can be used in some particular cases. For example if a company has several offices in different cities, they could use gateway in front of each network with IPSec to make secure tunnels between the places. Then in the application level, SIP over TLS (SIPS) and SRTP/SRTCP are necessary. SIPS assures confidentiality, integrity and authentication for the SIP messages. If possible, the use of the dual authentication in TLS adds also authentication for the client. SRTP prevents eavesdropping, modification and replay of packets for the media flows. These two protocols are mandatory for a minimum security policy in ToIP systems. The use of SRTCP is less critical than SRTP but it provides confidentiality, integrity and authentica- tion for the RTCP packets. In addition, if the phones use online XML services, they must do it with HTTPS and dual authentication (with TLS or just with digest authentication on TLS). Figure 10 summarize the protocols and techniques presented.
24 Layer 7 HTTPS, SIPS, SRTP
Layer 5 TLS
Layer 3 IPsec
Layer 2 802.1X, Anti DHCP-spoofing, Anti ARP-spoofing
Layer 1 Dedicated network, building security
Figure 10: Security measures at the network level
System Level
Once the secure versions of the VoIP protocols are in place, the system has to be protected against attacks that use the correct behavior of the secure protocols. The sys- tem administration best practices have to be followed. First, secure passwords (minimal number of characters, use of uppercase letters and symbols) must be used to prevent someone from guessing it. Then, the systems must be upgraded to their last version to prevent someone to use known vulnerabilities that have been fixed since. In the infras- tructure, a backup system must be in place to prevent single points of failure. It can be a redundancy of the IPBX and SIP servers. Then system hardening must be done to reduce the surface of vulnerability. Here, it will consist of disabling the services that are not used and revoking the credentials that are not needed. The configuration must be done very carefully on the servers because a bad configuration can induce vulnerabilities. Finally, the infrastructure has to be monitored to detect intrusion or strange behaviors. The network throughput can be watched for the whole system and per host, as well as the state of the devices, the bills for the month or the number of calls made. Detecting an attack as early as possible will reduce its impact.
3.1.4 Limits
However, even if most of the suggestions above have been applied to the ToIP infras- tructure, some attackers could pass through these protections. It can be done because of human factors or because of vulnerabilities in the protocols or in the running systems. Several scenarios are presented below to examine what could be done to prevent them to happen.
IP Phones vulnerabilities
In the worst cases, the IP phones may be the target of attacks to gain a root access on them or to change their firmware. Once this has been done, the attacker can do anything he wants with the phone. The system administration best practices described above make such attacks more difficult but there are always risks. For example, in 2013, it has been discovered [34] that some phones could be turned into spying microphones. This attack
25 required a physical access to the phone. Then, the serial port of the phone was used to inject binary code that exploited a security vulnerability to change the firmware and install whatever the attacker wanted. With this kind of attack, the attacker will be able to spy on every calls, to corrupt the RTP flow, to have access to the phone password, to make automatic calls to premium numbers, to turn the microphone on to spy on the employees or to contaminate the other systems on the same network... Even if the attacker cannot have a root access on the phone, he can change the config- uration files (using the web interface or by exploiting a vulnerability in the configuration downloading) and do some serious damages. First, he could disable the use of TLS and change the address of the SIP proxy. For example, he could put a B2BUA that will transmit the messages to the right proxy. The user won’t see any change during a call but every call will go through the attacker server that will see everything. The attacker could also disable the use of SRTP and add a media gateway for the RTP flow. A gateway that will belong to him of course. He could also change the address of the telephone directory to give the user a false phone number and get some information from him. Finally, this can be used to modify the firmware server address and change the firmware, making the attack worse. If the configuration file cannot be changed and the attacker cannot modify anything on the phone, he can still use it to make manual phone calls to make money or impersonate the phone owner.
IPBX vulnerabilities
As for the phones, the IPBX and other SIP servers are not immune. An IPBX can be compromised and used to execute the same attacks as for a single phone above, but for every phones at the same time. The IPBX might also have the SIP passwords or the voicemail passwords in clear text so an attacker could have all of them in case the IPBX is compromise. These passwords could also be used by other services and the attacker can use them to propagate the attack. In addition, the IPBX is very critical and it is at the front line of the SIP messages, so if a single vulnerability in the parsing of the SIP messages is found, it can make the whole service unavailable. It happened with the software based on OpenSER in 2009 [35], a single INVITE message with multiple “:” in the via field could make all the system crash. The fix was out few days after but during the interval the systems based on OPENSIR were very vulnerable. With the SIP protocol, every SIP router on the path puts its own IP address in a Via header. It is useful for routing back the messages but this is a confidentiality leak for operators. They do not want anyone to know the IP address of the IPBX because it is a good way for keeping it away from attack. The SIP protocol does not give a direct way to deal with this problem.
MITM threats
The security policy may be to use TLS and SRTP for every calls. However, the final choice depends on the two sides of the call. A ToIP infrastructure of a company can use TLS for internal calls. There will be cases where an external destination cannot use these protocols, because it does not want to or because these protocols have not been implemented. In this situation TLS will not be used and a MITM could intercept the
26 call. The fault could also be because of the phones, they can have a weak version of TLS or vulnerabilities in the implementation itself. Depending on the vulnerabilities, a MITM attack might be possible and someone could listen and modify the media flow.
DoS attack
An attacker could easily launch a DoS or a DDoS attack as explained in Section 3.1.2 against some element of the infrastructure. It can be the IPBX directly or the phones as they have less computational power and thus are easier to overload. A company can already have a firewall in front of its ToIP network. However the firewall does not have a full SIP understanding and cannot implement complex rules.
In most of the cases above, upstream actions can be taken to limit the possibility for an attacker to achieve them. However, zero risk is not possible and the ToIP infrastruc- ture has to be ready in case someone succeed attacking it. Something else, downstream, is needed to reduce the impact of the attack and to keep a high level of security. This expectation is one of the issue a Session Border Controller is supposed to fulfill.
3.2 Session Border Controller
With the industrialization of VoIP some new needs appeared. The extensibility of SIP helps the vendors to implement new features easily, by adding new headers. However, a few of them, like the NAT traversal and the topology hiding, could not be answered by the SIP protocol. Thus, vendors started to create a new device called Session Border Controller (SBC) to fulfill these needs.
3.2.1 Principle
A SBC can first be seen as a reverse proxy for SIP based systems. A reverse proxy is a device acting, on the server side, as an intermediate between any client and one or several servers. Reverse proxies are often used for HTTP and can have security or optimization features for serving web pages. A SBC is originally placed at the border of the network to interconnect two different ToIP networks and to protect the network from the outside. It can be seen as a toolbox that will add features in all domains of ToIP. It is present for a long time in operator infrastructures and is spreading in companies along with the increase in the use of ToIP. The SBC market is growing fast, and has reached 271 million in 2014 [36]. The most famous SBC vendors are Oracle ACME, Cisco, Alcatel-Lucent and AudioCodes [37]. An example of SBC placement is shown Figure 11.
27 Company A Company B
SBC SBC
SBC ISP A SBC SBC ISP B SBC
Figure 11: Example of SBC placement
A SBC is in the path of all SIP messages. When it receives a SIP packet, it passes it through a lot of processes and then transmits it to the other side. To have more flexibility, it has to act like a B2BUA (described in Section 2.1.2). It will divide each call into two call legs to manage each side independently. The two users will think they are talking to each other directly but they will talk to the SBC instead. On each side of the call, different parameters could have been chosen. For example, one side could use the iLBC codec and the other the G.711 codec with the SBC at the middle which transcodes the audio flow as shown in Figure 12.
Alice B2BUA Bob
INVITE (SDP iLBC) 100 Trying INVITE (SDP G.722) 100 Trying 180 Ringing 180 Ringing
200 OK (SDP G.722) 200 OK (SDP iLBC) ACK ACK
RTP (iLBC) RTP (G.722)
BYE BYE 200 OK 200 OK
Figure 12: Use of a B2BUA to transcode audio flow
28 The SBC can modify the SIP messages before transmitting them in order to remove some fields or rewrite them. It can modify the SDP part to change the codec or the IP ad- dress written in it. It can use SRTP on one side and not in the other side. Fundamentally, a SBC sees and can modify everything, following the chosen security policy.
3.2.2 Differences with existing devices
Now that the principle of a SBC has been presented, it is logical to wonder if a device already present in the ToIP infrastructure cannot achieve these features. A ToIP infrastructure already has an IPBX, understanding SIP well, and a firewall, dedicated to security.
Differences with an IPBX
The IPBX and the SBC act as a B2BUA but they do not have the same purpose at all. The IPBX is here, first, to assume the role of SIP Proxy as described in the RFC 3261 [9] and it acts as a B2BUA to bring features like call forwarding, call transfer or voicemail. In contrast, the SBC is a ToIP toolbox that can relieve some features from the IPBX, but above all, it brings features that can only be made at the border. In addition, the SBC brings another level of abstraction for ToIP security. One of its first role is to protect the IPBX that might be vulnerable, because not really thought for security.
Differences with a firewall
Both firewall and SBC are in the border of the network, one could think that merging them will reduce the costs and complexity of the installation. First, on a security level, this is generally a bad idea to mix features and vulnerabilities. It will remove the higher level of security a SBC can add. Then, even if a firewall can understand the SIP protocol, it can only block messages depending on criteria it received before. For example, it could block calls from domains, prevent REGISTER messages to come from the outside or open RTP port after seeing the SDP part of the INVITE. In fact, rules are only used to know if it has to transmit the message or not based on this particular message, independently of the others. The SBC has a full awareness of the SIP stack so it can really understand the whole conversation and apply smarter filter. Besides, applying filters is only a piece of what a SBC can do and all the other features like NAT traversal or protection against specific SIP attacks are far beyond what a traditional firewall can do.
The SBC has some unique features that can only work at the border of the net- work. Thus, it cannot be replaced by an IPBX or a firewall and it is absolutely necessary for some companies. In the next section, the features offered by a SBC will be presented with more detail. A special attention will be given to the security features. After that the placement of the SBC in the ToIP architecture will be discussed in Section5.
29 4 SBC features
The SBC offers a large range of features. First, it offers internetworking features to connect networks working with different sets of protocols or to allow NAT traversal. Then, it offers QoS features to monitor the calls and to improve the global quality of the service. Moreover, it offers media features like transcoding, media recording or DTMF conversion. Finally, and not the least, it offers useful security features to protect ToIP network against attackers. In this section every aspect on the SBC will be presented with a focus on the security features. Some features are already present in several proprietary SBC whereas others are suggestions that can improve the ToIP of a company and are new.
4.1 Internetworking
Most of the time, the SBC will be at the border of the network and will be the element that separates the VoIP network from the outside network. Thus, it can provide features to facilitate the connection:
Protocol conversion: It can convert protocols between the 2 networks it is between. The most used conversion are between the SDP early offer and SDP late offer, and between SIP and H.323.
SIP normalization: One might think that, because SIP is an open protocol that has been defined in a RFC, there is no incompatibility problem between SIP implemen- tations. Unfortunately, this is not the case and some points in the protocol are not understood in the same way by the different developers. The SBC can easily rewrite some fields to make the message understandable by both sides.
NAT traversal: The SIP protocol has no option to deal with NAT. Some protocols can be used. The most known methods are Session Traversal Utilities for NAT (STUN) [38], Traversal Using Relay NAT (TURN) [39] and Interactive Connectivity Establishment (ICE) [40]. However rely on these protocol is risky and the SBC can bring its own solution by rewritting the fields and transmitting the media flow.
Routing: The SBC can route the calls based on SIP attributes to improve the latency. It can choose the best path looking at the From and To headers, the codecs used or the answer-seizure ratio [41].
4.2 Media
The SBC will see all the SIP traffic and then can decrypt any SRTP sessions acting as a media gateway between both users. Thus, it has access to the media flow to record it or to modify it:
Transcoding: If the 2 sides of a call have no common codec, the SBC can use a different codec for each side and transcode the flow between each side. Table4 has been made using the documentation of each system and device. It shows that, for the phones and softphones, the codecs understood are very disparate and some have only the G.711 codec to communicate, which is not the best codec for both quality
30 and bandwidth. Thus the use of a SBC can be very useful to overcome the codec problem.
Device G.711 G.722 G.722.1 G.722.2 G.723.1 AMR G.726 G.729 G.719 iLBC Opus Android (mobile OS) X X X iOS (mobile OS) X X X Cisco 7800 (phone) X X X X Alcatel-Lucent 4008 (phone) X X Aastra 6739i (phone) X X X Ekiga (softphone) X X X X X X Linphone (softphone) X X X X X X Asterisk (IPBX) X X X X X X FreeSWITCH (IPBX) X X X X X X Cisco Cube (SBC) X X X X X X X X ACME Packet 6300 (SBC) X X X X X X X X Sonus (SBC) X X X X X X X X X
Table 4: Codecs understood by some SIP systems
Recording: Even though users do not like the idea of being listened to, there are several legitimate reasons to record calls of a VoIP service [42]. SIPREC protocol is a very new protocol, still in the draft state for the IETF [43], which aims to give a framework to call recording between a Session Recording Client (SRC) and a Session Recording Server (SRS). The SBC can act as a SRC and record calls. This feature will strengthen the critical behavior of the SBC.
DTMF conversion: There are several ways of transmitted pressed keys on VoIP net- works [44]. Unfortunately some devices might not support the same techniques and will not be able to use DTMF between them. The SBC could play the role of DTMF relay to convert one way to another making DTMF works for both.
4.3 QoS
Everyone has experienced calls with very bad quality that were almost impossible to continue. A SBC can implement several mechanisms to improve the quality of the calls passing through it. It can be done with traditional QoS techniques, by modifying the flow with some algorithms, or with rules to prevent a predictable bad situation:
Protocol efforts: The SBC can check the QoS fields in SIP messages. It can also have an internal prioritization mechanism based on the From and To fields.
Call Admission Control: Contrary to TCP/IP network, in case of congestion, it is simply better to reject the call and avoid customer dissatisfaction instead of putting the SIP messages in a buffer. A Call Admission Control (CAC) defines rules to know if the SBC can let this new call being established or not. Criteria of interest can be the number of call attempts per second or the maximal number of concurrent sessions.
Codec selection: It could be better to select the right codec depending on the available bandwidth to avoid a bad quality call at the beginning of a call. The SBC could know the maximal bandwidth from the parameters or from estimations [45] and influence the codec chosen.
31 Speech Processing: The SBC can apply techniques to improve user experience. The widely used ones are echo cancellation [46], voice activity detection [47], and comfort noise generation [48].
4.4 Security
Section3 has shown that the needs for security in ToIP are very high and cover several domains. The SBC aims to provide protection against known attacks, enforcement of the security policy and damage limitation in case of successful attack. This part will describe all the security measures that a SBC can support.
4.4.1 Upstream protection
First, the SBC could prevent an attacker to prepare an attack by enforcing internal security policy.
High frequency registration
When a UA sends a REGISTER the server responds with a 200 OK containing an expires header indicating the time window during which the binding will be considered as valid. Setting a short period of time will help in the fight against identity spoofing. During the time of the registration, someone could try to steal the IP address of a legitimate user (by ARP spoofing for example). If someone succeed in taking the IP address, he will receive the calls destined to the user and could impersonate him. If the registration is for a short time, the IP address will not be of any use once this time is passed and it will limit the damage. If a very short time has not been set in the expire header, this is because it will consume more bandwidth and might overload the IPBX which has already a lot of things to do. The SBC can be useful here by acting as a special relay for registration. It can control the registration timer in the middle: short timer for the endpoints and long timer for the IPBX. The long timer could be much longer than a regular service timer. The SBC keeps the state of the registration like a regular registrar and sends the REGISTER to the IPBX as long as the registration for the phone is OK. If the associated phone changes its IP address or stop sending REGISTER, the SBC can send a REGISTER with an expires field 0 which is equivalent to an "unregistered" method. Another advantage of this technique is to keep the NAT pinholes (bindings between public and private IP address and port) alive for the phones. The process is shown below in Figure 13. The SBC keeps REGISTER messages every 30s with Alice and transmits them only every 3600s to the IPBX.
32 Alice SBC IPBX
REGISTER expires: 1800s REGISTER expires: 3600s 200 OK 200 OK expires: 3600s expires: 30s
REGISTER Every 30s 200 OK
REGISTER Every 3600s 200 OK
Figure 13: SBC action to allow high frequency registration
Topology and identity hiding
Topology hiding is one of the key function of a SBC and is present since the beginning of the use of SBCs. The problem is simple: a company does not want to reveal its internal network topology. That means that they want their servers and their IP addresses to remain secret from the outside world. As explained in Section 3.1.4, the servers, following the SIP protocol, will put their IP address in the VIA header, making the final recipient aware of all the IP addresses of the servers on the way. The solution to this problem lies in the use of a B2BUA. The SBC is at the border and will start a new call with the outside hiding all the sensitive information from the original call. In addition to topology hiding, a company might want to hide the information their users have put in the fields to provide anonymity. It can be done by rewriting the Contact header, From header, Reply-To header and Call-Info header.
TLS and SRTP enforcement
The SBC is part of every call and must support SIP over TLS and SRTP to provide security for the entire network. The SBC can enforce the security policy by using TLS and SRTP with external hosts each time this is possible and even refuse the call if this is not possible. However, even if the SBC is in charge of the security between the internal network and the Internet, the use of secure protocols between the SBC and the phones is important. The network is not immune against an internal MITM and a maximal protection for the calls has to be applied. It can imply the use of an internal PKI instead of just a certificate for the SBC. Moreover, the SBC will be in charge of security so its TLS
33 implementation must be carefully verified and security updates must be applied quickly after each discovered vulnerability. In addition, the use of a SBC permits to manage carefully the cipher suites that will be used on a single point instead of multiple points. Maybe the phones have an old implementation of TLS that uses non secure ciphers. The SBC can keep a list of the desired ciphers and only agree on them to provide a more secure TLS connection. It can also influence the key exchange protocol used by SRTP and force the use of DTLS-SRTP, which is the most secure way to proceed as described in Section 2.2.3.
4.4.2 Common attack protection
This section presents the protection a SBC can offer against the ToIP attacks that have been described in 3.1.2.
Banner grabbing protection
The banner grabbing technique, used to gather information, could be the beginning of an attack. Most SIP implementations give to the user the possibility of disabling the use of the User-Agent. However, the SBC could also perform this check and remove or rewrite headers when necessary.
SIP user enumeration protection
The user enumeration technique is explained in Section 3.1.2. The SBC is fully aware of the conversation and thus can detect that the response message gives to much information. Then it can modify the message to give the same information, whether the user exists or not. For example, it can always be configured to respond with a 401 Unauthorized message.
Password cracking protection
Maybe the registrar has no security mechanism to detect if someone is trying too many passwords. The SBC could count the number of REGISTER per time period. When the number of password attempts exceeds the limit fixed in the system, the IP address will be blocked for a certain amount of time. The attacker will have no choice but too wait and it will greatly limit the number of attempts he will be able to make.
DoS protection
The DoS attacks are one of the most common attack as shown in Section 3.1.2 and the system needs to be prepared for such attack. The SBC might not be used in addition with a firewall and might be the one to assume the defense of the network. Beside protecting the SIP servers, the SBC is an attractive target and it has to protect itself. An attack could come from the inside and the SBC has to be ready to handle it. Two types of solutions exist: the ones taken from the firewall techniques and the ToIP specific solutions.
34 The SBC can implement the classical solutions used by firewalls. First it can have a solution based on the IP addresses of the messages. This solution is very basic and will not stand against spoofed IP addresses or attacks with thousands of attackers. In addition, the traffic can be classified in categories and different policies applied to them. The traffic can be separated in three categories [49]: the white, black and gray traffics. Several rules can be added to pass from one group to another: for example if a user sends more messages it can be blacklisted, the same if he sends malformed messages or tries to do unusual things. The sorting can be done with a hardware architecture to increase the capacity. Then, the use of a CAC for quality improvement, as explained in Section 4.3, can help in case of such attacks. If too many messages are received, all the values used by the CAC will be quite high and all the new calls will be refused. Of course when a message is received it passes through the whole SIP stack of the SBC and that consumes resources, thus this solution will not stand in case of heavy attack.
Illegitimate BYE protection
The illegitimate BYE attack has been presented in Section 3.1.2. To prevent this attack, TLS may be used to secure the communication and prevent a stranger to send messages. Another way to detect a fake BYE is to look at the entire session instead of just the BYE. If after the BYE, the party supposed to have sent it continues to send RTP packets, it indicates the BYE wasn’t from him after all. This check can be done at the SBC level by delaying the BYE transmission for a few ms. If the SBC was wrong and has dropped a licit BYE, it will be sent again to the SBC because its sender is expecting a 200 OK response from it.
SIP filtering
The SBC analyzes each packet before transmitting it to the internal network. It can easily check all the fields in the SIP header and in the SDP part to see if it is compliant with the standards. If an unknown or invalid field is detected, the SBC can rewrite or drop packets sending back a 400 error message. Thus, it could protect the phones from some malformed packet. However, the SIP stack of the SBC itself might also be vulnerable to fuzzing. The SBC is in the front line of security mechanisms and its stack must be well verified.
Loop detection
The RFC 5393 [2] explained the problem shown in Section 3.1.2 and proposed as a solution the use of a new header field called Max-Breadth. Each server when it forks a message into n messages will divide for each one the initial field value by n. Once the value reach 0, messages are not forked anymore. Thus, it limits the number of messages exchanged at the same step and solve the problem. The RFC 7332 [50] extends this solution to the B2BUA. There is almost no implementation of these RFCs in commercial and open-source software.
35 4.4.3 Downstream protection
Finally, once an attacker succeed in making one of the previous attack, the SBC can take some measures to limit the damages the attacker will be able to make.
High Availability
The need for reliability is very huge with ToIP and the SBC can help us achieving a very low downtime. Every SBC administrator has to be aware that his SBC is a new point of failure in his infrastructure: if it crashes, his whole telephony will be down. Thus, for security reasons, the SBC must have redundancy to reduce the downtime in case of trouble. In addition, if the SBC is placed in a large ToIP network with a lot of calls, maybe one IPBX is not enough. In such case, more than one IPBX is needed and the solution is to split the traffic between them. The traditional way of doing it is to statically assign for each Customer Premises Equipment (CPE) the IP address and port of an IPBX. If it is done with a large number of CPE, on average all the servers will support the same load. However this approach won’t work in every case:
• When a certain server is heavy loaded, others that have lighter traffic cannot share the overload. This happens commonly.
• To prevent overload it will be needed to overdimension the servers which will be wasteful because most of the time the servers will not be used.
To be fully efficient, a device in front of the IPBX that will split the traffic smartly between them is needed. The SBC can assume this role efficiently. When it receives an INVITE for a new call, it will choose one of the IPBX to handle the call following a distribution strategy [49], such as:
• Round robin: The SBC transmits the requests to each server in turn. At the end, all the servers will receive the same number of requests and must have almost the same load. It can be good if all the servers have the same capacity.
• Random select: It is similar to the round robin method. The server is selected randomly, so that all the servers receive the same amount of requests.
• Least busy: The SBC knows which calls are still active on which IPBX so it can select the server with the least number of active sessions.
• Proportional Distribution: A distribution of the calls is made, giving to each server the percentage of the calls it must handle. Then the load balancer tries to respect this distribution.
Diversion protection
The SBC can have the knowledge of the ToIP infrastructure to detect suspicious IP addresses in the header fields. It can analyze the Via header, Record-Route header, Contact header, o and c field in SDP to detect an IP that does not belong to the internal
36 network or is not the one expected. An attacker may use these fields to add a media gateway to listen the call, to add a Record-Route header or a Via header to see the SIP traffic or to start a call without passing through the SBC check. If an unexpected value is detected in one of these fields, the SBC can remove it, putting a right value, or discard the packet, returning a 400 Bad request message.
Call permissions
The SBC can enforce the security policy by preventing some calls from being estab- lished. It can block some numbers with a blacklist, block groups of users to interact with each other and analyze the calls looking for anomalies. The first need for the system is to block illegitimate calls towards internal users. It can simply be someone harassing employees or doing SPIT; or someone that has been detected with the security mechanisms described in this section and who might be an attacker or at least a suspicious person. The easiest way to achieve it is to make a list of IP addresses or domains users should not talk with anymore. If the SBC receives a call from someone in the blacklist, it just drops it and if someone from the inside tries to call someone in the blacklist, it aborts the call and responds with a 403 Forbidden for example. This security feature could also be used to block the premium numbers. They begin with the same prefixes and thus can be easily blocked to prevent toll fraud. Then, the easiest solution to manage users is the group management. Users can be classed in groups and each group will have permissions. In a company it can for example be a user group by department or a group by level of qualification. From these groups some rules can be defined:
• A limit for the outgoing calls to the PSTN network. For example, the human resources group and the secretaries group will have the possibility to make calls to the outside whereas the trainee group will not have this right.
• A limit for the ingoing calls from numbers outside the company.
• A limit for the calls between some groups to prevent calls between users that have no reason to talk to each other.
The IPBX could implement a solution but the SBC could perform the ultimate verifica- tion, thus adding a higher level of security in the ToIP system. An implementation of this feature is presented in Section 7.1. Finally, the SBC sees every call from beginning to end. Thus, as for the IPBX, it can produces the Call Detail Records (CDR). Then, it can use these CDR to detect suspicious calls from unexpected behaviors to raise alerts based on criteria it received before or to block the calls. The feature is explored in details and implemented in Section 7.2.
Steganography protection
The steganography techniques used in VoIP calls have been described in Section 3.1.2. There are several ways to prevent steganography. First, steganalysis techniques can be used to detect the use of steganography. Most of these techniques can be detected more or less successfully. For example the use of the LSB technique can be detect with a 100%
37 success rate [51] and the LACK technique could be detected by looking at the out of order packets. However, each new technique needs its associated detection method and the system is not sure that someone is not using a new undocumented one. Instead of relying on detection algorithms, the system could simply transcode the media flow to another codec. The SBC feature described in Section 4.2 can be reused for this purpose. At worst, it could lower the quality due to the hidden bytes that could tamper the conversion. If the transcoding between two different codecs is not possible because of the endpoint phones, the signal could simply be resampled. In addition to it, the RTP header must be entirely rewritten to remove hidden information that it may contain.
38 5 SBC Architecture integration
During the SBC introduction, it has been said that a SBC was a device placed at the border of the company ToIP network. If the IPBX used by a company is not in its network, the border is the only place a SBC can be put. This can be the case if the administrators have opted for an IPBX in the cloud or if the IPBX is on another site of the company. In the other case, if the IPBX is inside the company network, the placement of the SBC is a point that could improve security.
5.1 At the border of ToIP architecture
5.1.1 Presentation
Placing the SBC at the border of the ToIP network is the most common way to install it. Thus, it will achieve its internetworking, QoS, media and security functions. This configuration is described in the documentation of many SBC vendors. An example of such infrastructure is shown below in Figure 14. The SBC is at the border, between the Internet and the internal ToIP network. The IPBX and the phones are behind it.
Enterprise network
IPBX
SBC Infrastructure Internet (DNS, DHCP, NTP...)
Figure 14: Internal architecture with a SBC at the border of the ToIP network
In case of external call, the phone sends its SIP messages to the IPBX that will treat them and transmit the responses to the SBC. The SBC will pass the messages through its internal processes and transmit them to the recipient. The SRTP flow passes directly through the SBC until the final recipient.
39 5.1.2 Limits
With this configuration, the SBC will handle very well security features for calls from the inside to the outside and conversely. However, the security will not be as good in the other side of the SBC. Indeed internal calls and messages from internal devices to the IPBX will not pass through the SBC. This supposes that the internal network is secure and that the security features offered by the SBC are not needed in these cases. The solution to protect all of the calls is to place the SBC in front of the IPBX, at the center of the network.
5.2 At the Center of ToIP architecture
5.2.1 Presentation
In this scenario, the SBC will be installed at the center, between the phones and the IPBX. Any call or message to the IPBX will pass through the SBC which will apply its security functions to them. To make sure that no phone are talking directly to each other, bypassing the SBC, specific configuration such as private VLANs [52] can be configured on the switches. The VoIP flows are shown in Figure 15. The phone sends its SIP messages to the SBC which will transmit them to the IPBX. Then, the IPBX will respond back to the SBC which will transmit the messages to the right recipient. Note that the SRTP flow passes through the SBC.
IPBX
SIPS
SBC SIPS SBC SIPS Internet SRTP
Figure 15: VoIP flows with a SBC at the center
5.2.2 Limits
In this configuration, the SBC will handle well the security of the network for both internal and external calls. However, this will pose a problem for internetworking. In most cases, the SBC won’t be at the border anymore. Indeed, numerous companies use a NAT and it will be before the SBC when a message arrives. Thus, some features might not be working. For example, this will be the case for NAT traversal and maybe for topology hiding. In addition, several communication protocols will coexist on the network because the conversion will not be at the border anymore.
40 5.3 Combination
The optimal configuration for security and internetworking will be a mix of the pre- vious ones. The first one allowed internetworking features but had trouble with security that were corrected in the second configuration. With two SBCs, one at the center and one at the border, as shown in Figure 16, the advantages could be combined.
Enterprise network
IPBX
SBC SBC Infrastructure Internet NAT, DHCP...
Figure 16: Internal architecture with two SBCs at the border and at the center of the ToIP network
Obviously, this configuration will cost more money for the enterprise as it needs two SBCs instead of one. However, it will allow them to enforce a coherent security policy within the network and at its border.
41 6 SBC Security Test
Now that the main features expected from a SBC have been identified, the adequacy of a solution with the requirements can be evaluated from a security perspective. To do so, I have first established a test methodology with the tests to be done and the information sought. After defining the methodology, I have applied it to an example with Kamailio [7].
6.1 Methodology
6.1.1 Test environment
First, the SBC has to be put into a test environment. The environment must contain at least a SIP server and two phones to make calls. The phones can be real IP phones or softphones in order to ease the use of scripts. The SIP servers can be an IPBX like Asterisk or a SIP Proxy like Kamailio. To examine the packets, it can be useful to have an access to the servers to execute a tcpdump or an access to the switch to activate port mirroring.
6.1.2 Features announced
First, a look can be taken at the datasheets of the SBC to know the features that have been implemented and to compare them with the ones expected. This will give a first opinion of the SBC capacity. Table5 summarizes the security features presented in the previous part.
Feature Purpose High frequency registration Prevent identity spoofing Topology hiding Hide the internal network architecture Identity hiding Hide user information Encryption with TLS Protect signalization Conversion SIP ↔ SIPS Use TLS on the internal side if an external end- point does not support it Encryption with SRTP Protect media flow Conversion RTP ↔ SRTP Use SRTP on the internal side if an external end- point does not support it Force the use of TLS Enforce security policy Choose the right cipher Block weak ciphers from being chosen Force the TLS version Block weak version of TLS from being used Remove UA SIP field Prevent banner grabbing Remove the UA SDP field Prevent banner grabbing SIP user enumeration protection Prevent someone to discover existing extensions Password cracking protection Prevent password brute-force Illegitimate BYE protection Prevent a MITM that would close calls DoS protection Prevent unavailability Call Admission Control Prevent DoS and improve quality
42 Sanitize SIP and SDP Protect the protocol stack Loop amplification detection RFC 7332 and 5393 to prevent amplification attack High Availability Prevent single points of failure Diversion protection Check the IP addresses in the SIP messages Blacklisting Prevent harassment Restrict external calls Prevent toll fraud Prevent call between users Enforce internal phone policy Transcoding Prevent Steganography
Table 5: Overview of the security features
6.1.3 Fuzzing
The SBC is a single point of failure in the ToIP network and it will be at the front line of fuzzing attacks, as described in Section 3.1.2. Several tools have been created to test the SIP implementations [53][54]. However these tools are based on a few SIP messages prepared in advance and already present in the software. Thus, a more sophisticated fuzzer, like AFL [55], can be used. AFL is an intelligent file-format fuzzer that will instrument the executable (either by specially compiling it or using binary analysis) to determine whether or not it’s hitting “new” code on each execution. AFL works with programs that take a file as input. Thus, to use AFL on a server, the source code has to be modified to make it takes the SIP messages as a file instead of by the network interface. If an access to the source code is not possible but only to the binary, some tools can be tried like preeny [56], which takes the input file instead of the fuzzed program and transmit it to the program by the network interface. Both ways of launching AFL can be quite difficult depending on the tested program. However, AFL has shown its efficiency in many cases [55].
6.1.4 Dos/Flood
The SBC will be at the front in case of Dos Attack at the SIP level, one of its jobs could be to reduce the effects of this attack (as explained in Section 4.4.2). Its reaction to attacks has to be tested: to know how many SIP messages it can handle by seconds, how it will react in case of heavy DoS attack, how many simultaneous calls it can manage and what will be the effects on them if someone DoS the SBC during a call. The tools available to make that kind of attacks on SIP are rudimentary [57] and I have not found the appropriate tool for testing SBC DoS reaction. Thus, I have created a Python script, perfectible but sufficient, to validate the behavior of the SBC. The script has some interesting features. First, during the flood, it looks at the response from the server and gives back the statistics to the user in real time. If wanted, a password can be indicated to the application which will then respond to the authentication requests from the server with it. If the password is right, this will make the server accepts the call and increase the resources used. A range of IP to spoof can also be specified to counter the simple DoS protections that could be implemented in some SBCs. The program is composed of three threads: one to send the messages, one to listen the responses from the server and eventually respond to it and one last to display the statistics in the prompt. To
43 increase the speed of the program, the IP spoofing is not made with scapy but by writing the whole IP packet with the script. It can achieve up to 100 000 INVITE messages per second without IP spoofing and 80 000 if the IP spoofing feature is enabled. The message intensity of this application is good but could be improved by using a faster language. During the tests, the softphone Ekiga [58] is used to have the network statistics of the call to know the exact effect of the attack. It gives the lost packets, late packets, out of order packets and the jitter buffer.
6.1.5 TLS quality
The use of TLS with SIP is a major part of the data protection. As the SBC will be part of all the calls in both a client and server role for TLS, its TLS stack must be carefully managed. First, the solution must be configured to use only correct TLS version and the weak SSLv2 and SSLv3 must be disabled. Then, the cipher suites used must be conscientiously chosen. The use of weak ciphers could break the encryption. Furthermore, the TLS stack must be updated to the last version to correct the known vulnerabilities. A configuration audit can be executed with the helps of tools like TLS Prober [59], that detects the implementation of TLS and its version by sending a range of probes, and SSLScan [60] that gives the ciphers used by the server, classed in order of preference.
6.1.6 Common SIP attacks
Some attacks that are specific to VoIP and SIP systems can be tried to see if the SBC offers some protection against them.
User Enumeration
Tools like SIPVicious [61] can be used to test the SBC reaction to extension enumera- tion. The program takes as input the range of numbers that need to be tested, the method (INVITE, REGISTER or OPTIONS) and the address of the server. Then, it returns a list of users the script thinks they exist
Secret brute-force
Once a valid user of the system is known, an attacker can try to guess his password by doing a brute-force attack or a dictionary attack, as explained in Section 3.1.2, with INVITE or REGISTER messages. If the SBC has no specific protection against this kind of attack, it can be really fast. SIPcrack [62] can be used to crack SIP digests. A dictionary can be given to the program to speed up the cracking. For example, with Kamailio on the same network, it can guess a six characters password in a few minutes depending on its complexity and the dictionary used. If the attacker has the control of a router on the way, he can fake the source IP address in order to avoid SBC protections. The IP router will see the response even if the message never goes back to the attacker computer.
44 Banner grabbing
The information gathering protection can simply be done by looking at the content of the messages with a tool like Wireshark. However, to be more efficient, I have written a Python script which takes an IP address for input and return the user agent of the SIP software running on the targeted system.
Illegitimate BYE
The SBC could implement some protections against Illegitimate BYE. I have written a Python script which listens on the network for SIP messages. When it receives a SIP message, it extracts the parameters and sends a BYE to close the conversation.
Amplification attack
The amplification attack, explained in Section 3.1.2, could tear down any SIP proxy that does not have the protection against it. A simple python script has been written which, given the information about the users and the servers, will send the messages to start the amplification loop.
6.2 Test of Kamailio
Many people use Kamailio as a SBC. One could argue whether Kamailio is a true SBC or not. In fact it does not act like a B2BUA with a different call on each side of it. Nevertheless, it supports a lot of features expected from a SBC like NAT traversal, topology hiding or SIP header modification. Kamailio has more than 200 modules, making of it a very efficient SIP toolbox. I have not identified an open source SBC project. If someone wants a free SBC, he has to configure a SIP proxy like Kamailio or FreeSwitch to act like a SBC, even if it is not its first goal. Kamailio is one the most flexible free SIP tools available. It is one of the two forks of the OpenSER project with OpenSIPS. However Kamailio is more used than OpenSIPS and the community is more active with it. This explains why Kamailio is sometimes chosen and configured as a SBC.
6.2.1 Test environment
The equipment available for the environment is composed of two computers, a Cisco Switch and two IP Phones. On each computer, virtual machines (VMs) have been created to simulate several computers and servers:
• On the first computer, three Debian are running: two are used as softphone with Ekiga [58] and the last one is used to launch ToIP attacks. The softphones have 1GB of RAM and one core at 3.40GHhz as CPU and the attack VM has 16GB of RAM with 8 cores at 3.40GHz as CPU.
• The second computer has been split into two systems, running on Debian again. The first contains an Asterisk instance and the second a Kamailio instance. Each one has 3.5GB of RAM and 5 cores at 2GHz as CPU. Kamailio and Asterisk have
45 been built from the last stable release available on their repository ([63] and [64]), thus the version used is 4.3.4 for Kamailio and version 13.6.0 for Asterisk.
• Each VM has been configured in bridge mode to avoid NAT problems.
The architecture is shown below in Figure 17. Kamailio is in front of Asterisk and between Asterisk and the phones. First, Asterisk has been configured with a basic configuration. One context has been created with a few users in it. The configuration files used for the experiment are show in AppendixC. Then Kamailio had to be put in front of Asterisk and both configured in order that every packet going to Kamailio is transmitted to Asterisk that will respond to Kamailio. The final user must not see other IP address than the one of Kamailio and everything, including the media flow, has to pass through Kamailio. To make Asterisk respond to Kamailio, the field outboundproxy has been added in the Asterisk SIP con- figuration file. For Kamailio it was much more difficult and the routing logic has been built from scratch. When Kamailio receives a request from a phone, it changes the IP address putting the one of Asterisk and transmits it to Asterisk. On the other way, it does the opposite by replacing the IP address of Asterisk by its own. Using the t_relay() function makes Kamailio aware of the state of the calls instead of just using the stateless forward() function. This difference allows the use of more sophisticated function in the configuration, to manage the RTP session for example. The rtpengine module makes the RTP flow passes through Kamailio with a few changes in the configuration. In addition, the topoh module hides the contact and Via information when Kamailio responds to the phone, hiding totally the existence of Asterisk behind. The full configuration file is shown in AppendixB. Finally, the support of TLS and SRTP has been added by creating a CA and certificates for Asterisk, Kamailio and the two IP phones. Then, the configuration of the phones and servers have been adapted to support SIPS and SRTP. Calls with TLS and SRTP are possible with the IP phones or just with SIP and RTP with the softphones. This will allow a deeper test of the system to be done. In addition, the few services that will be used by the IP phones for configuration (HTTP server for configuration files download and NTP server to set the time on the phone) have been configured on the VM containing Kamailio.
46 Asterisk
Kamailio
IP phone IP phone Softphone Softphone
Figure 17: Test environment of Kamailio
Every packet, SIP as RTP, will go to Asterisk through Kamailio and the response will be sent back through Kamailio. The phones will never talk directly nor have knowledge of its existence. Kamailio will see everything.
6.2.2 Results
Features implemented
Kamailio has a very flexible configuration that mixes parameters and scripting lan- guage syntax. Some features can be obtained just by setting parameters while others require a complex script in the routing logic. Table6 below shows the security features implemented in Kamailio. A feature is considered as implemented only if no programming is needed, except a few lines in the routing part, to make it work.
Feature Present Comment High frequency registration No Not implemented Topology hiding Yes With topoh module Identity hiding Yes By rewriting the message pseudo-variables in the routing logic Encryption with TLS Yes With TLS module Conversion SIP ↔ SIPS Yes With t_relay functions in TM module Encryption with SRTP Yes With rtpengine module Conversion RTP ↔ SRTP Yes With flags in rtpengine module Force the user of TLS Yes With t_relay functions in TM module Choose the right cipher Yes With cipher_list parameter of TLS module Force the TLS version Yes With tls_method parameter of TLS module
47 Remove UA SIP field Yes With server_header parameter Remove the UA SDP field Yes With textops module User enumeration protection Partial Simple only if authentication by Kamailio Password cracking protection Yes With pike module to block IP addresses Illegitimate BYE protection No Not implemented DoS protection Partial With pike module Call Admission Control Partial Possible to implement a few parameters in configuration Sanitize SIP and SDP Yes Does not transmit if packet not understood, more checks with sanitize module Loop amplification detection Partial Only check its address in Via headers High Availability Yes With VRRP protocol [65] Diversion protection Yes Using textops and sdpops modules with comparisons in the routing logic Blacklisting Yes With userblacklist module Restrict external calls Yes With permissions module Prevent call between users Yes With permissions module Transcoding No Not yet implemented in rtpengine
Table 6: Security features implemented in Kamailio
Fuzzing
To use AFL on Kamailio, the main.c file had to be modified to change its behavior. In- stead of launching Kamailio process, it had to take a file as input and use the receive_msg function on it. The receive_msg function in receive.c is the function called first when a message is received. It parses the message before transmitting it to the other processes. During the modification, only the unnecessary parts had to be removed, keeping all the parts regarding the environment initialization. Once the new main is ready, Kamailio can be compiled using the afl-gcc compiler that will add some instructions required by AFL. Some classical SIP messages have been given to AFL as input. Then, AFL has been started in master/slave mode to use all the core of the computer and make the fuzzing faster. After several days of test, AFL found some interesting messages supposed to crash Ka- mailio. Unfortunately, trying them against a running implementation of Kamailio showed that they were only false positive. The test could be extended by adapting differently the main file or by doing it longer.
Flood
The SIP DoS script has been launched on the attack VM with Kamailio as the target. In order to test different attack intensities, the number of messages sent by second has been varied. For each test, the RAM and CPU usages have been measured, as well as the number of message transmitted, the number of response sent back and if it was possible to establish a call during the attack. The attacks last 60 seconds to gather enough data
48 to make the average. The CPU and RAM usages have been recorded every second during the attack to to average at the end. The results are shown in Table7 and in Figure 18.
INVITE/s % CPU % RAM Transmitted Answered Call Call quality 105 910 73.6 23.7 1.84% 0.23% No 83 110 61.2 15.8 0.00095% 0.59% No 65 990 78.6 17.4 0.00075% 3.77% No 46 095 77.8 16.8 0.00090% 5.33% No 26 760 63.2 16.6 0.0014% 7.75% No 9 960 34.7 15.7 0.0049% 6.87% No 5 050 52.99 16.0 0.0085% 31.6% No 2 560 57.6 16.3 0.017% 40.6% Yes Perfect 1 310 30.3 15.6 0.038% 31.0% Yes Perfect 525 19.8 15.6 0.097% 34.5% Yes Perfect 270 12.5 15.6 0.18% 41.3% Yes Perfect 91 5.5 15.6 0.53% 100% Yes Perfect
Table 7: Kamailio DoS results
Figure 18: CPU and RAM usages versus message intensity during DoS attacks
First the results are not linear. One possible explanation is that Kamailio, depending on the message intensity, launches some processes or not for the message, involving more or less resources. Furthermore, the memory consumption remains the same during the whole test regardless on the number of message received. In addition, looking at a pcap trace, Kamailio seems to believe that the new INVITE messages are actually the old ones
49 and thus resent the same messages from Asterisk instead of transmitting them to Asterisk again. A possible reason is that the IP addresses and the users in the INVITE are the same and it explains why the transmitted rate remains low contrary to the answered rate. Nevertheless, Kamailio has never reached 100% CPU usage and thus has never blocked the whole system. The SIP services were down sometimes, but the other services running on the server were still up. The media gateway process is handled by rtpengine binary and not Kamailio. Thus the RTP flow continued to pass through the server even if no new call could be established. Unfortunately, these results also show that an attacker does not need to have a huge botnet, nor computing power, to successfully prevent new call from being established. Mainly because Kamailio has no specific mechanism against it.
TLS
Kamailio TLS implementation is based on the OpenSSL package [66] which is the most used open-source implementation of the TLS protocol. Thus the vulnerabilities of Kamailio are the same as the OpenSSL ones. The choice of using a known cryptographic library is a good idea because it avoids to build a new stack, and so limits the vulnerability risks inherent in development. However, history has shown that vulnerabilities are still possible and several have been discovered the past few years [67]. The TLS vulnerabilities in Kamailio depends on the OpenSSL version used, the code in the TLS module and the configuration made by the administrator. In the test environment, the version of OpenSSL used is 1.0.1k from the Debian official packages. Asterisk works the same way as Kamailio with TLS. However, issues regarding the implementation of TLS in the phones were encountered. In fact they use an old custom version of OpenSSL with only a few ciphers available. From these ciphers, there are poor ones using:
• a anonymous Diffie-Hellman which is subject to MITM attacks [68]
• an export key which is by design short and can be broken easily [69]
• DES which uses only a 56-bit key [70]
• RC4 which is not considered as secured anymore and has been removed from OpenSSL [71]
After removing the ciphers using them, only three ciphers remains that can be used. However, if a Diffie-Hellman key exchange protocol is chosen, the key generated by the phones will be too short and refused by the OpenSSL version of Kamailio because of this vulnerability discovered recently [72]. Thus, those ciphers can be removed and it remains only one cipher : TLS_RSA_WITH_AES_128_CBC_SHA. This cipher does not provide forward secrecy, which means that a leak of the private key compromises all the previous TLS sessions. So, in the end, the problem with the infrastructure did not come from the SBC but from the phones themselves. In a TLS exchange, this is the server which decides and Kamailio has an option to choose the cipher suites that must be used. This is why having a good TLS implementation on the SBC is important.
50 Common attacks
As described in Section 6.2.2, Kamailio can protect the system from some attacks. If only TLS and SRTP are used, some of these attacks are blocked but here the supposition will be made that the system works without any encryption. It could happen for external calls for example. First, the user enumeration technique has been tried to discover the extensions on Asterisk. Asterisk has been configured not to provide protection against this attack, to let Kamailio operate. The script has successfully detected all the Asterisk users. In fact Kamailio can protect the system against this, but only if it manages itself the authenti- cation. In this case, it will ask for the authentication before sending any indication in the response. If the authentication is managed by something else, like Asterisk, it cannot stop the information leak from Asterisk easily. Maybe it is possible to do it in the configuration using a small script. However, in this case, Asterisk has the option alwaysauthreject that can be set to Yes to make Asterisk behave like Kamailio, asking for the authentication before. Secondly, the secret brute-force script has been launched with REGISTER to find some passwords. If the pike module has been activated in Kamailio, the number of messages per extension per unit of time can be limited and an attacker will be blocked if he reaches the limit. As the attacker cannot spoof his IP address in this attack, this protection is efficient and is able to protect the system. Then, the banner grabbing script has been executed to gather some information about the system. The use of the server_header parameter and the textops module prevent every information to pass through. Thus, the script gathered no real information about the system and it remains as a black box for the attacker. The effect of the amplification attack is limited by the timeout parameters that Ka- mailio set for each request. However, the attack generates almost 300 000 SIP messages between the two Kamailio proxies and thus can be used against Kamailio. Finally, no protection against illegitimate BYE or steganography are implemented in Kamailio so these attacks are possible without any restriction.
6.2.3 Conclusion
The previous parts have shown that Kamailio can offer a lot of features in different domains. Its domain of application remains in the comprehension of the SIP protocol and almost everything can be done regarding the SIP messages. It has also shown a good resistance to fuzzing. However, it has not been conceived as a SBC, and thus does not offer some features that could be needed like transcoding or a more advanced DoS protection. Nevertheless, it can be enough for most of the companies if the ToIP administrators are willing to spend enough time on the configuration.
51 7 Improvements
The two previous parts have shown the weaknesses of Kamailio and the features miss- ing in it. Several companies use Kamailio as a SBC because it is the open-source tool that achieves most of the SBC expectation because of its flexibility. Thus, this is logically the software we have chosen. From what could be implemented, the choice has been made to focus the work on toll fraud because it is one of the major ToIP risk for companies. The work on Kamailio has been divided on active and passive measures. For the active side, the permissions module of Kamailio has been improved to add the possibility of spec- ifying validity periods in rules. Then for the active side, a program to detect suspicious calls in a ToIP network based on log analysis has been written.
7.1 Permissions module
Kamailio has already a very old module to set up permissions between users to indicate if an employee has the right to call another employee [73]. Two files are needed, one to deny and the other to allow. In each file, rules can be set up with regular expressions using the syntax:
from_list [EXCEPT from_list] : req_uri_list [EXCEPT req_uri_list]
For example: “^sip:3677[0-9]” : “^sip:361[0-9]”. When a call is received, the sys- tem will look at the allow file to see if it matches one rule. If there is a match the call is then allowed. Otherwise, it opens the deny file looking for a match. In case of a match, the call is not allowed. However, this module can be improved to add more flexibility in the rules. It could be useful for some users, like companies, to specify a specific time for each rule. For example, a company could want to disable the possibility to call international numbers after working hours, while keeping the possibility to call managers and colleagues. It will reduce the possibility of toll fraud during the night. Right now this is not possible to add such a rule in Kamailio, or at least not easily.
7.1.1 Logic
The best way to do it, was to start from the permissions module and to add the feature in top of it. The new format of rules must be compatible with the old one to avoid troubles during Kamailio upgrade. This syntax satisfies these requirements:
from_list [EXCEPT from_list] : req_uri_list [EXCEPT req_uri_list] : time_recurrence
If no time_recurrence parameter is specified and the rule uses the same syntax as before, the system will have to consider the rule as valid permanently. If a correct time recurrence parameter is given, the rule will be valid only during the specified period. A syntax for the time recurrence parameter has to be chosen. In the core of Kamailio there is already a library to specify time recurrence rules following the RFC 5545 [74].
52 The RFC 5545 defines a standard to share calendar data, named iCalendar. This standard is used by many products like Google Calendar, Apple Calendar or Thunderbird. Among others, it gives a syntax to define recurrence rules. The library in Kamailio uses this syntax which is almost the one in the RFC:
[startdate]|[duration]|[frequency]|[until]|[interval]|[byday]|[bymonthday]|[ byyearday]|[byweekno]|[bymonth]
It is based on the part 3.3.10 of the RFC with the addition of a parameter duration de- fined in the part 3.3.6 of the RFC. In fact, the other parameters indicate an event with its repetition over time whereas the duration indicates how much time the event will stand. Of course, the duration must be shorter than the next repetition of the event. For ex- ample 20151006T103000|PT2H30M|weekly|20161006T103000|2|SA,SU defines a rule from the 6th of October 2015 to the 6th of October 2016, one week out of two, the Saturday and Sunday, starting at 10:30 and during 2 hours 30 minutes.
7.1.2 Implementation
Kamailio is written in C for all parts. The module has two files of interest here, parse_config.c to parse the rule files and create the associated rules into the system, and rules.c to find a match among the rules. First, the structure of a rule in rules.h was changed to include the new time recurrence parameter. Then, the parse_config.c was modified following the new rule syntax. The tmrec library was used to create the time rule from the string. To finish, the rules.c file was modified to add the comparison between the time of the call and the time recurrence parameter during the research of a matching rule. To achieve it, the functions included in the tmrec library were very useful. Once the implementation is finished the module can be compiled and added into Kamailio, adapting the configuration file to include it. Two softphones has been configured with different users to test the accuracy of the rules defined in the files. As the main mechanism of this improvement is the parsing of the recurrence rule, which relies upon existing code, the tests were quite fast.
7.2 CDR analysis
In addition to the use of strict rules, for example with the permissions module above, the system can have a tool to analyze the call afterwards and to detect anomalies. Most of the SBCs can produce Call Detail Records (CDRs) directly into a file or a database. The CDRs allow the administrators to keep an eye on the calls. As a border element, the SBC logs all the calls coming from the ToIP network without missing one. Once all the statistics have been gathered, data analysis can be done to detect fraud and raise alerts. The objective is to ease the CDR analysis from the administrators by creating detection algorithms.
7.2.1 Logic
The idea is to cover the CDRs one by one, doing tests to classify each one. First, strict rules can be applied to classify a CDR. For example, too long calls can be logged as well as the calls to premium numbers, the calls to dangerous international destinations
53 or just international destinations. Then, rules applying on the whole set of CDRs can be set. For example, if two calls from the same user have exactly the same duration, this is doubtful and might indicates that the calls are automatically made. If a user makes too many phone calls in a small time interval this can be considered as suspicious too. In addition to these rules, the system can try to detect deviation of behavior for an employee by using machine learning techniques. It has been showed that it was possible to build a profile for each employee and then quantify the deviation to compare it with a limit [75][76]. They achieve a True Positive Ratio (TPR) of 90.23% and a False Positive Ratio (FPR) of 1.87%. These are quite good results and these works will be the foundations of the algorithm used by our system.
Make profiles
First, a user profile has to be defined. This tool will be used inside a company, thus some parameters will not be as pertinent outside this context. For a user, the average number of calls per working hour, the mean duration, the percentage of calls made during work time, the percentage of calls made to international and the number of calls toward each number will be kept. When a call is received, the program computes a coefficient for the call based on what it knows for this user. For example, if a user, who has never made international calls, starts calling someone in another country for 45 minutes at midnight, the system has to detect it. If the employee making the call is used to do calls like this one, maybe it is a regular call and it does not have to raise an alert. Now that the user profiles have been defined, the calls that will be added to this user’s profile have to be detailed. The first idea is to learn, at the beginning, during a certain amount of time, and then to consider that enough data have been gathered to build the profile of each user. The main problem with this technique is that it only learns at the beginning. If an employee changes his behavior, because he is now working on something else, his profile won’t be updated in consequence. To have an adaptive profile maker, the system has to learn from every call it receives. Learning from the new calls, it will see such changes of behavior. But still one problem remains: if the user changes its behavior, the old calls will still have an influence on the data. The best way will be to have a moving learning period. The system learns on a given time period and then it will move, removing from the data the old calls that are not in the learning period anymore and learning from the new calls. The figure 19 illustrates the process. The learning period moves following the new calls. The learning process has to be modified to take care of the users that take holidays and are not here for a long time. When they will come back, there profile will be empty and the system will have to wait again to fill the profiles and during this period it won’t detect a thing. A minimal number of calls in the learning data can be set to address this issue. When a call has to be removed, because it is older than the beginning of the moving learning period, the program checks if there are still enough calls in the data, and if not, it keeps the call even though it should be deleted.
54 Learning period
Present Past Time
Figure 19: Learning period in time
Coefficient computation
The coefficient will be a multiplication of terms that will be computed depending on the user profile. The multiplication in the process, instead of an addition [75], allows each term to have an impact depending on how strange the call is. For example, the term for the international calls has to be greater for someone who never makes international calls than for someone who is used to. The coefficient will be A ∗ B ∗ C ∗ D where A is the term for the duration of the call, B the term for the hour of the call, C the term for the international calls and D the term for the call frequency. In each term, a dimensioning parameter Ki will be used. For A this formula will be used:
( duration A = K1 ∗ log2( mean duration + 1) if duration ≥ mean duration mean duration A = K1 ∗ log2( duration + 1) if duration < mean duration where duration is the duration of the current call and mean duration is the mean duration of the calls of this user. A log is used to avoid that this term gets a too important value in case of a very long or very short call. The addition in the log is to avoid that the term approaches 0 too closely. For B and C these formulas will be used:
( 1 B = K2 ∗ (( − a) ∗ rate_off_hour + a) if call not during working time, 1 otherwise K2 1 C = K3 ∗ (( − a) ∗ rate_international + a) if call is international, 1 otherwise K3 where rate_off_hour is the percentage of calls made by the user outside working hours and rate_international is the percentage of calls made by the user to international des- tinations. A linear function has been chosen for these terms. If the call is very different from the behavior of the user, the associate term can be up to three times. For example, if a user makes an international call for the first time (rate_international ' 0), B will be three times greater than for a user who makes only international calls. nb_calls For D, the formula D = K4 ∗ log2( nb_calls_dest ) will be used where nb_calls is the total number of calls made by the user and nb_calls_dest is the number of calls made by the user towards the destination of the current call. This coefficient is greater if the proportion of calls made towards the destination is small. Thus, it indicates that a call made toward a new destination is more suspicious that a call made toward a colleague the employee is used to call.
55 At the end, the coefficient is compared to a limit. If it is greater than the limit it raises an alert, does not add the call to the profile of the user, and finally passes to the next CDR.
7.2.2 Implementation
For the implementation, Python has been used. It is not the fastest programming language but still it shows good performances and allows me to program quickly. As the algorithm was still uncertain at the beginning, it was useful to be able to modify it rapidly to see the results. It can be run into any server because it just needs the CDRs provided by a SBC or an IPBX. Nevertheless, if it needs to be integrated directly into an existing software, it can be adapted into the software language. The program is composed of two classes: the User class which contains the user profiles and the CDR class which contains the attributes of the Call. A CDR belongs to a user whereas a user can have several CDRs with the relation types belong to and learning for the CDRs in the learning period of the user. The User class has several methods, including one method to update the CDRs in its learning period, and one method to update the profile characteristics based on the CDR in the learning period. When a call is received, a first test is made with the strict rules about the too long calls, the destination or if the call has the same duration than another call in the learning period. After that, if the call passed these tests, the machine learning algorithm above is executed. Then, the CDRs in the learning period are updated and this CDR is added if it is not suspicious. Finally, the user profile is recomputed. All the suspicious calls are kept and the program writes them into a log file with the reason of there guiltiness.
7.2.3 Tests
The algorithm has several undetermined coefficients that have to be dimensioned first. The problem remains that, to dimension them, a test set of CDRs composed of known fraudulent calls is needed. Then, the program is launched over this test set and computes the TPR and the FPR to measure the efficiency of the algorithm for a given set of pa- rameters. Unfortunately, CDRs are very sensitive data not easily findable on the Internet and I did not find any source. Thus, I tried to generate them myself.
Test set creation
A Python tool has been written to create users with different profiles and CDR ac- cording to these profiles. A user profile is first composed of a set of other users who are the “friends” of this user. These friends are the ones this user calls. To be realistic, it was not possible just to choose a random recipient for each call because a user often calls the same people. The profile is also composed of probabilities to call international destinations, to call during working hour, to make calls during weekends, the mean duration and the mean excess (standard deviation) of the calls. For the recipient, one of the user’s friend is taken considering the probability of international calls. For the hour of the day, a Gaussian centered on 15:00 with a sigma of 5:00 has been chosen. A value in working hours is taken depending on the probability given in the user profile, the day of the week being chosen with the weekend probability of this user. For the duration, a chi squared distribution
56 has been considered. Such a distribution reflects the way calls are made: a lot of calls centered from 0 to twice the average deviation with a few longer calls still possible. The Gaussian could not be used because it was possible to have negative values, it was too much centered (more calls with a small duration are needed) and the probability to have a very long call was too small. Figure 20 shows a spider diagram of the profile of one user in the test set. The hour distribution is shown in Figure 21 with the reference Gaussian in green. Once these “real CDRs” have been created, fake ones can be generated into them. For the fake ones, unusual properties are chosen: an unusual duration, an international destination from the whole phone numbers set if the user makes more local calls (a local destination in the opposite case) and the same to know if the call is made during working hours or not. Then, all these fake CDRs are added into the list, and their “IDs” are kept in a separate file.
Figure 20: Example of a user profile
57 Figure 21: Call hour distribution for a user
Dimensioning
Now that the training set is ready, the goal is to find the best parameters for the algorithm. To do so, the program will be run with parameter values and the FPR and TPR will be computed. The parameters that gave us the best results will be the better ones. Unfortunately, the program takes several minutes to process and it has at least 6 parameters, so every possibilities cannot be tested. The time complexity of the operation will be in power of 6 so a different technique has to be applied. As it was not the subject of this whole master thesis, values giving good results will be considered as satisfying, even though they are not the optimal ones. If someone wants to implement this method in its product, he will have to test if these values are still good in his case. In order to find these values, a step by step process will be applied. At the first step, very different values for each parameter will be chosen. After this first computation, the program is launched again around the values that gave the best results before. The same process is repeated until satisfactory results are achieved. After several days of computation, the following interesting results have been obtained:
K1 K2 K3 K4 a limit TPR FPR 0.4 1.0 0.6 0.6 3 3.7 0.688 0.046 0.3 0.7 0.5 0.6 3 3.5 0.539 0.005 0.3 0.7 0.5 0.5 3 3.5 0.363 0.001
Table 8: FPR and TPR results
These results are satisfactory. The second line means that the program can detect more than half fake calls while raising only one false alert every 200 regular calls. Of
58 course, along with more fake calls detected, the program will also have more false posi- tive. The Receiver Operating Characteristic (ROC curve) below in Figure 22 illustrates the performance of the call classifier by representing the TPR and FPR for numerous parameters values. It shows that, for a few fake calls (almost 20%), the algorithm cannot tell if they are fake or not. The algorithm is not adapted to detect them.
Figure 22: Receiver Operating Characteristic for the call classifier
The parameters can be chosen depending on the FPR and TPR required. Maybe a single suspicious call cannot be missed and then a high TPR will be chosen, even though the FPR could be higher. On the contrary, if the the administrator does not want to spend time on false positive alerts, a smaller FPR will be chosen along with a smaller TPR. These results seems good, however the tests was performed on generated CDRs and this is the main limitation of these tests. This algorithm has to be confronted with real data from companies to be improved.
59 8 Conclusion and future work
8.1 Accomplished work
In this thesis, a study of the security threats affecting a ToIP architecture have been described and the Session Border Controller has been presented and characterized, based on the responses to these vulnerabilities. First, its features have been described, based on the vendors data sheets and original ideas. Then, its integration within a ToIP architecture has been discussed in regards of the security requirements and a new proposition of design has been proposed. A test protocol has been introduced and several tools have been developed. It included a DoS program, and scripts to exploit common SIP vulnerabilities. The methodology has then been applied on the free software Kamailio. Kamailio has been first configured as a SBC and integrated with Asterisk in a test environment. This model was new and can be reused in a company architecture. The tests have shown the quality of Kamailio and how it can be improved. From these possible improvements, two have been implemented. First, the possibility of adding a time parameter in call permission rules has been added in the permissions Kamailio module. An administrator has now the ability to prevent calls between numbers based on the time of day. Secondly, a threat detection tool has been written in Python to read the call logs produced by the SBC and raise alert in case of a suspicious call. It is based on a machine learning algorithm that builds a profile for each user and then uses this profile to detect behavior deviations in new calls. The tests have been conducted on generated data and have achieved good ratios (TPR at 0.69 with FPR at 0.046).
8.2 SBC conception
To finish this study on the SBC, a discussion can be started about the correct way to conceive one. The SBC sees everything, signalization messages as media flows. If an attacker gains access to the administration interface, he will be able to use some regular features to record calls, redirect them, or even establish calls. If he gains access to the whole system with a root shell by finding vulnerabilities, he will be able to execute his own scripts, and do everything he wants on ToIP with almost no limitation. As the SBC is the security device in the ToIP architecture, no other system could detect nor prevent the effects of such attack. Thus, the SBC is a very critical device and therefore needs particular attention about security. First, the hardware side can be examined. The SBC can be a specific device or an image that can be launched on a virtualization server. With a specific device, some features can be done more efficiently like transcoding or DoS protection because they can rely on dedicated hardware instead of just the processor. However this configuration will be at the same time less flexible than a virtual machine, and it will be harder and more expensive to achieve redundancy. The choice depends on each situation and on the needs of the client. In addition, hardening must be done to reduce the surface of vulnerability. The vendor can close the unused network ports or parameter strict rules in the firewall. The administration interface must be reachable through a separate dedicated network. During the development, the software must be securely designed to reduce the impact
60 of a bug. A privilege separation model can be applied by separating the key SBC actions between them. For example, the TLS part manages the private keys and thus is critical for confidentiality. A bug in a vulnerable element, like SIP parsing, must not lead to a private key leak. The same separation has to be applied between the most critical elements of the SBC and for each part privileges have to be carefully chosen.
8.3 Future work
Even if Kamailio has been configured to work as a SBC, it was not really thought for that and a few key features are missing. It goes from security features (CAC, loop amplification protection or DoS protection) or internetworking features (high frequency registration, protocol conversion) to media features (recording and transcoding). Imple- menting them requires a full knowledge of Kamailio internal structure and thus takes time. Once these features will be implemented, and the configuration eased, Kamailio will be a real competitor to proprietary solutions. The existing tools didn’t allow to perform all the proposed tests, thus I have written new attack scripts. Some are new while others bring new features to existing attacks. These scripts could be gathered in the same python program to simplify their use. The work about threat detection using CDRs can be improved by using real data as input to dimension the coefficients. Such data can only be obtained by a service provider and are the only way to really test the program. This way, its quality could be proven, and improvements may be found.
61 References
[1] R. Frederick V. Jacobson H. Schulzrinne, S. Casner. RFC 3550: RTP: A Transport Protocol for Real-Time Applications. 2003.
[2] A. Hawrylyshen B. Campen R. Sparks, S. Lawrence. RFC 5393: Addressing an Am- plification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies. 2008.
[3] Skype statistics. http://blogs.skype.com/2013/08/28/skype-celebrates-a- decade-of-meaningful-conversations/. Accessed: 2015-12-14.
[4] Instat. http://www.instat.com/. Accessed: 2015-12-16.
[5] Infonetics. http://www.infonetics.com/pr/2015/VoIP-UC-Services-Subs- Market-Highlights.asp. Accessed: 2016-01-06.
[6] Nettitude. VOIP Attacks On The Rise. 2015.
[7] Kamailio. http://www.kamailio.org/w/. Accessed: 2015-11-30.
[8] J. Kuthan U. Abend H. Schulzrinne D. Sisalem, J. Floroiu. SIP Security. Wiley, 2009.
[9] G. Camarillo A. Johnston J. Peterson R. Sparks M. Handley J. Rosenberg, H. Schulzrinne and E. Schooler. RFC 3261: SIP: Session Initiation Protocol. 2002.
[10] SIP header fields. http://www.iana.org/assignments/sip-parameters/sip- parameters.xhtml#sip-parameters-2. Accessed: 2015-11-25.
[11] Asterisk. http://www.asterisk.org/. Accessed: 2015-11-30.
[12] Freeswitch. https://freeswitch.org/. Accessed: 2015-11-30.
[13] A. M. Hagalisletto and L. Strand. Formal modeling of authentication in SIP regis- tration. 2008.
[14] L. Strand and W. Leister. Improving SIP authentication. 2011.
[15] C. Jennings J. Peterson. RFC 4474: Enhancements for Authenticated Identity Man- agement in the Session Initiation Protocol (SIP). 2006.
[16] A. Jeffrey V. Gurbani. RFC 5922: Domain Certificates in the Session Initiation Protocol (SIP). 2010.
[17] M. Naslund E. Carrara K. Norrman M. Baugher, D. McGrew. RFC 3711: The Secure Real-time Transport Protocol (SRTP). 2004.
[18] J. Callas P. Zimmermann, A. Johnston. RFC 6189: ZRTP: Media Path Key Agree- ment for Unicast Secure RTP. 2004.
[19] F. Lindholm M. Naslund K. Norrman J. Arkko, E. Carrara. RFC 3830: MIKEY: Multimedia Internet KEYing. 2004.
62 [20] E. Rescorla B. Desruisseaux. RFC 5764: Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP). 2010.
[21] D. Wing F. Andreasen, M. Baugher. RFC 4568: Session Description Protocol (SDP) Security Descriptions for Media Streams. 2006.
[22] C. Perkins M. Handley, V. Jacobson. RFC 4566: SDP: Session Description Protocol. 2006.
[23] Skype. http://www.skype.com/fr/. Accessed: 2015-12-01.
[24] TeamSpeak. https://www.teamspeak.com/. Accessed: 2015-12-01.
[25] Jingle. http://xmpp.org/about-xmpp/technology-overview/jingle/. Accessed: 2015-12-02.
[26] E. Guy F. Miller K. Shumard M. Spencer, B. Capouch. RFC 5456: IAX: Inter- Asterisk eXchange Version 2. 2010.
[27] Communications Fraud Control Association (CFCA). 2015 Global Fraud Loss Sur- vey. 2015.
[28] C. Jennings J. Rosenberg. RFC 5039:The Session Initiation Protocol (SIP) and Spam. 2008.
[29] M. Collier and D. Endler. Hacking Exposed Unified Communications & VoIP: Secu- rity Secrets & Solutions. McGraw-Hill Osborne, 2014.
[30] M. Farooq Z. Rafique, A. Akbar. Evaluating DoS Attacks Against SIP-Based VoIP Systems. 2009.
[31] Eric Y. Chen and Mitsutaka Itoh. Scalable Detection of SIP Fuzzing Attacks. 2008.
[32] Wojciech Mazurczyk. VoIP Steganography and Its Detection – A Survey. 2013.
[33] VoIP Hopper. http://voiphopper.sourceforge.net/. Accessed: 2015-12-04.
[34] Vulnerabilities in Cisco IP phones. http://engineering.columbia.edu/seas- computer-scientists-find-vulnerabilities-cisco-voip-phones. Accessed: 2015-12-07.
[35] M. Ali Akbar M. Zubair Rafique and Muddassar Farooq. Evaluating DoS Attacks Against SIP-Based VoIP Systems. 2009.
[36] SBC market growth. http://www.infonetics.com/pr/2015/4Q14-Enterprise- Session-Border-Controllers-Market-Highlights.asp. Accessed: 2015-12-07.
[37] SBC market statistics. http://www.infonetics.com/pr/2014/2Q14-Enterprise- Session-Border-Controllers-Market-Highlights.asp. Accessed: 2015-12-07.
[38] P. Matthews D. Wing J. Rosenberg, R. Mahy. RFC 5389: Session Traversal Utilities for NAT (STUN). 2008.
63 [39] J. Rosenberg R. Mahy, P. Matthews. RFC 5766: Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN). 2010.
[40] J. Rosenberg. RFC 5245: Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols. 2010.
[41] Answer-seizure ratio. http://www.markholloway.com/blog/?p=1709. Accessed: 2016-01-19.
[42] Call recording with SIPREC. https://andrewjprokop.wordpress.com/2014/02/ 26/call-recording-with-siprec/. Accessed: 2016-02-01. [43] C. Eckel A. Johnston A. Hutton L. Portman, H. Lum. Session Recording Protocol. 2015.
[44] Understanding SIP DTMF Options supported by CUCM. https://supportforums. cisco.com/blog/154706. Accessed: 2016-02-01. [45] M. Murray K. Claffy R. Prasad, C. Dovrolis. Bandwidth Estimation: Metrics, Mea- surement Techniques, and Tools. 2003.
[46] Echo suppression and cancellation. https://en.wikipedia.org/wiki/Echo_ suppression_and_cancellation. Accessed: 2016-02-01. [47] H.S. Jamadagni M.C Chiranth R. Sah R. Prasad, A. Sangwan and V. Gaurav. Com- parison of Voice Activity Detection Algorithms for VoIP. 2002.
[48] Comfort noise. https://en.wikipedia.org/wiki/Comfort_noise. Accessed: 2016- 02-01.
[49] Patrick Park. Voice over IP Security: Security best practices derived from deep analysis of the lastest VoIP network threats. Cisco Press, 2009.
[50] A. H. Kaplan, V. Pascual. RFC 7332: Loop Detection Mechanisms for Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs). 2014.
[51] Jana Dittmann Christian Kraetzer. Mel-Cepstrum Based Steganalysis for VoIP- Steganography. 2007.
[52] Private VLAN. https://en.wikipedia.org/wiki/Private_VLAN. Accessed: 2016- 02-01.
[53] PROTOS. https://www.ee.oulu.fi/research/ouspg/PROTOS_Test-Suite_c07- sip. Accessed: 2015-11-25.
[54] VoIPER. http://voiper.sourceforge.net/. Accessed: 2015-11-25.
[55] AFL. http://lcamtuf.coredump.cx/afl/. Accessed: 2015-11-25.
[56] Preeny. https://github.com/zardus/preeny. Accessed: 2015-11-25.
[57] inviteflood. http://tools.kali.org/sniffingspoofing/inviteflood. Accessed: 2016-01-20.
[58] Ekiga. http://ekiga.org/. Accessed: 2015-11-25.
64 [59] TLS Prober. https://github.com/WestpointLtd/tls_prober. Accessed: 2015- 11-25.
[60] SSLScan. https://github.com/rbsec/sslscan. Accessed: 2016-01-20.
[61] SIPVicious. https://github.com/sandrogauci/sipvicious. Accessed: 2016-01- 20.
[62] SIPcrack. http://manpages.ubuntu.com/manpages/natty/man1/sipcrack.1. html. Accessed: 2015-11-25.
[63] Kamailio repository. https://github.com/kamailio/kamailio. Accessed: 2015- 12-22.
[64] Asterisk repository. https://gerrit.asterisk.org/. Accessed: 2015-12-22.
[65] VRRP with Kamailio. http://blog.unicsolution.com/2015/01/kamailio-high- availability-with.html. Accessed: 2016-01-20.
[66] OpenSSL. https://www.openssl.org/. Accessed: 2015-12-22.
[67] OpenSSL Vulnerabilities. https://www.openssl.org/news/vulnerabilities. html. Accessed: 2015-12-23.
[68] Anonymous Diffie-Hellman weakness. https://wiki.openssl.org/index.php/ Diffie_Hellman. Accessed: 2016-01-20.
[69] Export keys weakness. https://en.wikipedia.org/wiki/FREAK. Accessed: 2016- 01-20.
[70] Six ways to break DES. http://lasec.epfl.ch/memo/memo_des.shtml. Accessed: 2016-01-20.
[71] Hacker Intelligence Initiative. Attacking SSL when using RC4. 2015.
[72] Z. Durumeric P. Gaudry M. Green J. Halderman N. Heninger D. Springall E. Thomé L. Valenta B. VanderSloot E. Wustrow S. Zanella-Béguelin P. Zimmermann D. Adrian, K. Bhargavan. Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice. 2015.
[73] Kamailio permissions module. http://kamailio.org/docs/modules/stable/ modules/permissions.html. Accessed: 2015-11-30.
[74] D. McGrew. RFC 5545: Internet Calendaring and Scheduling Core Object Specifi- cation (iCalendar). 2009.
[75] T. Wiens A. Wiens and M. Massoth. A new Unsupervised User Profiling Approach for Detecting Toll Fraud in VoIP Networks. 2014.
[76] T. Wiens A. Wiens and M. Massoth. Improvement of User Profiling, Call Destination Profiling and Behavior Pattern Recognition Approaches for Telephony Toll Fraud Detection. 2015.
65 A Loop amplification Attack
This attack has been described in details in RFC 5393 [2]. An attacker needs two accounts on two different registrars, for example a@R1, b@R1, a@R2, b@R2. Then he will send the four REGISTER messages below in Figure 23.
REGISTER sip:P1 SIP/2.0 To:
REGISTER sip:P1 SIP/2.0 To:
REGISTER sip:P2 SIP/2.0 To:
REGISTER sip:P2 SIP/2.0 To:
Figure 23: REGISTER messages of a loop amplification attack
Once the REGISTER messages have been accepted the attacker will just send an INVITE message to one of the user, for example a@P1. It will fork the request into two requests to a@P2 and b@P2 following the information given by the REGISTER messages. Then the call to a@P2 will be fork into two calls to a@P1 and b@P1 and the call to b@P2 into a@P1 and b@P1. Then the process will continue and each step will double the number of messages between the two proxies until the Max-Forwards field reaches 0. Up to 271 messages can be generated from the single INVITE. The flow is shown below in Figure 24. The attack is difficult to setup because the attacker needs two accounts on each server.
a@P1
a@P2 b@P2
a@P1 b@P1 b@P1 a@P1
a@P2 b@P2 b@P2 a@P2 a@P2 b@P2 b@P2 a@P2
Figure 24: Example of the flow of a SIP amplification attack from RFC 5393 [2]
66 B Kamailio configuration files kamailio.cfg
#!KAMAILIO
####### Defined Values #########
#!define ASTERISK 192.0.2.42 #!define WITH_TLS
####### Global Parameters #########
#!ifdef WITH_DEBUG debug=4 log_stderror=no #!else debug=2 log_stderror=no #!endif memdbg=5 memlog=5 log_facility=LOG_LOCAL0 fork=yes children=2 auto_aliases=no port=5060
####### Modules Section ######## mpath="/usr/local/lib/kamailio/modules" loadmodule "tm.so" loadmodule "db_text.so" loadmodule "mi_fifo.so" loadmodule "kex.so" loadmodule "sl.so" loadmodule "rr.so" loadmodule "pv.so" loadmodule "maxfwd.so" loadmodule "textops.so" loadmodule "sdpops" loadmodule "siputils.so" loadmodule "xlog.so" loadmodule "sanity.so" loadmodule "ctl.so" loadmodule "cfg_rpc.so" loadmodule "mi_rpc.so" loadmodule "path.so" loadmodule "rtpengine.so" loadmodule "topoh"
#!ifdef WITH_DEBUG loadmodule "debugger.so" #!endif
67 # ------setting module-specific parameters ------modparam("mi_fifo", "fifo_name", "kamailio_fifo")
# add value to ;lr param to cope with most of the UAs modparam("rr", "enable_full_lr", 1) # do not append from tag to the RR (no need for this script) modparam("rr", "append_fromtag", 0) modparam("path", "use_received", 1)
#Parameter for RTP Engine to do media gateway modparam("rtpengine", "rtpengine_sock", "udp:127.0.0.1:12221")
#Parameter for Topology hiding (to hide Asterisk) modparam("topoh", "mask_key", "hidenipbx") modparam("topoh", "mask_ip", "192.0.2.42")
#!ifdef WITH_TLS listen=udp:192.0.2.42:5060 listen=tls:192.0.2.42:5061 enable_tls=yes loadmodule "tls.so" modparam("tls", "config", "tls.cfg") #!endif
#!ifdef WITH_DEBUG # ----- debugger params ----- modparam("debugger", "cfgtrace", 1) #!endif
####### Routing Logic ######## route {
route(SBC_CHECK);
if (src_ip != ASTERISK) { # SIP request packet client->backend if ($op == 5061){ $du = "sips:192.0.2.43:5061"; } else { $du = "sip:192.0.2.43:5060"; } add_path_received(); route(RTPPROXY); } else { # SIP request packet backend->client if ($op == 5061){ $fu = "sips:192.0.2.42:5061"; } else { $fu = "sip:192.0.2.42:5060"; }
loose_route(); route(RTPPROXY);
68 } t_relay(); }
#Check we want to do as a SBC route[SBC_CHECK] {
#We check the fields if (!sanity_check()) { exit; }
#We can add whatever check we want on the messages
return; } route[RTPPROXY] { t_on_reply("1"); rtpengine_manage("replace-origin"); return; }
#On the reponse messages onreply_route[1] { rtpengine_manage("replace-origin"); return; } tls.cfg
[server:default] method = TLSv1 verify_certificate = yes require_certificate = yes private_key = tls/key_kamailio.pem certificate = tls/cert_kamailio.pem ca_list = tls/CA.pem #The cipher list can be chosen depending on security policy cipher_list = kRSA
[client:default] method = TLSv1 verify_certificate = yes require_certificate = yes private_key = tls/key_kamailio.pem certificate = tls/cert_kamailio.pem ca_list = tls/CA.pem #The cipher list can be chosen depending on security policy cipher_list = kRSA
69 C Asterisk configuration files sip.conf
[general] outboundproxy = 192.0.2.42:5060 defaultexpirey=1800 dtmfmode=auto qualify=yes alwaysauthreject=yes tlsenable=yes tlsbindaddr=0.0.0.0 tlscertfile=keys/asterisk.pem tlscafile=keys/ca.pem tlscipher=ALL tlsclientmethod=tlsv1 extensions.conf
[general] static=yes writeprotect=no clearglobalvars=no
[Developper1] exten => _X.,1,Dial(SIP/${EXTEN}, 10) exten => _X.,20,Hangup()
[Developper2] exten => _X.,1,Dial(SIP/${EXTEN}, 10) exten => _X.,20,Hangup() users.conf
[general] hasvoicemail = yes hassip = yes hasiax = yes callwaiting = yes threewaycalling = yes callwaitingcallerid = yes transfer = yes canpark = yes cancallforward = yes callreturn = yes callgroup = 1 pickupgroup = 1
[Developper1] type=friend host=dynamic dtmfmode=rfc2833 disallow=all allow=all language=fr context = Developper1
70 [Developper2] type=friend host=dynamic dtmfmode=rfc2833 disallow=all allow=all language=fr context = Developper2 transport=tls
[1100](Developper1) username=1100 fullname = 1100 secret=123456
[1101](Developper1) username=1101 fullname = 1101 secret=123456
[1200](Developper2) username=1200 fullname = 1200 secret=123456
[1201](Developper2) username=1201 fullname = 1201 secret=123456
71 TRITA TRITA-EE 2016:024
www.kth.se