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 Cam
bium 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.
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.