[VOIPSEC] Who the heck needs security anyway...

[Jason Ostrom]

The original article was very interesting and I'm glad it was sent out 
on this list - thanks J. Oquendo.  I agree with it as well - to me it is 
saying that users have been de-sensitized to security alerts and 
burdensome security rules, and when the rules are too constrained, they 
will find ways to get around them, because that is more practical and 
productive for them.  If there was an incentive to follow these security 
rules, now that would be a different matter.  This is one of the oldest 
thoughts in the InfoSec industry:  that in order to be successful a 
security system must have a balance of utility (the tradeoff betwen 
complexity and assurance)[1].  I liked this apt quote from the article, 
"Security professionals need to consider that user education costs 
everyone (in time), but benefits only the small percentage who are 
actually victimized, he wrote.  Advice must be based on an estimate of 
the victimization rate for a particular security issue, not a worst-case 
scenario risk analysis."

The discussion digressed a little on the subject of "security testing", 
so I'll chime in on something I love :)

In my opinion, "security testing" is not a synonym for "fuzzing."  
Fuzzing is no doubt very important.  I thank you, Ari, for your 
contribution to the security community with PROTOS.  But when we do 
security testing in the sense of "penetration testing", fuzzing is one 
of many test cases that should be included in a rigorous and 
comprehensive security assessment methodology.  Furthermore, security 
test cases depend entirely on the VoIP business environment.  "Security" 
is different for everyone.  For some people, security is being allowed 
to have the dancing pigs and flying bears on their screen.  To others 
like the "VoIP Engineers", it is being able do QA, SDLC, and find 
software bugs, to help improve the reliability of their VoIP solution.  
No one security requirement is better than the other - it all depends on 
the business environment for how you are using VoIP, where your users 
and product is placed, and where the attacks could be coming from.  It 
all depends on whether you are testing from a Voice VLAN port or over 
the public Internet, and what VoIP / UC specific attacks are most at risk.

Again, just my opinion with what I am seeing with the SIP trunking 
adoption rate:  when you open up your VoIP ports to the public Internet, 
the greatest risk from an attacker perspective becomes the risk of 
service abuse / toll fraud / account hijacking and less about exploiting 
vulnerabilities based on fuzzing.  Because we've seen that criminals and 
real attackers are motivated most by financial gain, and vulnerabilities 
related to toll fraud have a high risk, financial impact.

On the subject of relying on automated tools, depending on what you are 
testing, they can be very useful.  But I've never seen a single panacea 
tool that can uncover the most critical of vulnerabilities that can only 
be discovered through combining manual, multiple methods.  For example, 
I was involved in a remote VoIP security test recently, in which the 
customer was suffering financial loss from toll fraud.  We took a 
comprehensive, creative, and technical approach.  By reconnaissance of 
the company's website, we found DID blocks of downstream customers.  We 
then used the WarVox [2] tool to find accounts that were provisioned, 
but not being used.  We then used some other tools and manual methods to 
uncover several critical vulnerabilities that revealed how the VoIP 
accounts were being hijacked for toll fraud.  It's my strong opinion:  A 
security testing methodology should include manual methods as well as 
being able to take outputs from several different tools and combine them 
in a way that can be an exploitable vulnerability.  Had we relied on a 
single tool, we wouldn't have found these vulnerabilities.  Automated 
tool can't find flaws in the business logic of a UC application, or 
vulnerabilities in how SIP accounts are provisioned.  But this "SIP 
Security" book [3] does hint at future tools being able to aid 
administrators by testing for Authorization policies related to Toll 
Fraud.   

To me this is how it works with "security testing":
1.  Understand your customer, their business, and how they are using VoIP
2.  Understand who their customers are and what product / service they 
are selling or using around VoIP (if necessary)
3.  Create a VoIP application flow diagram that maps physical locations 
to logical / VLAN / IP networks, to ingress and egress points for VoIP 
application flow
4.  Understand what VoIP / UC specific attacks the customer is most 
concerned about
5.  Build a list of test cases
6.  Adapt the security testing methodology to the customer environment
7.  Constant communication
8.  Technical assessment
9.  Constant communication
10.  Communicate findings
Vulnerabilities / Discoveries should be communicated in three different 
tones:  To executive management, Managers, and technical personnel.  
Show the vulnerabilities.

Security testing should be communicated so that the CIO can see the 
business impact.  I'm really intrigued to see Dan Yorks' new book [4], 7 
Deadliest UC Attacks.  This looks like one of the first books to address 
this in a unique way.  From what I've seen so far, this book is unique 
in that it communicates technical vulnerabilities as sexy attacks that 
can be understood by the CIO.  Very interesting and good work Dan.  I've 
already pre-ordered a copy!

[1]  "Computer Security", Gollmann, Dieter.  Page 14.

[2]  VIPER Blog on WarVox tool
http://www.viperlab.net/wordpress/?p=14

[3]  "SIP Security", Henning Schulzrinne, et. al, page 83

[4]  "7 Deadliest UC Attacks" website
http://www.7ducattacks.com/

 

Ari Takanen wrote:
> Sooner? ;)
>
> The VoIP industry should be proud of itself! Already in 2002, majority
> of VoIP vendors had some type systematic security testing (smart
> fuzzing) in place, whereas rest of the communication domains are still
> struggling to convince their management of the benefits of proactive
> security testing. Check out e.g. PROTOS tool release from 2002/2003:
>
> https://www.ee.oulu.fi/research/ouspg/PROTOS_Test-Suite_c07-sip
>
> Perhaps with the only exception of SNMP testing, VoIP is the only
> industry where multi-vendor vulnerability handling spawned an industry
> of its own (with us at Codenomicon perhaps only two years ahead of the
> rest):
>
> http://www.cert.org/advisories/CA-2003-06.html
>
> Also in no other industry have you had industry bodies defining
> protocol misuse cases (and having annual meetings around them) since
> 2003. Even the industrial automation industry are only now trying to
> work anything similar. Check out e.g.:
>
> http://tools.ietf.org/html/draft-ietf-sipping-torture-tests-00
>
> and
>
> http://www.ietf.org/rfc/rfc4475.txt
>
> The VOIP community is YEARS ahead of the rest of the software
> community. Every single VoIP vendor I know does some sort of fuzzing,
> with majority of them use at least two commercial solutions in
> addition to their internally built test harnesses. Most of them have
> had continuous security programmes since 2003. 
>
> Also if you look at the service providers in VoIP, you see that most
> end-users do fuzzing. In most VoIP operators that I have worked with,
> it is a natural part of procurement process. They just refuse to buy
> bad quality software. Security is a customer requirement, and
> therefore _key part of the business_.
>
> I have been looking at the security testing industry for quite some
> time, and there are very few other market domains where security
> testing is at the same maturity level. In VoIP, security equals
> quality. Security is part of software development. Security is not
> only about features and functionality, it is about systematic
> elimination of bugs. It is about software reliability and
> dependability.
>
> All the rest of the industries still think "hacking" needs skills and
> right attitude. VoIP engineers understand that it is just about tools,
> processes and techniques.
>
> Sorry for the rant, I suppose something snapped when I read the word
> "sooner". ;)
>
> Best regards,
>
> /Ari
>
>