The 2019 Database Gold Rush

The California Gold Rush began in 1848 when James W. Marshall discovered gold at Sutter’s Mill in Coloma, California. Just over 170 years later, we are experiencing a similar rush, only this time it is data being mined, instead of gold. The data gold rush may have had a slower start, but the value to those who are doing the mining is similar.

What Makes Databases So Valuable?

Database attacks are on the rise, and that really is not surprising due to the massive return on investment cybercriminals receive from these types of attacks. As you can see in the chart below from Statista, data breaches rose more than tenfold between 2005 and 2017. While 2018 showed a slight decline, you can see that the number of records that were exposed increased drastically, likely indicating cybercriminals are becoming more brazen in their attacks. The data indicates that attackers are going after larger data sets, rather than relying on getting their data from a larger number of smaller attacks.

Now think about the type of data you enter when you create a new account on a website. You are often required to provide your email address, date of birth, first and last name, and a password. This is valuable personal data that can be used for anything from targeted advertising to identity theft in extreme cases. Modern websites will typically keep this data inside of a database, which means that exploiting a database vulnerability to access this data can be much more lucrative than simply accessing the website’s files.

Taking a look at the Equifax breach discovered in July of 2017, initial reports showed that Social Security Numbers, birth dates, addresses, and driver’s license numbers were accessed. Additional review indicated that other personally identifiable information (PII) such as name, date of birth, and credit card data may have been leaked as well. With a name, date of birth, and social security number, there is very little an attacker couldn’t do in your name.

In 2013, Yahoo was the target of what is still the largest breach of data in history, with over 3 billion accounts getting compromised. The information stolen included names, email addresses, date of birth, and phone numbers. In 2014 eBay announced that over 145 million users’ information had been stolen, including names, addresses, date of birth, and passwords. Even as recently as 2018, Marriott International reported that an attack from 2014 left over 500 million users’ information exposed.

How Do Databases Get Compromised?

There are quite a few attack vectors available to breach a database. If you have a Content Management System (CMS) like WordPress or Joomla!, failing to regularly update your theme, plugin, and core files is a huge security risk. These updates often contain security patches intended to fix a vulnerability. Ignoring these updates is like going on vacation and leaving your bedroom window open. An attacker might not be able to walk in the front door, but by exploiting the vulnerability, they potentially have easy access in a way your average user probably wouldn’t look for.

Privilege Escalation & Brute Force Attacks

Privilege escalation is a broad term that generally means that a malicious actor is able to obtain an access level that is higher than what they would normally be granted such as admin access. What makes this type of attack attractive, is the fact that there are often ways to export database contents from within an administrative control panel in a CMS by allowing the attacker to utilize database management or backup solutions within the control panel. Even without direct database access, the attacker would at least have access to most of the valuable data stored in the database.

Brute force attacks are similar to privilege escalation in results. In the event of a brute force attack, an attacker utilizes different username and password combinations, in an attempt to find a combination that gives them admin access. The more administrators a site has, the greater the risk of an attacker executing a brute force attack to compromise the valuable contents within a database. Each admin user represents a potential access point to your site, which means site owners should limit the number of administrators that have full access to the website. All it takes is one weak password, one click on a phishing email, or one re-used password that has already been compromised, for an attacker to gain unauthorized access to your site.

Cross-Site Scripting & SQL Injection

Custom-built websites can also be vulnerable to attacks, including sites built with a CMS. These custom websites can fall victim to nefarious attacks, especially if they have a control panel. However, those aren’t the only ways to gain unauthorized access to database content. Any site that does not properly sanitize user inputs will put the site at risk of cross-site scripting (XSS) or SQL injection (SQLi) attacks.

In SiteLock’s 2019 Website Security Report, we analyzed 6 million websites in our sample data to determine the most prevalent cyber threats websites face today. We found that of the websites we scanned, 1.4% had an XSS vulnerability and 6% had a SQLi vulnerability, which could be devastating for a website owner. These vulnerable sites are 3.3 times more likely to become infected with malware than a site without a vulnerability. An internal review has also shown that out of the sites we clean manually, approximately 30% had database infections.

XSS attacks are one-way malicious actors can trick a site user into inadvertently providing sensitive information. The attacker can use XSS to steal session cookies or even create fake login pages, which then collect the credentials and provide them to the attacker. This is yet another example of an attack that allows an attacker to gain admin access to the site, resulting in unauthorized access to any content or backup options available directly from the admin dashboard.

Ultimately, if a malicious actor is specifically targeting data stored within a database, the attack vector of choice is a SQL injection attack. This type of attack results in an attacker taking advantage of improperly formatted code and retrieving valuable information from the database without ever needing to authenticate or login. A SQL injection works in a similar way to XSS because the code can often be added in a form field or the address bar. If the website’s code is not properly sanitized, an attacker now has access to information that should not be public-facing.

