Tuesday, February 24, 2009

Cambium Group, LLC. CAMAS Advisory

We've finally released the Cambium Group, LLC Content Management System ("CAMAS") advisory after much waiting and debate. These security risks were discovered in CAMAS during a customer penetration test that we did in August of 2007 (we notified the Cambium Group about these risks on 08/24/2007). The security vulnerabilities that are disclosed in the advisory are kept very high level and low detail as to not arm any potentially malicious people. Unfortunatley the vulnerabilities still exist today (almost two years later) according to some recent Google research that we did. In fact, according to Google's cache the Cambium Group's own website was vulnerable as of Feburary 9th 2009 to the exact same vulnerabilities that we alerted them to on 08/24/07 (see the screen shot below).


We can't ethically test Cambium Group customer's websites without their permission, hence why we rely on Google for this information. Google sometimes triggers vulnerabilities in websites while crawling them and the results get recorded to Google's database. When that happens they become searchable (and get cached). Malicious hackers and script kiddies also use Google in this way to identify websites that are vulnerable to SQL Injection. This gives them an easy set of targets that they can compromise with little effort.

You can check to see if Google stumbled upon a vulnerability in your instance of CAMAS by using the following technique. Type the following string into the Google search engine but replace www.company.com with your company's domain (see the screen shot below as an example.) String (without the quotes): "inurl:www.yourcompany.com 1064 You have an error in your SQL"

When you hit the search button (and if Google has a cached version of your website being vulnerable) you will see a link that reads something like "1064: You have an error in your SQL syntax near '' at line 1 select * from Template where TemplateID =". That error is an SQL error that demonstrates that your website is (or was) vulnerable to SQL Injection. SQL Injection Vulnerabilities are one of the more serious risks because they can be used by hackers to gain administrative levels of access to websites, web servers and their respective content.

Unfortunatley, if Google doesn't respond with something like the response shown above, you might still be vulnerable. SQL Injection vulnerabilities can also be blind in nature, meaning that they do not throw errors back to the attacker but that they can still be used to penetrate into systems (in some cases they may throw non-informational errors). *Additionally, CAMAS isn't only vulnerable to SQL Injection, but it is also vulnerable to Cross-Site Scripting, Cross-SIte Request Forgery, Local File Inclusion, Remote File Inclusion, and some Cryptographic Weaknesses (*according to testing done in 2007 and to more Google homework).

The reason why we were unable to come forward with this advisory back in 2007 is because the Cambium Group hadn't yet fixed the vulnerabilities that we discovered in our customers instance of CAMAS. We were only recently able to come forward because an ex Cambium Group consultant exposed these same vulnerabilities in a posting that he made to the Full Disclosure mailing list. As a result we felt that it would be prudent to release a formal advisory to help CAMAS users become aware of the risks and defend against them.

Our normal process for vulnerability research and advisory release is to work with the vendor in a friendly and professional manner. We've got quite a bit of expereince in doing this with vendors like Apple, HP, etc. In most cases vendors respond with questions about how to fix the vulnerabilities that we discovered. We provide them with all of the information that we can and wait for them (while working with them) to create a fix.

In most cases this process takes anywhere from 3 to 6 months, but when its done, we've done our job and the risks are eliminated. Not only does this type of work help the vendor to keep their customer's safe, but it also enables the vendor to demonstrate to their customers that they take security seriously. We attempted to follow the same practice with the Cambium Group, LLC. but no fixes were ever pushed out to their customers (based on what we saw). To the best of our knowledge, this is the first time that a CAMAS advisory has been released about the vulnerabilities that we discovered in 2007. If that is inaccurate, please leave us a comment and we'll consider updating this entry.

In addition to our advisory being published, there also exists a good article that was written by Dan Goodin at the register. Dan Goodin took the time to contact the Cambium Group to hear their side of the story before writing the article (as any good reporter does). Something to make note of before reading the article is a quote from Scott Wells where he said "All of the recommendations that Netragard gave were followed and the site was then able to pass their validation process." We're not sure why he said that, we never rechecked the customer site and we don't have a "validation process".

