[VOIPSEC] How to test VoIP security

Tue Nov 15 07:52:37 CST 2005

>> Oh Boy, I was just waiting for someone to breach this topic again.  

-----Original Message-----
From: steven rivera <steven.rivera at mci.com>
Sent: Nov 15, 2005 7:40 AM
To: 'Floris Jan Schepel' <fjschepel at hmc-heerema.com>, voipsec at voipsa.org
Subject: Re: [VOIPSEC] How to test VoIP security

Floris

VOIP Security is the delicate balance between accessibility and security.
Below is a list (no particle order) of what I have done for such VoIP
security audits is the following. I hope you find this useful.

- View the VOIP system with associated telephones as a host on your network.
Doing this allows you to treat the VoIP phone like you would any other end
device on your network and thus test for the vulnerabilities the same way
using similar tools

>> Except in the case where the VoIP phone offers a secondary ethernet jack, especially if one has a networked device with a sniffer loaded on it.  Some telecommunication equipment manufacturers state the secondary jack is a convenience factor, so that office workers do not have to request a secondary ethernet drop or purchase a hub if they only have one ethernet jack available.  Some don't even provide a way to disable the port, so therefore the VoIP phone with an additional ethernet jack no becomes a passthrough device for any security auditor who needs an ethernet jack to plug into (CreepyCibir, you may want to take notes for your next preso)

- You would be surprised as to the ease and simplicity of older
vulnerabilities like "smurf" attacks that are affecting VOIP Phones

>> Smurf attacks, Disabling or causing DDOS attacks to shutdown a VOIP Phone is not really a valid test, but obtaining network access and being able to sniff voice conversations is much more interesting validation of whether the VoIP solution is setup properly or validation of the security of the VoIP Solution one has purchased through the various telecommunications equipment manufacturer.  Wrapping security around opensource protocols and proprietary codecs are not that difficult to figure out how to point out security vulnerabilities.  

- pen-tests end devices - bring the end device into a lab environment
>> Pen Test end devices, good idea, but you may want to simulate some network conditions in your lab environment: Ability to utilize sample network traffic in order to provide accurate security information for 'real world' deployments versus 'yep, we tested in the lab and couldn't find anything'

- VoIP Network architecture - the question is: converge or not to converge
voice and data? - the more disparate they are the better for security,
although separate means more expensive and an additional layer of
complexity.

>> Some telecommunication equipment providers recommend that voice and data should be placed on separate VLANS, others do not, separate does not necessary mean more expensive or an additional layer of complexity, unless the VoIP Network architecture proposed is convuluted to begin with or you have a 'rockstar' like security consultant providing the organization very expensive consulting advice.  Note: Don't hire 'rockstar' like security consultants who do not have hands-on pbx/telecom/voip experience, otherwise you are sorting through a complex layer of security consultant speak.

- The connectivity across the two networks can be a point of weakness and
often little thought is put into the architecture of it
>> This point does not apply since point of weaknesses could be identified in supporting VoIP equipment or the architecture itself.

- review the protocols, gateways and proxies closely

>> Good idea, why not review the telecommunications policy as well, a poor call routing policy could be harder to find than restricting tftp access by ip.

- Ensure that firewalls that are VOIP aware are being used and are
configured properly - SIP operates from outside connection initiation this
can open up a gaping hole to the network

>> Some VoIP aware firewalls are protocol aware but not codecs aware, Each codec supported if supported, utilize various packet sizes that are different from HTTP, FTP, SMTP, IMAP, HTTPS. G.729ab can cause more headaches than G.711alaw or G.726. 

- Other concerns that should be considered are eavesdropping / tapping and
sniffing of the voice traffic

>> More of a crowd pleaser than anything else, great to point out to CEO/CSO types, especially those who used to conduct bug sweeps at their previous job, but did you ever consider attendant features or supervisor role restrictions.

- There are simple protocol analyzers like the "Vomit" tool that can be used
to sniff out voice traffic from network traffic. It's a freeware tool
readily available from the internet
- evaluate the integration with voicemail this is often a weak point that
the requirement of ease of use outweighs security concerns.

>> Again, more of a crowd pleaser.  I know a fellow who does the Vomit tool on his preso, "This is not an encrypted conversation" versus "Encrypted conversation", white noise plays, Still doesn't provide enough of how is the rest of my VoIP Infrastructure, is it built to scale, will I have to purchase another 48 port PoE switch because in reality the power provided in the 48 port PoE switch is only capable of supporting 32 PoE ports.  What about other factors as well ??

>>Hopefully my comments help, especially to those recently demoted CSO's out there doing the same old 'scary' talk..

>>Enjoy

I hope this helps. I think that when a company chooses to bring the voice
traffic onto a data network it should be protected the same way, with the
same security countermeasures as the data. Often what I am seeing is that
most who do not view VoIP in that way may be opening themselves up for huge
security breeches. 

Sincerely,

Steven Rivera
Information Security Specialist
Southern New England Commercial Accounts
MCI - Rye Brook, NY
914-312-2197 Office
325-2197 VNET
914-960-9117 Cell

View our Managed Security Services Video:
http://global.mci.com/external/us/cyber_security.rm

-----Original Message-----
From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
Behalf Of Floris Jan Schepel
Sent: Tuesday, November 15, 2005 5:47 AM
To: voipsec at voipsa.org
Subject: [VOIPSEC] How to test VoIP security

Dear experts,

I am a IT student at TI Mon3aan, in the Netherlands, whit a work placement
at Heerema.
My study here is to find out, how to secure VoIP.
Heerema will work whit a Cisco Avaya solution. A Cisco network, whit
Catalyst 4506, 3560, and 2950 switches.
The VoIP environment will be Avaya, like the 8700 media servers, G650 Media
gateways direct to ISDN, and Avaya IPphones.(H.323)

On a lot of sites, there are explanations how to secure a VoIP environment,
but none of this sites, tell me how to test a VoIP environment. I am looking
for a tool or a appliance, with I can test and log the security of this VoIP
network. I like to use this tool or appliance on a test network.

I'ts not the purpose to knock (DoS) or Hack the VoIP network down. I have
Google'd a lot and, checked the email list, but I have failed to find
something usefull. I also have read a lot of VoIP books, like: "Switching to
VoIP", and Carrier grade Voice over IP" but none of them gives me
information of what I am looking for.

I hope, that you can help me, testing this VoIP environment without harming
it.

Thanks for you help,
Floris

_______________________________________________
Voipsec mailing list
Voipsec at voipsa.org
http://voipsa.org/mailman/listinfo/voipsec_voipsa.org

______________________________________________________________________
This e-mail has been scanned by MCI Managed Email Content Service, using
Skeptic technology powered by MessageLabs. For more information on MCI's
Managed Email Content Service, visit http://www.mci.com.
______________________________________________________________________

______________________________________________________________________
This e-mail has been scanned by MCI Managed Email Content Service, using Skeptic™ technology powered by MessageLabs. For more information on MCI's Managed Email Content Service, visit http://www.mci.com.
______________________________________________________________________