The advantage a SQL injection attack has over other attack methods is the direct access to the database, rather than having to work through an admin console. An attacker’s best options for direct access are utilizing backup options or installing a database management plugin. SQL injection is also relatively easy to achieve if the site is vulnerable. Consider the URL below:

http://sl-example.com/shop/ite...; DROP TABLE users

This is a very common example of a SQL injection attack. Everything in this URL, through the equal sign, is legitimate — that’s where this gets interesting. A malicious actor can pick a random item_id – here we used 999 – and then insert a semicolon. Everything after the semicolon will be understood by the database to be a new query. In this case, the new query would cause an error on the page if item 999 does not exist and then the database will delete the users table. This same method can be used to run any number of database queries, allowing a malicious actor to steal any data they deem to be of value to them.

Steps Users Can Take To Secure A Database

The exact steps to secure your database will be dependent on exactly how your website and database are configured. There are definitely a few key things to consider when looking at securing your database: the principle of least privilege, sanitized inputs, regular updates, and using an SSL certificate.

The Principle Of Least Privilege

According to the 2019 Verizon Security Report, 34% of breaches involved internal actors. These types of breaches may not have been made with malicious intent, which indicates the security issues within your database may be the result of insecure internal practices rather than a targeted attack. As a best practice, the principle of least privilege means not giving more access than is actually needed. When it comes to users on your site, consider who really needs admin access, who just needs editor or contributor access, and who only needs to be able to view the public pages on the site. It is also a good idea to regularly audit your users, adjusting access levels based on current need, and removing users who do not need access that requires a login.

This same principle can be applied directly to the database itself. When setting up a database, at least one database user is required to access the database. While it is necessary to have an admin user with escalated privileges on the database, this should not be the only database user with access to the database. A good practice is to have a user specifically for the website, using a minimal set of privileges, and an administrative user that has the ability to manage database users, update privileges and perform other functions the website doesn’t need to use. This will limit what a malicious actor can do with a nefarious database connection. Database access must always be considered for proper functionality, and all other database privileges should not be allowed for this specific database user. As an example, WordPress only requires the following database privileges; Select, Insert, Update, and Delete. Thus, eliminating the Drop privilege within the database, the SQLi example above would not function, keeping your users table intact.

Sanitized Inputs

As websites become more data-driven than ever before, contact form submissions are an example of how website owners are collecting data through their websites. It may surprise you to know that these simple forms are seen as a valuable commodity to attackers. The idea behind sanitizing an input field on a contact form is to only allow expected content to be submitted, essentially hardening vulnerable code. Expected content, in this case, means predefining what the user can input, right down to the type of characters that are allowed. This could be as simple as rejecting text in a date field, limiting the number of characters allowed, or requiring an appropriate pattern for an email field, which reduces the risk of unauthorized requests to your database. Additionally, upload forms should not accept just any file type, and any input field should make use of code that prevents any submitted code to be recognized as anything other than plain text.

Regular Updates

Performing regular updates on your CMS or other applications is a necessity for any website owner. Neglecting to update your website when available security updates are released, leaves you vulnerable to exploitation by malicious attackers. Updates can be more complicated with a custom-built website, as they will require code review, and manual updates to patch any security vulnerabilities. When a custom site is being considered, there should be ample time spent on analyzing whether manual security updates are feasible for the site. These code reviews should be performed on a regular basis, while also paying attention to announced vulnerabilities in the core technologies used to build the website.

For websites built in a CMS, one of the best things you can do is enable automatic updates on the core application, as well as any themes, plugins, or extensions that allow it. This will ensure that your site gets any new security updates as soon as possible. An admin should also regularly be logging in to the admin console, looking for available updates and notifications from developers. Website owners should also look into an automated solution to automatically patch security vulnerabilities within website code, plugin, CMS, and Ecommerce applications.

SSL Certificates

An SSL certificate, sometimes branded as a TLS certificate, encrypts the traffic between the server a website is stored on and the device the site visitor is using to view the website. While this doesn’t protect the server itself, it does ensure sensitive data is encrypted and can’t be read by an attacker in the event it’s intercepted. This is especially important on any page where sensitive data is provided, or requested, such as a contact form.

In addition to securing your data with the methods mentioned above, a comprehensive security solution should be used to account for anything you may have missed or any undiscovered vulnerabilities. It is always a good idea to implement a web application firewall to protect against malicious traffic and bots, and a website scanner to detect and clean malware that has been injected into the website or database.

SiteLock remains focused on delivering industry-leading cybersecurity solutions, especially in the face of this database gold rush. SiteLock understands website owners’ need to scan any web application using a MySQL database — including identifying and removing malware, spam content, and even bad WordPress users from the database. SMART® Database™ (SMART/DB™), is the first and only automated database malware and spam content removal tool that scans a MySQL database including WordPress and Joomla!

By Topher Tebow & Ron Doss