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. 

Netragard : Facebook from the hackers perspective.

For the past few years we've (Netragard) been using internet based Social Networking tools to hack into our customer's IT Infrastructures. This method of attack has been used by hackers since the conception of Social Networking Websites, but only recently has it caught the attention of the media. As a result of this new exposure we've decided to give people a rare glimpse into Facebook from a hackers perspective.  Credit for designing this specific attack methodology goes to Kevin Finisterre and Josh Valentine both core members of our team. 

Lets start off by talking about the internet and identity. The internet is a shapeless world where identities are not only dynamic but can't ever be verified with certainty. As a result, its easily possible to be one person one moment, then another person the next moment. This is particularly true when using internet based social networking sites like Facebook (and the rest).

Image provided by Michael Painter

Humans have a natural tendency to trust each other. If one human being can provide another human with "something sufficient" then trust is earned. That "something sufficient" can be a face to face meeting but it doesn't always need to be. Roughly 90% of the people that we've targeted and successfully exploited during our social attacks trusted us because they thought we worked for the same company as them.

The setup...

Facebook allows its users to search for other users by keyword. Many facebook users include their place of employment in their profile. Some companies even have facebook groups that only employees or contractors are allowed to become members of. So step one is to perform reconnaissance against those facebook using employees. This can be done with facebook, or with reconnaissance tools like Maltego and pipl.com.

Reconnaissance is the military term for the collection of intelligence about an enemy prior to attacking the enemy. With regards to hacking, reconnaissance can be performed against social targets (facebook, myspace, etc) and technology targets (servers, firewalls, routers, etc). Because our preferred method of attacking employees through facebook is via phishing we normally perform reconnaissance against both vectors.

When setting up for the ideal attack two things are nice to have but only one is required. The first is the discovery of some sort of Cross-site Scripting vulnerability (or something else useful) in our customers website (or one of their servers). The vulnerability is the component that is not required, but is a nice to have (we can set up our own fake server if we need to). The second component is the required component, and that is the discovery of facebook profiles for employees that work for our customer (other social networking sites work just as well).

In one of our recent engagements we performed detailed social and technical reconnaissance. The social reconnaissance enabled us to identify 1402 employees 906 of which used facebook. We didn't read all 906 profiles but we did read around 200 which gave us sufficient information to create a fake employee profile. The technical reconnaissance identified various vulnerabilities one of which was the Cross-site Scripting vulnerability that we usually hope to find. In this case the vulnerability existed in our customer's corporate website.

Cross-site scripting ("XSS") is a kind of computer security vulnerability that is most frequently discovered in websites that do not have sufficient input validation or data validation capabilities. XSS vulnerabilities allow an attacker to inject code into a website that is viewed by other users. This injection can be done sever side by saving the injected code on the server (in a forum, blog, etc) or it can be done client side by injecting the code into a specially crafted URL that can be delivered to a victim.

During our recent engagement we used a client side attack as opposed to a server side attack . We chose the client side attack because it enabled us to select only the users that we are interested in attacking. Server side attacks are not as surgical and usually affect any user who views the compromised server page.

The payload that we created was designed to render a legitimate looking https secured web page that appeared to be a component of our customer's web site. When a victim clicks on the specially crafted link the payload is executed and the fake web page is rendered. In this case our fake web page was an alert that warned users that their accounts may have been compromised and that they should verify their credentials by entering them into the form provided. When the users credentials are entered the form submitted them to http://www.netragard.com and were extracted by an automated tool that we created.

After the payload was created and tested we started the process of building an easy to trust facebook profile. Because most of the targeted employees were male between the ages of 20 and 40 we decided that it would be best to become a very attractive 28 year old female. We found a fitting photograph by searching google images and used that photograph for our fake Facebook profile. We also populated the profile with information about our experiences at work by using combined stories that we collected from real employee facebook profiles.

Upon completion we joined our customer's facebook group. Joining wasn't an issue and our request was approved in a matter of hours. Within twenty minutes of being accepted as group members, legitimate customer employees began requesting our friendship. In addition to inbound requests we made hundreds of outbound requests. Our friends list grew very quickly and included managers, executives, secretaries, interns, and even contractors.

After having collected a few hundred friends, we began chatting. Our conversations were based on work related issues that we were able to collect from legitimate employee profiles. After a period of three days of conversing and sharing links, we posted our specially crafted link to our facebook profile. The title of the link was "Omigawd have you seen this I think we got hacked!" Sure enough, people started clicking on the link and verifying their credentials.

Ironically, the first set of credentials that we got belonged to the person that hired us in the first place. We used those credentials to access the web-vpn which in turn gave us access to the network. As it turns out those credentials also allowed us to access the majority of systems on the network including the Active Directory server, the mainframe, pump control systems, the checkpoint firewall console, etc. It was game over, the Facebook hack worked yet again.

During testing we did evaluate the customer's entire infrastructure, but the results of the evaluation have been left out of this post for clarity. We also provided our customer with a solution that was unique to them to counter the Social Network threat. They've since implemented the solution and have reported on 4 other social penetration attempts since early 2008. The threat that Social Networks bring to the table affects every business and the described method of attack has an extraordinarily high success rate.

They will protect my data (won't they?)

So the other day I was talking with my buddy Kevin Finisterre.  One of the things that we were discussing was people who just don't feel that security is an important aspect of their business because their customers don't ask for it.  That always makes my brain scream "WHAT!?". Here's a direct quote from a security technology vendor "We don't perform regular penetration tests because our customers don't ask us to do that."

Isn't it the service provider's/vendor's responsibility to properly manage and maintain the security of their infrastructure?  Don't they have an ethical obligation to their customers to protect the service that they are offering and any information that the customers decide to store on their systems?

The real question is, how many customers would they lose if the customers heard them say that? That is after all just like saying "We don't care about security because our customers aren't asking us to care about it."  

So who have I heard this from? Here's the (very) short list:

• Vendors that make security software (like email gateways, anti-virus technology, Intrusion Prevention Systems, etc).
• Vendors that make technology that is used to control our Nuclear Power Plants, Water Purification Plants, Traffic Control Systems, etc.
• Vendors that sell business enabling technologies like PHP based Content Management Systems, Commercial Web Servers, Server based applications, Web Applications, etc.
• Vendors that sell desktop applications like Financial Tracking Systems, Invoicing Systems, File Sharing Systems, Backup Solutions, etc.
• I've also heard this from MAJOR Service Providers such as Web Hosting Providers, Email Providers, Backup Service Providers, etc.
• The list goes on....
  

I think that people need a wake up call.  This strikes me as a serious ethical issue, what about you? Leave me a comment I'm very interested in feedback on this one.