Transcript Lecture 20 - The University of Texas at Dallas

Data and Applications Security
Dr. Bhavani Thuraisingham
The University of Texas at Dallas
Attacks to Databases
March 2012
Outline of the Unit
 1. Brute-force (or not) cracking of weak or default
usernames/passwords
 2. Privilege escalation
 3. Exploiting unused and unnecessary database services and
functionality
 4. Targeting unpatched database vulnerabilities
 5. Stolen backup (unencrypted) tapes
 6. SQL injection
 http://www.darkreading.com/security/encryption/211201064/index.ht
ml
Brute-force (or not) cracking of weak or
default usernames/passwords
 Older versions of Oracle and others database systems used well
known default passwords
 New versions have changed this practice and don’t allow database
systems to keep default passwords
 Even unique, non-default database passwords aren’t hacker-safe –
with Bruce Force attacks and password cracking tools
 Steer clear of default passwords, and institute tight password
management and regular change-ups.
Privilege Escalation
 There have been several insider attacks that came as a result of a
malicious user possessing more system privileges than he or she
should have had.
 Outside attackers sometimes have higher-level privileges by
compromising the operating system.
 Privilege escalation usually has more to do with misconfiguration: A
user is mistakenly granted more access and privileges on the
database or related applications than he actually needs to do his job.
 Sometimes an inside attacker (or an outsider who has taken over a
victim’s machine) can go from one application to the database, even
if he doesn't have database credentials.
 Solution: Give users only the access and rights they need on the
database, nothing more
Exploiting unused and unnecessary database
services and functionality
 One of the first things an outside attacker will look for is whether his
potential victim is running the Listener feature on its Oracle
database. Listener seeks out and forwards network connections to
the Oracle database, and thus can expose users and database links.
 Via Google, an attacker can search and find exposed Listener
services on databases.
 Other features, such as hooks between operating systems and the
database, can leave the database exposed to an attack. Such a hook
can become a communications link to the database.
 Often, database administrators run too many services and services
may be open up to vulnerabilities
 Solution: Install only the database features you need.
Targeting unpatched database vulnerabilities
 Oracle and other database vendors patch their vulnerabilities.
However difficult for organizations to keep up with the patches
 Database vendors are careful not to disclose many details about the
vulnerabilities and their patches fix so that attackers are not notified
 Some hacker sites post exploit scripts for known database
vulnerabilities
 Solution: Organizations must be vigilant about installing patches in
a timely manner.
Stolen backup (unencrypted) tapes
 If the database data on the stolen are not encrypted and the tapes
get into the wrong hands then there is a huge problem
 But this type of attack is more likely to occur with an insider selling
the media to an attacker.
 Solution: Encrypt the critical data. Use a safe for sensitive database
tapes
SQL Injection
 SQL injection attacks occur where the fields available for user input
let SQL statements through to query the database directly.
 Outside of the client, Web applications typically are the weakest link.
In some cases, if the attacker gets a screen on the application for
username and password, all he has to do is provide a SQL statement
or database command and that goes directly to the database
 If the application does not examine the content of the logon. “The
problem is that the authentication and authorization has been moved
to the application server.
 Now instead of a user name, it is a SQL command put into a packet
and sent by the application server to the database.
 The database reads the SQL command, and it could shut down a
database altogether
SQL Injection
 Solution is to look at the content the user is providing.
 SQL injection attacks can occur both from the Web application to the
database, and from within the database itself.
 There are some programming practices that help prevent SQL
injection flaws in applications, such as using what are called “bind
variables,” or parameters for queries.
 In languages such as Java, that means using question marks as
placeholders in the SQL statement and binding the “received”
values to those placeholders
 Another practice is to avoid displaying certain database error
messages to avoid giving away potentially sensitive information to a
would-be attacker
SQL Injection
 Conasier ing a very simple web application that processes customer
orders. Suppose Acme Widgets has a simple page for existing
customers where they simply enter their customer number to
retrieve all of their current order information. The page itself might
be a basic HTML form that contains a textbox called
CustomerNumber and a submit button. When the form is submitted,
the following SQL query is executed:
SELECT *
FROM Orders
WHERE CustomerNumber = CustomerNumber
The results of this query are then displayed on the results page.
During a normal customer inquiry, this form works quite well.
SQL Injection
 Suppose John visits the page and enters his customer ID (14). The
following query would retrieve his results:
SELECT *
FROM Orders
WHERE CustomerNumber = 14
However, the same code can be a dangerous weapon in the hands of
a malicious user. Imagine that Mal comes along and enters the
following data in the CustomerNumber field: “14; DROP TABLE
Orders”. This would cause the following query to execute:
SELECT *
FROM Orders
WHERE CustomerNumber = 14; DROP TABLE Orders
SQL Injection
Solutions: Implement parameter checking on all applications. For
example, if you’re asking someone to enter a customer number,
make sure the input is numeric before executing the query. You may
wish to go a step further and perform additional checks to ensure
the customer number is the proper length, valid,
 Limit the permissions of the account that executes SQL queries. The
rule of least privilege applies. If the account used to execute the
query doesn’t have permission to drop tables, the table dropping will
not succeed!
 Use stored procedures (or similar techniques) to prevent users from
directly interacting with SQL code.
 As with many security principles, an ounce of prevention is worth a
pound of cure. Take the time to verify the code running on your
servers