OWASP #4 Continues to Laugh at Automated Scanners

I was thinking back to 2006 when I was new to the world of Application Security.  Someone on our consulting team arranged a call with a vendor called Secure Software, Inc.  They were a company with a code scanning product called CodeAssure, but they were probably best known for a freeware tool called Rough Auditing Tool for Security ("RATS").  The company was bought by Fortify in 2007 and their products essentially died off. 

On the call I wanted to better understand how this magical CodeAssure product worked.  For example, how could it recognize Insecure Direct Object Reference in a web application?  (Actually, that term wasn't even coined yet.  Back then it was called Broken Access Control. Come to think of it, I like that name better.)  Anyway, I described some of the vulnerabilities I was seeing during my application pen testing where I could edit numerical parameters in the URL or the HTTP request body and gain access to another user's data.

For a moment, there was dead silence on the call.  It was one of those times when nobody on their side knew how to answer and they were all hoping that one of their teammates would step up and offer an intelligent response.  In the end there was no intelligent response, only dancing around the question as sales people often do.  I was a little naive back then to ask the question in the first place.  I should have known their product could do absolutely nothing to identify this type of vulnerability. 

SAST scanning tools can't be relied upon to identify insecure direct object references.  But hey, the same is true for dynamic scanners.  DAST tools aren't human and aren't smart enough to know that if you change acct_id=100011 in a URL to acct_id=100012 and you get back a valid response with another person's data that it's a big freaking problem.  The exploitability rating of this flaw is off the chart.  Almost anyone can perform the attack and it is still happening today.  Even big companies that pay attention to security like Citibank can succumb. 

The bottom line in my opinion is that you can't use one security testing technique and have confidence that your apps are secure.  Multiple testing approaches are needed for the best assurance.  Obviously, cost is a factor here, but for your most business-critical applications, I would use SAST, DAST, and manual pen testing.  Techniques like IAST and RASP are making strides and have much promise as well.  Both of these are going to require development teams to be more involved (and accountable) for application security however.   

Bug in WebEx Productivity Tools Exposed Audio Conference Credentials

I recently found a security bug in Cisco's WebEx Productivity Tools.  The bug caused your audio conferencing credentials to be sent out in meeting invitations.  It was limited in scope to InterCall customers who integrate with WebEx.

Background:
InterCall is an audio conferencing solution and can be used as an alternative to WebEx's built-in audio.  My company is starting to roll out WebEx this way.  InterCall users have a dedicated  conference code and a leader PIN which are your account credentials.  The conference code is meant to be public, but the leader PIN is like a password and should be kept confidential.  Productivity Tools (PT) is an add-on product for WebEx customers.  One of the key features is an integration with Outlook that allows you to create WebEx meetings and send out the invitations from within Outlook.

The Discovery:
First I set up WebEx to use my InterCall account for audio and then downloaded and installed WebEx PT.  Next I created a test WebEx meeting from within Outlook and invited one person.  Upon clicking "Send", PT securely communicated to the WebEx server to auto-populate the conferencing information in the meetng invite.  When the information appeared, I saw my InterCall leader PIN just for a moment before the email was sent.  At first I thought it was a mistake, but inspection of my Sent Items folder showed that my PIN was indeed sent.  The person who received the invite confirmed he got my PIN as well.  Wow!  How could no one at Cisco or my company notice this?  I was unable to find a work-around except for avoiding PT altogether by logging into the WebEx site and creating a meeting from there.

The WebEx meeting host key was also exposed in the email, but that wasn't too worrisome because it changes with each meeting.

The Fix:
I reported this security threat to Cisco (and InterCall) on April 28th.  After pestering them for updates, Cisco Engineering finally confirmed to me on May 14 that it was a defect and that they were working on a fix.  I can now confirm that the bug has been fixed in WebEx Productivity Tools Version 2.36.13013.10003, which was released on May 19, 2015.  I would like to thank both InterCall support and Cisco PSIRT for their attention to this matter.  For reasons that are unclear, Cisco hasn't released a security advisory or security alert about this issue  This blog post will have to suffice.

I'd like to be able to say that technical acumen and advanced hacking were needed to find this vulnerability.  Alas that was not the case!  I was just curious about my new WebEx toy, wanted to understand how it worked, and stumbled upon it. Being curious and questioning things... it's what people in information security tend to do.

Update: On May 28th I received an email from WebEx notifying me about the patch for the vulnerability: