Database Vulnerabilities

What is a database?

 Database is a collection of information setup into a logically-related format application so an organization can access their files in a structured way. It’s designed, built, and populated with data for a specific purpose. It has an intended group of users and some preconceived applications in which these users are interested

How do database applications make databases more useful?

The Data entry forms are used to read, insert, modify, & delete data.

These reports are used to show data in a structured context like

 Collection of names,

Home address

Telephone numbers

Collection of words to make paragraph in a page

What type of DBMS are available for personal, small office or Corporation?

•       MySQL

•        PostgreSQL

•       Microsoft SQL Server

•       Oracle

•        Sybase

•       SAP HANA

Top Ten DataBase Vulnerabilities

•       Default, Blank & Weak Username/Password

•       SQL Injections in the DBMS

•       Excessive User & Group Privilege

•       Unnecessary Enabled Database Features

•       Broken Configuration Management

•       Buffer Overflows

•       Privilege Escalation

•       Denial of Service Attack DoS

•       Unpatched Databases

•       Unencrypted sensitive data – at rest and in motion

Default, Blank and Weak Username and Passwords

Today’s topic is Default, Blank & Weak Username/Passwords.

Most DBMS’s now ask for custom usernames and/or passwords in the installer screens. Nonetheless, the risk has not been eliminated. At present, Googling ‘Oracle default users’ produces more than 3 million pages, with more than 1,000 default username/password combinations.

To create a strong password:

•       Don’t use words that can be easily guessed or found in the dictionary

•       Use a combination of letters, numbers and characters

•       Create a complex sentence instead of a word

•       Do not share your password with anyone or write it down and leave it in your desk drawer

SQL Injections in the DBMS

Similar to the Web-based variant, SQL Injection in the DBMS exploits passing SQL commands as a parameter of a function or stored procedure. This will then execute the malicious SQL commands in the context of the component that provides the called function. This is often done using components with system or admin privileges resulting in privilege escalation.

Excessive User & Group Privilege

•       The process of collecting and untangling the web of all rights that a user has can become a daunting task. Privileges aren’t typically just assigned directly to the users they also inherit privileges from groups or roles they belong to.

Follow these steps in order to avoid extensive user and group privileges:

1. Map Job Functions to Privileges on IT assets
2. Never Assign Privileges Directly to Guest Accounts or Public
3. Untangle The Web of User Entitlements
4. Implement Compensating Controls for What You Can’t Fix

 Unnecessary Enabled Database Features

They now offer many features to analyze and report on data, run Java and other extensible languages, and even have various levels of OS access built in.

These features provide database application developers with a lot more power when working with a DBMS.  The flipside of the coin is, the more power you give a developer, the more attack vectors you potentially expose to the bad guys.

Many of these features are optional and are not required by applications accessing a Database Management System. DBMS vendors like to include all the bells and whistles in order to up-sell opportunities.

Check your Database Configurations

•       Once upon a time, Database Management Systems (DBMS) had only a handful of configuration options and they didn’t allow the DBA many choices.

•       The options available were simple - naming the database instance or which storage location to use for the data files.

•       Today, there are a myriad of configuration options – many related to performance and enhanced feature sets. There are also many options that are either direct security settings, or that impact security.

•       Having the correct configuration settings could determine whether or not your critical business information is secure and whether it could be compromised.

Buffer Overflows

A buffer overflow is when the input to a function contains more data than the input buffer can hold. If the size of the input is not checked during the copy to that buffer, adjacent memory that is used for other purposes might get overwritten. In most cases, this will be more or less random and can lead to unpredictable behavior, like crashing the server. However, if an attacker is able to also change the code execution pointer to the location of the overwritten memory, it is possible to execute any kind of malicious code using the context of the DBMS process. This could lead to a potential total compromise of the system, resulting in loss of sensitive information and overall security.

To protect against these types of attacks, it is important to always keep your DBMS updated with the latest security patches available from the vendor, as well as monitoring for known attack signatures.

Privilege Escalation

In any well configured Database Management System (DBMS), accounts are restricted to only perform the actions and access the data that they require to perform their job functions. For anybody with malicious intent, this is like being at a candy store, but you’re stuck in the room that only has oatmeal cookies. There could be a whole database with millions of credit card numbers, but you only have access to the organizations marketing folder.

Of course, too often, the locks to the candy store are easy to pick.

A privilege escalation attack is when the attacker is exploiting a known vulnerability in a DBMS that allows a user account with restricted privileges to execute instructions or query data that that typically requires higher privileges. Thus unlocking the locks in the candy store.

There are different common vulnerabilities that allow for privilege escalation. Sometimes misusing a function that runs under a sysdba, sa or similar security context. In other cases it is done by exploiting vulnerabilities that allow a low-privileged account to grant itself more rights.

To protect against these types of attacks, it is important to always keep your DBMS updated with the latest security patches available from the vendor, as well as continuously monitor for known attack signatures.

Denial of Service

Think of a washing machine. The more clothes you put in it, the more work it needs to do. If you overfill it with clothes, it gets overwhelmed and stops working. The same thing happens with a Denial of Service attack. It creates so much traffic on a site, a server or even sections of the internet that it cannot function and shuts down.

The most infamous DoS involving database servers was in 2003 when a computer worm called the SQL Slammer compromised more than 75,000 servers and slowed internet traffic to a halt.

The problem – unpatched Microsoft SQL Server databases.

The SQL Slammer vulnerability was fixed by Microsoft fairly quickly – six months before the attack surfaced. Unfortunately, many DBAs didn’t patch their databases timely and because of it, the Slammer took down the internet.

To mitigate risk and ensure critical databases stay up and running, be sure to patch all databases with the latest vendor patches once they are available.

Unpatched Databases

Organizations house sensitive data – typically in databases. In response to the ever-changing vulnerabilities that are being exploited by attackers, database vendors release patches to ensure sensitive information in databases is protected from threats.

The good news. Most vendors provide patch updates on a fairly regular basis. For instance, Oracle provides a critical patch update (CPU) every quarter.

Now for the bad news. Once these patches are released they should be patched – at least the most critical vulnerabilities. If left unpatched, hackers can reverse engineer the patch, or can often find information online on how-to exploit the unpatched vulnerabilities, leaving a DBMS even more vulnerable that before the patch was released.

Unencrypted Sensitive Data

Today’s post wraps up the Top 10 List with #10, Unencrypted Sensitive Data – At Rest and in Motion.

Encryption is an important part of housing sensitive data. Network traffic should also be encrypted to ensure that the passwords used to access sensitive, critical data cannot be seen by traffic. We’ve talked about how important it is to create strong passwords in our first post of the series, if they are visible to network traffic; it’s as bad as keeping your admin passwords set up or leaving a list of all your passwords on a post-it on your desk.

Any information that goes over the network or stored in the database should be encrypted and kept from prying eyes. Some network configurations and database management systems might allow for critical information to be sent in clear text. To ensure this doesn’t occur, make sure you have the latest version of software and turn off text indexing.

Digital warfare and worldwide cyberattack rates are on the rise, and protection on corporate networks is even more crucial.