If you are a Cambium Group customer then there are a few things that you can do to ensure the saftey of your website and its respective users. The first recommendation that we have is to perform a Web Application Penetration Test against your website. You can do this yourself in a light weight sort of way by using a scanner like NTOspider or WebInspect (we're not affiliated with either but we'd recommend NTOspider). Having said that, we're not too fond of relying on automated tools for security so we recommend that you hire a qualified third party to test the security of your website. Make sure that they do manual testing, not just automated testing.

We also recommend that any Cambium Group customer consider installing a reverse proxy with application layer filtering capabilities. These proxies are designed to analyze web traffic being sent from web users to your website. If the data is normal web traffic then it is allowed to reach your website, but if it contains malicious data that matches known attack patterns then it is blocked and never reaches your website. This prevents attackers from being able access the vulnerable components of websites that suffer from various risks. Examples of such proxies are ModSecurity and BlueCoat (there are many others and we're not affiliated with any of them).

The other way to defend against these vulnerabilities is to impliment properly designed parameterized stored proceedures and to use strong input validation and data sanitization techniques as defined by the
Open Web Application Security Project. This is true for for any Web Application, not just CAMAS. Never the less, in the case of CAMAS the Cambium Group would need to impliment these changes, you would probably not be able to because CAMAS is not an open source product.

If you have any questions about this blog entry please do not hesitate to contact us with any of your questions or concerns. You can either leave us a comment on the blog and we'll respond promptly, or you can contact us off-line and we'll keep it confidential. Your privacy and security are our top concern.

Update:  One of our readers sent us a link to The Vermont Statutes Online, Title: 9 Commerce and Trade Chapter: 62 Protection of Personal Information 2435. Notice of security breaches.  If you are a CAMAS customer then it is our understanding that you should have received notification of these risks based on the aforementioned statute. 

6 comments:

  1. I just wanted to say thank you for making this information public knowledge and good work!! I work for a credit union that uses this content management system and we never received any notification from the Cambium Group about these risks. When I saw your blog entry I decided to check our our website to see if we were vulnerable and we were. Isn't the Cambium Group supposed to notify us about risks like this? According to your blog post you told them about this in 2007, why didn't they contact us?

    ReplyDelete
  2. Thank you for the comment! I'm not sure if they are "supposed to notify you of risks, but it certainly is the prudent thing to do. Lots of vendors that we work with release advisories to their customers before they release public advisories. This enables them to protect most of their customers before the rest of the world gets wind of the risks. Unfortunately, based on what you are saying that customer level notification didn't happen. You might want to call the Cambium Group to discuss this.

    ReplyDelete
  3. Quoting this entry: "That error is an SQL error that demonstrates that your website is (or was) vulnerable to SQL Injection."

    No it doesn't. It simply means that a DB error was encountered and the error message was displayed in the browser.

    If you have the credibility to be releasing a "security advisory" why do you have this simple fact wrong?

    ReplyDelete
  4. In response to Anonymous posted on April 17th, 2009 at 5:21 AM --

    You are wrong, here's why.

    SQL injection is a code injection technique that exploits a security vulnerability occurring in the database layer of an application. The vulnerability is present when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and thereby unexpectedly executed.

    In the example above we are able to generate an error in the database layer of the application by injecting arbitrary data into the TemplateID variable. The result of that arbitrary data is the error that you see above.

    During our penetration test we were able to inject a specially crafted SQL statement into the application. When the TemplateID variable was processed our SQL command was successfuly executed and we were able to dump the contents of the entire database. After that point we were able to gain administrative levels of access to CAMAS and from there we were able to gain root access to the system. (Not disclosing the techniques that we used.)

    Next time you attempt to discredit something you should do your homework first.

    ReplyDelete
  5. I wouldnt waste my breath Adriel. Posting an advisory was doing the right thing. Any good programmer knows that, anyone who would try to deny it well....

    ReplyDelete
  6. I believe vermont has this statue in effect. So this company is required by law to report security breaches to there clients.

    http://www.leg.state.vt.us/statutes/fullsection.cfm?Title=09&Chapter=062&Section=02435

    ReplyDelete