CHAPTER 18
VoIP Attacks
The growing popularity of IP telephony services is stimulating real concern over VoIP security. With potential security threats including attacks that disrupt service and attacks that steal confidential information, we must pinpoint and resolve any vulnerabilities in the VoIP network prior to the occurrence of a network breach, and prepare the network to deter any such attacks. In a time of global uncertainty, VoIP security exploits such as those related to denial of service can have a detrimental result of significant outages that affect our entire global infrastructure. Additional exploits related to service theft can cost in the billions of dollars to recover from and recoup service. With such emphasis today on the way we communicate in our daily lives, it is absolutely critical that we put preventative measures into place to prevent these hazards from occurring. These measures include drilling down into the depths of our technology in order to seek and resolve even the smallest fault. This is the moment and prized opportunity for the gray hat hacker to utilize his or her knowledge and expertise to drive a well-thought-out security initiative using techniques that we will discuss in this chapter, such as enumeration, password cracking, eavesdropping, fuzzing, and so forth.
In this chapter, we cover the following topics:
• What is VoIP?
• Protocols used by VoIP
• Types of VoIP attacks
• How to protect against VoIP attacks
What Is VoIP?
VoIP, or Voice over Internet Protocol, is a type of transmissions medium that is responsible for the delivery of real-time voice and data communication. Unlike its analog predecessor in which the transport functionality was routed via the public switched telephone network (PSTN), calls are now converted from an analog signal to a digital format, which is what the Internet Protocol (IP) uses for transmission and delivery, making VoIP possible. Several other key processes, such as signaling, authentication, security, call control, and voice compression, are established by VoIP prior to and during the call setup phase.
The evolution of VoIP is certainly an amazing one, starting back in 1995 when a company called VocalTec Communications released what is believed to be the world’s first Internet software phone product, called Internet Phone. This software was designed to run on home computers very much like the softphone PC clients of today. Telephone calls were made in a peer-to-peer fashion (PC to PC) and utilized earlier adopted VoIP protocols such as H.323. Although VocalTec had a great deal of success as a pioneer in this new area of telecommunications, the technology had several drawbacks. A major drawback was the lack of broadband availability. At that time, the use of lower-speed modems was highly prevalent, and the infrastructure was not in place to support the much needed bandwidth and higher transmission rate requirements. Quality of service was also a huge deterrent. The advancements made in modern codec and audio compression technologies just were not there in the past. The combination of using voice communication in conjunction with the slower modem technology resulted in serious voice quality concerns.
With the emergence of broadband along with the continued innovation in VoIP development, protocol standardization and formality started to arise. Superior advancements in routing and switching with emphasis on QoS control and packet priority aided in building the next-generation VoIP platform of today. Notably, despite the expansive growth of VoIP, security considerations were very limited. With this increased momentum, VoIP as a mainstream offering became the premiere product choice of telcos such as Sprint, Verizon, AT&T, Comcast, and so forth, which viewed it as a highly lucrative and low-cost mechanism for residential and business customers. This in itself created a new type of competition and marketing mix, with various flavors of service offerings and price point differentiators to meet the needs of many potential clients.
The migration from legacy (analog) type service to VoIP (packet switched) type service has continued growing at a substantial rate. As seen today, the overall subscription cost for VoIP is considerably lower than the subscription cost for its legacy companion. With VoIP, fees are geared toward being flat and fee-based, including both local and long distance, while legacy lines still prove to be quite costly. More importantly, the improvement in voice intelligibility and call quality definitely has made it a worthwhile candidate. Thus, the answer to the question “What is VoIP?” could reasonably be that it is the marriage of many complex protocols for use in the exchange of real-time communication for both voice and data communication.
Protocols Used by VoIP
A number of protocols are utilized in VoIP communications. As we explore further, you will find that certain protocols have rather comprehensive methods and functions. This potentially increases the probability for exploitation due to the number of error paths and use-case scenarios that can be generated. The most common protocols used by VoIP are:
• Session Initiation Protocol (SIP)
• Media Gateway Control Protocol (MGCP, Megaco, or H.248)
• H.323
• Transport Layer Security (TLS)
• Datagram TLS (DTLS)
• Secure Real-time Transport Protocol (SRTP)
• Zimmermann Real-time Transport Protocol (ZRTP)
SIP
SIP is documented in RFC 3261 and is recognized globally as a worldwide standard. SIP is an application layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. Due to its simplicity as a text-based protocol, the probability of attackers discovering flaws in it is greater. It is also important to note that SIP on its own offers very little security, making it a target of choice for attackers.
• Proxy server An intermediary entity that acts as both a server and a client for the purpose of making requests on behalf of other clients.
• Registrar server A SIP server that can authenticate and register user agents.
• Redirect server A user agent server that generates SIP 3xx responses to requests it receives, directing the client to contact an alternative set of URIs.
• User agent (UA) Can be a soft client or a hard phone that supports the SIP protocol. The user agent can originate or terminate calls.
The SIP protocol defines several methods:
• SIP method invite Invite another UA to a session
• SIP method invite re-invite Change a running session
• SIP method register Register a location with a SIP registrar server
• SIP method ack Facilitate reliable message exchange for INVITEs
• SIP method cancel Cancel an invite
• SIP method bye Hang up a session
• SIP method options Features supported by the other side
The SIP protocol defines several responses:
• 1xx Informational 100 Trying, 180 Ringing
• 2xx Successful 200 OK, 202 Accepted
• 3xx Redirection 302 Moved Temporarily
• 4xx Request Failure 404 Not Found, 482 Loop Detected
• 5xx Server Failure 501 Not Implemented
• 6xx Global Failure 603 Decline
The following are SIP method extensions as defined in other RFCs:
• SIP method info Extension in RFC 2976
• SIP method notify Extension in RFC 2848 PINT
• SIP method subscribe Extension in RFC 2848 PINT
• SIP method unsubscribe Extension in RFC 2848 PINT
• SIP method update Extension in RFC 3311
• SIP method message Extension in RFC 3428
• SIP method refer Extension in RFC 3515
• SIP method prack Extension in RFC 3262
• SIP specific event notification Extension in RFC 3265
• SIP message waiting indication Extension in RFC 3842
• SIP method publish Extension is RFC 3903
Megaco H.248
Megaco H.248 (Media Gateway Control Protocol) is documented in RFC 3525 and is recognized as a standard. Megaco H.248 defines the protocol for media gateway controllers to control media gateways for the support of multimedia streams across networks. This protocol is text based, making it easy to modify and analyze from an attacker’s point of view.
H.323
H.323 is a widely implemented recommendation published by the International Telecommunication Union Telecommunication Standardization Sector (ITU-T). This recommendation provides a foundation for multimedia communications (audio, video, and data) over packet-based networks (PBNs). The PBN over which H.323 entities communicate may be a point-to-point connection, a single network segment, or an internetwork that has multiple segments with complex topologies.
H.323 is composed of the following protocols:
• Digital Video Broadcasting (DVB) Defines a set of open standards for digital television
• H.225 Covers narrow-band visual telephone services
• H.225 Annex G Describes methods to allow address resolution, access authorization, and usage reporting H.323 systems
• H.225E Describes a packetization format and a set of procedures that can be used to implement UDP- and TCP-based protocols.
• H.235 Covers security and authentication
• H.323SET Describes the standards for simple endpoint types in H323
• H.245 Negotiates channel usage and capabilities
• H.450.1 Defines supplementary services for H.323
• H.450.2 Covers Call Transfer supplementary services for H.323
• H.450.3 Covers Call Diversion supplementary services for H.323
• H.450.4 Covers Call Hold supplementary service
• H.450.5 Covers Call Park supplementary service
• H.450.6 Covers Call Waiting supplementary service
• H.450.7 Covers Message Waiting Indication supplementary service
• H.450.8 Covers Calling Party Name Presentation supplementary service
• H.450.9 Covers Completion of Calls to Busy Subscribers supplementary service
• H.450.10 Covers Call Offer supplementary service
• H.450.11 Covers Call Intrusion supplementary service
• H.450.12 Covers ANF-CMN supplementary service
• H.261 Describes a video stream for transport using the Real-time Transport Protocol
• H.263 Defines a video coding standard in which support numerous bit rates
• Q.931 Manages call setup and termination
• Registration, Admission, and Status (RAS) Manages registration, admission, and status messages used in the gatekeeper discovery and endpoint registration processes.
• Real-time Transport Protocol (RTP) Provides end-to-end network transport functions
• RTP Control Protocol (RTCP) Provides control and statistical information to all participants in the session
• T.38 Defines IP-based fax transmission
• T.125 Multipoint Communication Service Protocol (MCS)
TLS and DTLS
Transport Layer Security (TLS) is documented in RFC 5426. TLS is normally used to secure communications between web browsers and web servers, but it can also be used to secure VoIP. TLS can provide confidentiality and integrity protection, but attacks that affect availability can still be performed.
Datagram Transport Layer Security (DTLS) is documented in RFC 4347 and RFC 5238. DTLS is based on TLS and is designed to prevent eavesdropping, tampering, and message manipulation/forgery. It can be used with a centrally managed public key infrastructure (PKI).
SRTP
The Secure Real-time Transport Protocol (SRTP) is documented in RFC 3711. SRTP is the protocol used to encrypt the low-level voice packets. Beyond encryption, SRTP is intended to provide message authentication, integrity checking, and replay protection.
ZRTP
Zimmermann Real-time Transport Protocol (ZRTP) is documented in IETF Internet Draft avt-zrtp. ZRTP is a VoIP encryption key–agreement protocol that two communication endpoints use to negotiate the SRTP session key.
Types of VoIP Attacks
VoIP architectures and services are prone to several types of attacks. These can be categorized into vulnerabilities or exploits that violate any of the CIA (confidentiality, integrity, and availability) tenants, as shown in Figure 18-1 and detailed here:
• Confidentiality Attacks include eavesdropping, packet sniffing, password cracking, social engineering, information leakage
• Integrity Attacks include message, log, and configuration tampering, and bit flipping
• Availability Attacks and vulnerabilities include denial of service (DoS), distributed DoS, physical tampering, corruption of data, manmade and natural disasters, and fuzzing
An additional category of violations could be attacks to circumvent authenticity. These attacks would include spoofing and man-in-the-middle replay attacks.
Since SIP is the most prevalent VoIP protocol that is deployed globally, let’s focus our sights on understanding some of the more popular SIP attacks:
• Enumeration
• SIP password cracking
• Eavesdropping/packet capture
• Denial of service
Enumeration
Enumeration is the process of gathering information about a target system or network entity for reconnaissance and potential exploitation. Tools such as SIPVicious, Smap, Nmap, and so forth are capable of retrieving valuable information from a SIP server. This information in turn may identify what application, service, or operating system is actively running. For example, if we were to run the svmap.py executable, one of several tools in the SIPVicious suite, on a SIP-enabled device as shown next, we should be able to obtain the device’s fingerprint information to establish its identity and version number.
Figure 18-1 Information Security Components (CIA tenants)
Python svmap.py 192.168.0.199
| SIP Device | User Agent | Fingerprint |
| 192.168.0.199:5060 | 3CXPhoneSystem 8.0.10708.0 | 3CXPhoneSystem |
This information can be quite useful to the attacker because it gives them the name and build number of the user agent. There could be exploits written against this system to attack known vulnerabilities that have not been patched or resolved.
Nmap is another very useful enumeration utility. By performing a simple UDP scan on port 5060 of the user agent, we see that this port is open and that the SIP service is active:
Nmap –sU 192.168.0.199 –p 5060
Starting Nmap 5.20 ( http://nmap.org ) at 2010-03-02 22:33 EST
Nmap scan report for 192.168.0.199
Host is up (0.077s latency).
PORT STATE SERVICE
5060/udp open|filtered sip
MAC Address: 00:22:FA:C1:CF:88 (Intel Corporate)
Additional enumeration can be performed by analyzing/sniffing the network using an ARP poisoning tool like Dsniff. This in turn would allow us to capture all of the SIP URIs on that particular LAN segment.
SIP Password Cracking
There are quite a few tools that can perform SIP password cracking, such as Cain & Abel, SIP.Tastic, Vnak, and the SIPVicious tool suit. As shown next, the svcrack.py utility, part of the SIPVicious toolset, is able to run a brute-force attack on the SIP PBX extension 100 to locate its password:
python svcrack.py -u100 -r1-999 -z2 192.168.0.199
| Extension | Password |
------------------------
| 100 | 777 |
Other SIP password-cracking tools such as Cain & Abel are able to perform a man-in-the-middle attack and sniff the SIP authentication process between a SIP user agent and a SIP server. Still other types of SIP password-cracking tools are powerful enough to perform both active and offline dictionary attacks.
Eavesdropping/Packet Capture
Unless some type of encryption mechanism is used, such as TLS-DTLS, SRTP, or ZRTP, the call signaling or voice (bearer) path will be vulnerable to eavesdropping and/or interception. In basic and smaller deployment scenarios, usually security is an after-thought. In large VoIP deployments, security mechanisms may be limited to TLS, which only secures the signaling path, leaving the voice path subject to eavesdropping. In fact, the open source tool Wireshark can easily capture and analyze unencrypted RTP packets for immediate playback.
NOTE
Although SRTP and ZRTP offer efficient encryption support for voice, these protocols still have limited deployment and implementation.
Denial of Service
Denial of service (DoS) can be defined as an incident in which a user or organization is deprived of necessary services or resources that are needed for the user or organization to be fully functional. Utilizing some of the behaviors of SIP, there are several methods that can deteriorate and hinder normal operation. This section discusses three tools that can be used in SIP DoS attacks.
inviteflood
One type of attack that can consume resources and cause outages is the SIP invite flood. The inviteflood tool is one tool that can be used to execute a SIP invite flood. This tool works in transmit mode only and can be quite effective at promoting a DoS attack. The tool generates semivalid invite messages that are transmitted at a phenomenal speed and rate. During the execution of this tool against several commercial SIP server and SIP softclient types with active calls, very few were able to throttle or block the incoming SIP flood, which resulted in continuous dropped calls and SIP exceptions.
Basic inviteflood Command Line Example:
./inviteflood eth0 "217+4262" sip.inphonex.com 192.168.0.199 30000 –v
Asteroid
Another interesting tool used in SIP DoS attacks is called Asteroid. This is a DoS testing tool that contains 36KB of malformed/fuzzed SIP test packets that fall into the following SIP message categories:
./ASTEROID/invites
./ASTEROID/cancels
./ASTEROID/byes
./ASTEROID/refers
./ASTEROID/option
./ASTEROID/registers
./ASTEROID/subscribes
./ASTEROID/notifies
To utilize Asteriod, you first have to install the Netcat utility. After you install Netcat, extract the Asteroid content and cd into one of the Asteroid test packet directories such as /ASTEROID/invites. For easier test case handling and automated execution, the following script was created to rename the test case folder contents using the .pdu extension name:
//Script used to rename the test cases with the .pdu extension
# /bin/csh
foreach file (*)
set base='basename $file.pdu'
echo " base:$file.pdu"
mv $file $file.pdu
end
Once the test case packets are renamed by running the preceding script, you can then use the following command line to promote automated test case execution of the SIP test packets to the system under test. Transmission of the packets can be verified using Wireshark or tcpdump.
//Script used to automate the test case execution in each folder
for x in *.pdu; do cat $x|perl *$x 192.168.0.199; sleep 3;
echo sending test case $x; done
NOTE
It is extremely important to monitor the system under test (SUT) very closely for memory impairment, exception handling and reporting, and general behavior while performing test case execution. It is also highly recommended that the SUT engage active calls in order to determine impact to overall call integrity and call quality.
VoIPER
In our opinion, VoIPER is one of the most comprehensive open source VoIP test tools because it is based on the concept of fuzzing, a technique that is used to inject irregular message content and data inputs in an effort to test the robustness of a system. To prove the exceptional capabilities of VoIP fuzzing attacks, we chose to use the VoIPER tool (authored by “nnp”) because of its software portability, relative ease of use, and novel use of automation. VoIPER is a security tool that contains several SIP fuzzing modules based on known SIP methods that are supported today.
Before you get started with the VoIPER Exploit Research Toolkit, you need Python 2.4.4, wxPython runtime 2,4, and the ctypes module. You also need the QuteCom SIP softphone client to evaluate the interactive responses to the VoIPER Exploit Research Toolkit. Additionally, our test bed will utilize two Windows machines. We’ll use Windows PC 1 for process management and debugging, and we’ll use Windows PC 2 to transmit malformed/fuzzed SIP messages.
VoIPER Installation and Execution Steps Following are the steps to install and execute VoIPER:
1. Install Python 2.4.4 on both Windows machines using the default installation parameters.
2. Install wxPython runtime 2.4 (win32-ansi) on both Windows machines, and choose the default installation parameters.
3. Install ctypes ctypes-1.0.2.win32-py2.4.exe on both Windows machines, and choose the default installation parameters.
4. Install the VoIPER Exploit Research Toolkit on both Windows machines. The version that you want to download is VoIPER v0.06. You will need to gunzip and untar the VoIPER content to the C:VoIPER-0.06 directory.
5. You need a SIP client to test. For this example, choose the open source SIP client QuteCom, which is the new name for the open source softphone previously known as WengoPhone.
NOTE
This test setup will actually re-create two bugs that were reported to the QuteCom Development team by the author of this chapter under Trac ticket/defect #188, “Malformed/fuzzed sip invite msgs will crash client.” The QuteCom software build that this ticket was written against is QuteCom-2.2-RC3-setup-release.exe.
6. Install the QuteCom softclient on PC 1.
7. Sign up for a free SIP account. For purposes of this example, use SIP service from InPhonex. The QuteCom softclient requires registration information that you obtain by registering with InPhonex. Once you enter the registration information into the QuteCom client, click Connect, and the QuteCom client should register and become active.
8. We should now be ready to start our testing. The VoIPER tool has three test modes available. For our example, we will be using Level 3, which is the preferred test mode because it focuses on VoIPER’s unique automation and process monitoring capabilities.
9. On PC 1 (the same PC that is running the QuteCom softclient), attach the VoIPER debug process to the QuteCom softclient. To do this, you need to launch the Windows command line.
10. Use the cd command to go to the VoIPER directory that you created on the C: drive.
11. Enter the following command-line syntax to monitor the QuteCom process (the name of which can be found within Windows Task Manager):
C:VoIPER-0.06>python sulleywin_process_monitor.py -c
sessionsQuteComtest1.crashbin -p QuteCom.exe -l 3
[07:50.06] Process Monitor PED-RPC server initialized:
[07:50.06] crash file: sessionsQuteComtest1.crashbin
[07:50.06] # records: 0
[07:50.06] proc name: QuteCom.exe
[07:50.06] log level: 3
[07:50.06] awaiting requests...
In the preceding syntax, QuteComtest1.crashbin is the name of the file in which you want to record information about the crash, and QuteCom.exe is the name of the process in memory to monitor.
12. Move to PC 2 to launch the VoIPER fuzzer. From a Windows command prompt on PC 2, cd to the VoIPER directory and launch the VoIPER GUI by typing
python win_fuzzer_gui.py.
13. Once the VoIPER GUI is launched, set the following parameters (see Figure 18-2):
Target Selection
• Target host The IP address of PC 1.
• Target port The default SIP port number is set to 5060.
Crash Detection/Target Management
• Level Set the level to 3 for this test to provide an automated approach of fuzzing the SIP messages and capturing the debug data if any crashes are caught. (This is the preferred method to test.)
• PedRPC port The default port number is 26002. The PedRPC port is the port the remote process monitor script is listening to.
• Restart Interval The interval at which the fuzzer will instruct the process monitor script to restart the target process. For our test, we will use a value of 0.
• Start Cmd The path to the QuteCom executable, which is C:Program FilesQuteComQuteCom.exe.
• Stop Cmd The default TERMINATE_PID is being used.
Fuzzer Configuration
• Fuzzer For our test, we will use SIPInviteCommonFuzz, but other fuzzing modules are available.
• Session Name We will call our session QuteComtest1, but you can use whatever name you prefer.
Optional: Leave the optional parameters at their default values.
14. Click Start in the Control Panel area on the GUI and watch the magic begin.
Once the test has started, you will see within the Windows command line on PC 1 that the win_process_monitor script updates, and confirms connection to the QuteCom process:
C:VoIPER-0.06>python sulleywin_process_monitor.py -c sessions
QuteComtest.crashbin -p QuteCom.exe -l 3
[07:50.06] Process Monitor PED-RPC server initialized:
[07:50.06] crash file: sessionsQuteComtest1.crashbin
[07:50.06] # records: 0
[07:50.06] proc name: QuteCom.exe
[07:50.06] log level: 3
[07:50.06] awaiting requests...
[10:41.41] updating start commands to:
['C:\Program Files\QuteCom\QuteCom.exe
[10:41.42] updating stop commands to: ['TERMINATE_PID']
[10:41.42] debugger thread-1266853302 looking for process name:
QuteCom.exe
[10:41.42] debugger thread-1266853302 found match on pid 3260
You will also see that on PC 2 within the VoIPER toolkit GUI, test cases have started to execute.
15. As we continue our testing, it appears that we have found a bug/crash, as shown in Figure 18-3.
Figure 18-2 VoIPER test case execution
Figure 18-3 VoIPER bug/crash identification
16. It appears that test case #46 has caused our crash. Pause the VoIPER toolkit on PC 2 for a moment to investigate the crash further.
17. From another Windows command prompt, cd into the VoIPER directory on PC 1, which is the target machine, and run the following command:
C:VoIPER-0.06>python sulley/s_utils/crashbin_explorer.py
sessions/QuteComtest1.crashbin
[1] phapi.dll:10013917 mov eax,[edx+0x4] from thread 1284 caused
access violation 46,
18. The preceding output gives us the same error that is reported within the VoIPER GUI. We will now explore the exception a bit deeper. From within the same command prompt, run the following command:
C:VoIPER-0.06>
python sulley/s_utils/crashbin_explorer.pysessions/QC.crashbin -t 46
phapi.dll:10013917 mov eax,[edx+0x4]from thread 1284
caused access violation when attempting to read from 0x00000004
CONTEXT DUMP
EIP: 10013917 mov eax,[edx+0x4]
EAX: 00000000 ( 0) -> N/A
EBX: 01e384d8 ( 31687896) -> 2)Xxx-C (heap)
ECX: 0000000f ( 15) -> N/A
EDX: 00000000 ( 0) -> N/A
EDI: 02e05960 ( 48257376) -> pZ (heap)
ESI: 02fda068 ( 50176104) -> 8Y (heap)
EBP: 00000000 ( 0) -> N/A
ESP: 03f2fe80 ( 66256512) -> PD (stack)
+00: 02e04450 ( 48251984) -> INVITE sip:[email protected]
SIP/2.0 (heap)
+04: 02e05948 ( 48257352) -> `YumenpZh(YZ (heap)
+08: 1002613f ( 268591423) -> N/A
+0c: 02e05960 ( 48257376) -> pZ (heap)
+10: 010ffd38 ( 17825080) -> ]amu8 (heap)
+14: 00272420 ( 2565152) -> N/A
disasm around:
0x100138fb jz 0x10013911
0x100138fd mov eax,[esi+0xc]
0x10013900 mov ecx,[esi+0x4]
0x10013903 push eax
0x10013904 push ecx
0x10013905 call 0x100137c0
0x1001390a add esp,0x8
0x1001390d test eax,eax
0x1001390f jnz 0x1001396a
0x10013911 mov edx,[edi+0xac]
0x10013917 mov eax,[edx+0x4]
0x1001391a mov edi,[eax+0xc]
0x1001391d mov eax,[esi+0xc]
0x10013920 mov ecx,edi
0x10013922 mov dl,[eax]
0x10013924 cmp dl,[ecx]
0x10013926 jnz 0x10013942
0x10013928 test dl,dl
0x1001392a jz 0x1001393e
0x1001392c mov dl,[eax+0x1]
0x1001392f cmp dl,[ecx+0x1]
SEH unwind:
03f2ffdc -> MSVCR80.dll:78138ced
ffffffff -> kernel32.dll:7c839ad8
The preceding command provides information about the process’s state when it crashed, such as registers, stack unwinds, and so on. This type of data is invaluable in providing bug resolution.
19. Now that we have found our first bug, you can return to testing by going back to the VoIPER GUI on PC 2 and clicking Restart within the Control Panel. You should also notice since the first crash that the QuteCom softclient and its process were automatically restarted.
All in all, VoIPER is a phenomenal open source tool. The combination of its automation capabilities and sheer number of test case scenarios provides a self-contained framework for exhaustive SIP analysis and bug discovery.
NOTE
Crashes occurred while testing the QuteCom SIP client and the issues were readily addressed with patches as soon as they were reported.
References
ASTEROID www.packetstormsecurity.org/DoS/asteroidv1.tar.gz
Cain & Abel www.oxid.it/cain.html
ctypes-1.0.2.win32-py2.4 www.sourceforge.net/projects/ctypes/files/
dsniff www.monkey.org/~dugsong/dsniff
InPhonex www.inphonex.com/reg/free-voip-calls.php
inviteflood www.hackingexposedvoip.com/tools/inviteflood.tar.gz
Netcat www.netcat.sourceforge.net/
Nmap www.nmap.org/
Python 2.4.4 www.python.org/download/releases/2.4.4/
QuteCom Bug Report http://trac.qutecom.org/ticket/188
QuteCom SIP softclient www.qutecom.org/
SIP.Tastic www.isecpartners.com/sip_tastic.html
SIPVicious www.code.google.com/p/sipvicious/
vnak www.isecpartners.com/vnak.html/
VoIPER 0.06 www.VoIPER.sourceforge.net/
Wireshark www.wireshark.org/
WxPython runtime 2.4 (win32-ansi) www.wxpython.org/download.php
How to Protect Against VoIP Attacks
To protect against VoIP attacks, you should follow the same conventional methods and security best practices that you use for any other software segment. Test your system thoroughly via penetration testing and implement a strategy of defense in depth that encompasses the entire system. Defense in depth is achieved by
• Making it harder for intruders to penetrate all defenses to compromise the security of the network
• Greatly reducing the likelihood of a security breach
• Accelerating the deployment of modular security architectures that can be implemented in phases
• Minimizing downtime in the event of a security breach or network failure
Additional strategies that should be leveraged include
• Segmenting signaling and bearer paths into different VLANs
• Segmenting VoIP user agents such as VoIP hard phones from PC infrastructure
• Incorporating scheduled upgrades (including patch maintenance)
• Utilizing protective protocols such as IPsec, PKI, TLS-DTLS, SRTP, and ZRTP if possible
• Implementing a Security Information and Event Management (SIEM) system for log aggregation, maintenance, and audit analysis
• Implementing a scalable edge network strategy for all applicable firewalls, switches, routers, and IDS devices
• Confirming and ensuring policies are in place for two- and three-factor authentication
• Ensuring scheduled internal security assessments are routinely performed
• Using vendors that have gone through certification processes
These security measures, along with proper planning, should deter and greatly reduce the risk of any type of breach. Welcome to the brave new world of VoIP.