On October 29, 2014 the security team for Drupal, the popular open source content management system (CMS) for over a billion websites, released a public service announcement advising their 12 million customers to update their software due to a SQL injection attack.
Drupal’s announcement said, “Automated attacks began compromising Drupal 7 websites that were not patched or updated to Drupal 7.32 within hours of the announcement of a SQL injection vulnerability (SA-CORE-2014-005). You should proceed under the assumption that every Drupal 7 website was compromised unless updated or patched before October 15, 11pm UTC.”
The vulnerability allows hackers to use SQL injection to breach core code intended to prevent such attacks, and then take control of a website’s database. Once a web server has been compromised, the patch can’t help. In fact, according to Hacker News, if you did not download a patch but the patch is already there when you attempt the fix, your website has been infiltrated.
This tactic is a similar type of exploit used in the JP Morgan breach, in which personal information of 83 million clients was stolen. According to media reports, an employee for JP Morgan’s Corporate Challenge event with administrative access used the same computer at home and on the company network, inadvertently compromised the website’s security certificate and exposed participating employee usernames, passwords and email addresses. Hackers gained access to 90 of the bank’s servers using the stolen login information from the Corporate Challenge’s compromised website.
Website vulnerabilities are especially alarming because of the plethora of information that is stored in website back end data bases. Every time we input information into a website form, we rely on the owner of the website to secure our information. Consider the point that website data bases contain usernames, passwords, names, addresses, phone numbers, and email addresses, birth dates, social security numbers, bank account info, etc. When we provide this information we trust that the Webmaster is keeping the website front end up to date and free of vulnerabilities. We trust that appropriate security measures are applied to the data base to keep our data safe. The reality is that while most of us do trust that the Websites we frequently use are secure, many are not.
Hackers exploit vulnerabilities to penetrate websites without being detected, and with the intent of exfiltrating data or establishing footholds from which they can traverse an organization’s network.
The most common tactic used by adversaries to penetrate Web applications by exploiting SQL (structured query language) Injection vulnerabilities. SQL is programming language used to manage relational databases. Adversaries employ this tactic by inserting, or “injecting”, SQL commands into web application using the Website’s normal data input mechanism e.g. dialogue box. If the coding behind the input mechanism isn’t written such that only precise data values are accepted as valid input, an adversary could substitute SQL commands for the desired data. For example; if an adversary can enter something other than a 10 digit phone number into a dialogue box asking for a 10 digit phone number, without getting an error response from the Web application, then the Web application could be vulnerable to SQL Injection. By exploiting this vulnerability, an adversary could be capable of reading, modifying, or exfiltrating data.
Another common tactic used by adversaries to penetrate Web applications is by exploiting Cross-site scripting (XSS) vulnerabilities. XSS allows an adversary to combine malicious content with valid content being delivered to a client Web browser. For example, if an adversary identifies a XSS vulnerability on an online shopping Website, the adversary could use that website as the basis for a Phishing attack against an unsuspecting third party. The phishing email would contain a link to a valid website, combined with malicious code that could execute any number of commands. The XSS vulnerability is manifested in the Web applications inability to identify the additional malicious code.
Mike Walls is Managing Director, Security and Operations and Analysis at EdgeWave. While on Active Duty in the U.S. Navy, Mike served as Commander Task Force 1030 reporting directly to the Navy’s Fleet Cyber Command, and was responsible for Cyber readiness of over 400,000 people, 300 ships, and 4,000 aircraft. Comments and questions for Mike Walls are welcome: firstname.lastname@example.org