Software Security - Vulnerability&Attack

Software Security Vulnerability AnalysisEmanuela Boroș

Emanuela Boroș

“Al. I. Cuza” University, Faculty of Computer Science

Master of Software Engineering, II

Page 1 /15


Table of Contents 1. Overview..........................................................................................................................................3

2. Web application vulnerabilities........................................................................................................3

a) Input Validation...........................................................................................................................7

3. SQL Injection...................................................................................................................................7

a) State-of-the-art.............................................................................................................................7

b) SQL Injection Example...............................................................................................................9

c) Protecting against SQL Injection...............................................................................................10

d) Java specific Protecting against SQL Injection..........................................................................11

6. SQL Injection Scanners..................................................................................................................13

a) Pangolin.....................................................................................................................................13

1. Database Support..............................................................................................................13

2. Sample use of Pangolin....................................................................................................13

b) GreenSQL.................................................................................................................................15

c) Add-ons for Firefox...................................................................................................................15

1. SQL Inject Me..................................................................................................................15

7. Bibliography...................................................................................................................................15

Page 2 /15


1. Overview

Every day, increasingly, organizations face security risks imposed upon them by attackers intent on achieving fame, glory, or profit. Attackers, familiar with common vulnerabilities inherent in many of today's websites, know how to exploit those vulnerabilities with attacks designed specifically to take advantage of them. 1 A vulnerability is a weakness in the application, which can be a design flaw or an implementation bug, that allows an attacker to cause harm to the stakeholders of an application. Stakeholders include the application owner, application users, and other entities that rely on the application. 2 In order to create an application that has a decreasing number of vulnerabilities it is needed a solid foundation for designing, building, and configuring secure web applications.

Number 1 in the Top 10 most critical web application security vulnerabilities3 identified by the Open Web Application Security Project (OWASP)4 is Injection Flaws. Injection happens whenever an attacker's data is able to modify a query or command sent to a database, LDAP server, operating system. Types of injections are SQL, LDAP, XPath, XSLT, HTML, XML, OS command. SQL injection and Cross-Site Scripting account for more than 80% of the vulnerabilities being discovered against web applications5 (SANS Top Cyber Security Risks6).

It's hard to believe, but SQL injection has been around for 13 years. SQL injection is as prevalent as ever as highlighted in The 2011 Mid-Year Top Cyber Security Risks Report7. In 1998 – 1999, Internet security was all about firewalls and SSL. Most people tend to think of security as a network problem. The truth: security is often a software problem.

2. Web application vulnerabilities

Hackers today have an ever increasing list of weaknesses in the web application structure at their disposal, which they can exploit to accomplish a wide variety of malicious tasks. New flaws in web application security measures are constantly being researched, both by hackers and by security professionals. Most of these flaws affect all dynamic web applications whilst others are dependent on specific application technologies. In both cases, one may observe how the evolution and refinement of web technologies also brings about new exploits which compromise sensitive databases, provide access to theoretically secure networks, and pose a threat to the daily operation of online businesses.

Based on data pulled from The Open Source Vulnerability Database (OSVDB)8, the total number of new vulnerabilities reported for the first half of 2011 is about 25% lower than the number of new vulnerabilities reported at mid-year 2010 and previous years. As of June 30, 2011, OSVDB cataloged 3,087 reported vulnerabilities in Internet-based

1 The 2011 Mid-Year Top Cyber Security Risks Report http://h20195.www2.hp.com/v2/GetPDF.aspx/4AA3-7045ENW.pdf

2 https://www.owasp.org/index.php/Category:Vulnerability3 https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project4 https://www.owasp.org/index.php/Main_Page5 http://weblogs.java.net/blog/caroljmcdonald/archive/2009/10/02/top-10-web-security-vulnerabilities-num-

ber-2-injection-flaws6 http://www.sans.org/top-cyber-security-risks/7 http://www.acunetix.com/blog/web-security-zone/articles/sql-injection-prevalent-hack/8 The Open Source Vulnerability Database, http://osvdb.org/

Page 3 /15


systems, applications, and other computing tools, as compared to 4,091 cataloged in the corresponding period in 2010.

After peaking in 2006, vulnerability reporting has been in a slow decline. The reasons for this decline are varied, but several likely reasons stand out. Software makers and system developers have increased their security awareness and have taken steps to reduce vulnerabilities prior to releasing their products. The second reason is a reduction in the disclosures of discovered vulnerabilities, motivated by a desire to instead sell the vulnerability for profit. Another is that some organizations would rather announce details regarding vulnerabilities only after they've been fixed.

Despite the overall decline in new vulnerabilities being discovered and reported, it is important to note that the ratio of vulnerabilities discovered in web applications still makes up 31% of all vulnerabilities disclosed. It is worth noting that roughly half of all vulnerability disclosures since 2006 have involved Web applications, so the downward trend for the first half of 2011 is yet another proof point for the overall drop in vulnerability disclosure thus far.

The reason for the high number of web application vulnerabilities is a matter of opportunity and profit. First, the number of web applications in circulation grows steadily every day. A web application in its simplest form ties together an operating system, a web server, a database, and some top-level application that customers use to interact with the back-end systems. Many organizations have adopted this model for interacting with customers through retail sites, online banking or finance applications, or even appointment scheduling. In addition, many organizations have confidential or sensitive data stored in the databases connected to these applications, offering an almost limitless field of opportunity for attackers, who view it all as a very lucrative proposition.

First of all, there has to be defined a set of application vulnerability categories in order to know what type of attacks can appear. There are common categories that span multiple technologies and components in a layered architecture. These categories are the focus for designing are building secure web applications. 9

9 Improving Web Application Security, Threats and Countermeasures, patterns & practices, Microsoft Corpor-ation, 2003

Page 4 /15


Category Description Threats

Input Validation

Input validation refers to how your application filters, scrubs, or rejects input before additional processing.

Buffer overflow; cross-site scripting; SQL injection

Authentication

Authentication is the process that an entity uses to identify another entity, typically through credentials such as a user name and password.

Network eavesdropping; brute force attacks; dictionary attacks; cookie replay; credential theft

Authorization

Authorization is the process that an application uses to control access to resources and operations.

Elevation of privilege; disclosure of confidential data; data tampering; luring attacks

Configuration

Management

Configuration management refers to how your application handles operational issues.

Unauthorized access to administration interfaces and to configuration stores; overprivileged process and service accounts

Sensitive Data

Sensitive data is information that must be protected either in memory, over the wire, or in persistent stores. Your application must have a process for handling sensitive data.

Access sensitive data in storage; network eavesdropping; data tampering

Session Management

A session refers to a series of related interactions between a user and your Web application. Session management refers to how your application handles and protects these interactions.

Session hijacking; session replay; man in the middle

Cryptography

Cryptography refers to how your application enforces confidentiality and integrity.

Poor key generation or key management; weak or custom encryption

Parameter

Manipulation

Form fields, query string arguments, and cookie values are frequently used as parameters for your application. Parameter manipulation refers to both how your application safeguards tampering of these values and how your application processes input parameters.

Query string manipulation; form field manipulation; cookie manipulation; HTTP header manipulation

Exception

Management

When a method call in your application fails, what does your application do? How much does it reveal about the failure condition?

Information disclosure; denial of service

Auditing and

Logging

Auditing and logging refer to how your application records security-related events.

User denies performing an operation; attacker exploits an application without trace; attacker covers his or her tracks

Page 5 /15


Web application vulnerabilities are easy to exploit with a variety of attack techniques and tools. When vulnerabilities are broken down by category, some interesting trends begin to emerge. Cross-Site Scripting (XSS) and SQL Injection (SQLi) still comprise the most significant amount of new Web application vulnerability disclosures10. XSS is commonly used for spam, phishing, and Web browser exploits. Buffer Overflow and Denial of Service (DoS) vulnerabilities round out the top four.

It is interesting to note that the breakdown of popular vulnerabilities by category remains fairly consistent over the past three years, likely because XSS vulnerabilities are relatively easy to find and are very useful to attackers. Spammers and phishers are always looking for ways to make their trade more profitable, and XSS continues to be a useful vulnerability for these purposes.

a) Input Validation

Input validation is a security issue if an attacker discovers that your application makes unfounded assumptions about the type, length, format, or range of input data. The attacker can then supply carefully crafted input that compromises your application. When network and host level entry points are fully secured; the public interfaces exposed by your application become the only source of attack. The input to your application is a means to both test your system and a way to execute code on an attacker’s behalf. Does your application blindly trust input? If it does, your application may be susceptible to the following11:

SQL injection

Buffer overflows

Cross-site scripting

10 The 2011 Mid-Year Top Cyber Security Risks Report http://h20195.www2.hp.com/v2/GetPDF.aspx/4AA3-7045ENW.pdf, pg.6

11 Improving Web Application Security, Threats and Countermeasures, patterns & practices, Microsoft Corpor-ation, 200, Chapter 2: Threats and Countermeasures, pg. 25-26

Page 6 /15


3. SQL Injection

Web applications are affected by multiple types of attacks, and SQLi and XSS are just two that have received a significant amount of media attention over the last few months. SQL injection is a vulnerability that allows an attacker to alter backend SQL statements by manipulating the user input. An SQL injection occurs when web applications accept user input that is directly placed into a SQL statement and doesn't properly filter out dangerous characters.

This is one of the most common application layer attacks currently being used on the Internet. Despite the fact that it is relatively easy to protect against, there is a large number of web applications vulnerable.

An attacker may execute arbitrary SQL statements on the vulnerable system. This may compromise the integrity of your database and/or expose sensitive information.

Depending on the back-end database in use, SQL injection vulnerabilities lead to varying levels of data/system access for the attacker. It may be possible to not only manipulate existing queries, but to UNION in arbitrary data, use subselects, or append additional queries. In some cases, it may be possible to read in or write out to files, or to execute shell commands on the underlying operating system. Certain SQL Servers such as Microsoft SQL Server contain stored and extended procedures (database server functions). If an attacker can obtain access to these procedures it may be possible to compromise the entire machine.

a) State-of-the-art

SQL Injection is an attack technique used to exploit applications that construct SQL statements from user-supplied input. When successful, the attacker is able to change the logic of SQL statements executed against the database.

Structured Query Language (SQL) is a specialized programming language for sending queries to databases. The SQL programming language is both an ANSI and an ISO standard, though many database products supporting SQL do so with proprietary extensions to the standard language. Applications often use user-supplied data to create SQL statements. If an application fails to properly construct SQL statements it is possible for an attacker to alter the statement structure and execute unplanned and potentially hostile commands. When such commands are executed, they do so under the context of the user specified by the application executing the statement. This capability allows attackers to gain control of all database resources accessible by that user, up to and including the ability to execute commands on the hosting system.

This is how SQLi attacks have evolved over the years:

1998 – Rain Forest Puppy (RFP) discloses/discusses the initial idea of SQL Injection in Phrack Magazine (Volume 9, Issue 54)

2000 – SQL Injection FAQ – Chip Andrews – uses the first public usage of term “SQL Injection” in a paper

2003 – The idea of blind SQL Injection is disclosed/discussed

2006 – Web application vulnerability disclosure skyrockets in part due to SQL Injection

2008 – SQL Injection vulnerability disclosure peaks

Page 7 /15


2008 – The Asprox botnet leverages SQL Injection for mass drive by SQLi attacks to grow botnet (http://en.wikipedia.org/wiki/Asprox). From at least April through August, a sweep of attacks began exploiting the SQL Injection vulnerabilities of Microsoft's IIS Web server and SQL Server database server. The attack does not require guessing the name of a table or column, and it corrupts all text columns in all tables in a single request. An HTML string that references a malware JavaScript file is appended to each value. When that database value is later displayed to a website visitor, the script attempts several approaches at gaining control over a visitor's system. The number of exploited Web pages is estimated at 500,000.

On August 17, 2009, the U.S. Justice Department charged an American citizen Albert Gonzalez and two unnamed Russians with the theft of 130 million credit card numbers using a SQL Injection attack. In reportedly “the biggest case of identity theft in American history,” the man stole cards from a number of corporate victims after researching their payment processing systems. Among the companies hit were credit card processor Heartland Payment Systems, convenience store chain 7-Eleven, and supermarket chain Hannaford Brothers.

On February 5, 2011, HBGary, a technology security firm, was broken into by Anonymous using a SQL Injection in their CMS-driven website.

On April 11, 2011, Barracuda Networks was compromised using a SQL Injection flaw. Email addresses and usernames of employees were among the information obtained.

On June 1, 2011, “hacktivists” of the group LulzSec were accused of using SQLi to steal coupons and to download keys and passwords that were stored in plaintext on Sony's website, accessing the personal information of a million users.

In June 2011, Group Anonymous claims to have hacked the NATO site, using a “simple SQL Injection”. With SQLi attacks, it is readily apparent that attackers are content leveraging existing vulnerabilities for their exploits.

b) SQL Injection Example

1. use of string concatenation to build query: SQL Injection can happen with dynamic database queries concatenated with user supplied input, for example with the following query:

"SELECT * FROM tableName WHERE name =" + parameter;"

2. if the user supplies "name' OR 'a'='a' " as the parameter it results in the following:

"SELECT * FROM tableName WHERE name ='name' OR 'a'='a';"

3. the OR 'a'='a' causes the where clause to always be true which is the equivalent of the following:"SELECT * FROM tableName;"

Page 8 /15

http://en.wikipedia.org/wiki/Asprox


4. if the user supplies "name' OR 'a'='a' ; DELETE FROM tableName" as the parameter it results in the following:

"SELECT * FROM tableName WHERE name ='name' OR 'a'='a'; DELETE FROM tableName;"

5. the OR 'a'='a' causes the WHERE clause to always be true which is the equivalent of the following:

"SELECT * FROM tableName; DELETE FROM tableName;"

6. some database servers, allow multiple SQL statements separated by semicolons to be executed at once.

c) Protecting against SQL Injection

SQL Injection arises from an attacker's manipulation of query data to modify query logic. The best method of preventing SQL Injection attacks is, therefore, to separate the logic of a query from its data; this will prevent commands inserted from user input from being executed. The downside of this approach is that it can have an impact on performance and that each query on the site must be structured in this method for it to be completely effective. If one query is inadvertently bypassed, that could be enough to leave the application vulnerable to SQL Injection.

These are some tips in order to protect your system from SQL injection:

Don't concatenate user input data to a query or commandUse Query Parameter binding with typed parameters, this ensures the input data

can only be interpreted as the value for the intended parameter so the attacker can not change the intent of a query

Validate all input data to the application using white list (what is allowed) for type, format, length, range, reject if invalid

Don't provide too much information in error messages (like SQL Exception Information, table names) to the user.

Page 9 /15


The following code shows a sample SQL statement that is SQL injectable.

sqlStatement = "SELECT * FROM tableName";sqlStatement = sqlStatement + "WHERE id =" + id;oCmd.CommandText = sqlStatement;

The following example utilizes parameterized queries and is safe from SQL Injection attacks.

sqlStatement = "SELECT * FROM tableName";sqlStatement = sqlStatement + "WHERE id = id;oCmd.CommandText = sqlStatement;oCmd.Parameters.Add("id", id);

The application will send the SQL statement to the server without including the user's input. Instead, a parameter – id – is used as a placeholder for that input. In this way, user input never becomes part of the command that SQL executes. Any input that an attacker inserts will be effectively negated. An error would still be generated, but it would be a simple data-type conversion error, and not something that a hacker could exploit.

d) Java specific Protecting against SQL Injection

4. Don't concatenate user input data to a query or command:

Don't do this with JDBC:

String id = req.getParameter("id");String query = "SELECT * FROM tableName WHERE id = '" + id +"'";

Don't do this with JPA:

query = entityManager.createQuery("SELECT * FROM tableName t WHERE " + "t.id = '" + id + "'");

Page 10 /15


5. Use Query Parameter binding with typed parameters

With JDBC you should use a PreparedStatement and set values by calling one of the setXXX methods on the PreparedStatement object

String sql = "SELECT * FROM tableName WHERE id = ? ";PreparedStatement pStmt = con.prepareStatement(sql);pStmt.setString(1, id);

This sets the first question mark placeholder to the value of the input parameter id in the SQL command. Any dangerous characters – such as semicolons, quotes, etc.. should be automatically escaped by the JDBC driver.

With JPA or Hibernate you should use Named Parameters. Named parameters are parameters in a query that are prefixed with a colon (:). Named parameters in a query are bound to an argument by the javax.persistence.Query.setParameter(String name, Object value) method. For example:

query = entityManager.createQuery("SELECT e FROM tableName t WHERE " + "t.id = ':id'");q.setParameter("id", id);

This sets the id to the id in the SQL command, again any dangerous characters should be automatically escaped by the JDBC driver.

With JPA 2.0 or Hibernate you can use the Criteria API. The JPA 2.0 criteria API providies a typesafe object-based Query API based on a metamodel of the Entity classes, rather than a string-based Query API. This allows you to develop queries that a Java compiler can verify for correctness at compile time. Below is an example using the Criteria API for the same query as before :

QueryBuilder qb = em.getQueryBuilder();CriteriaQuery<Employee> q = qb.createQuery(TableName.class);Root<TableName> t = q.from(TableName .class); ParameterExpression<String> id = cb.parameter(String.class);

TypedQuery<TableName> query = em.createQuery(q.select(t).where(cb.equal(t.get(TableName_.id), id) );query.setParameter(“id”, id);

6. SQL Injection Scanners

a) Pangolin

Pangolin is an automatic SQL injection penetration testing tool developed by NOSEC. Its goal is to detect and take advantage of SQL injection vulnerabilities on web applications. Once it detects one or more SQL injections on the target host, the user can choose among a variety of options to perform an extensive back-end database management system fingerprint, retrieve DBMS session user and database, enumerate users, password hashes, privileges, databases, dump entire or user’s specific DBMS tables/columns, run his own SQL statement, read specific files on the file system and more.

Page 11 /15


1. Database Support

Access: (Database Path; Root Path; Drivers); Data

MSSql: Data; FileReader; RegReader; FileWriter; Cmd; DirTree

MySql: Data; FileReader; FileWriter

Oracle: Version; IP; Database; Accounts, Data

DB2: Data

Sybase: Data

PostgreSQL: Data; FileReader

Sqlite: Data

At present, most of the functions are directed at MSSQL and MySql coupled with Oracle and Access. Other small and medium-sized companies are using DB2, Sybase, PostgreSQL, as well as Sqlite which isn't so common.

2. Sample use of Pangolin

Run Pangolin then type or paste the URL that you suspect is susceptible to SQL injection.

Page 12 /15


Page 13 /15


b) GreenSQL

GreenSQL is a Database Security solution. GreenSQL is an Open Source database firewall used to protect databases from SQL injection attacks. It works as a proxy and has built in support for MySQL and PostgreSQL. The logic is based on evaluation of SQL commands using a risk scoring matrix as well as blocking known db administrative commands (DROP, CREATE, etc).

Sample page protected by GreenSql at http://www.greensql.net/sql-injection-test

Page 14 /15


c) Add-ons for Firefox

Security Compass with:

1. SQL Inject Me

SQL Injection vulnerabilities can cause a lot of damage to a web application. A malicious user can possibly view records, delete records, drop tables or gain access to your server. SQL Inject-Me is Firefox Extension used to test for SQL Injection vulnerabilities (not available for Firefox 8.0).

7. Bibliography[The 2011 Mid-Year Top Cyber Security Risks Report, Article, HP DVLabs, HP teams: Fortify and the Application Security Center, Hewlett-Packard Development Company, L.P, September 2011, http://h20195.www2.hp.com/v2/GetPDF.aspx/4AA3-7045ENW.pdf]

[Open Web Application Security Project (OWASP), OWASP Foundation, last modified on 11 October 2011, https://www.owasp.org/]

[Java.net, 2011, Oracle, http://weblogs.java.net/blog/caroljmcdonald/archive/2009/10/02/top-10-web-security-vulnerabilities-number-2-injection-flaws]

[SANS Information Security & Research, SANS Institute, September 2009, http://www.sans.org/top-cyber-security-risks/]

[Acunetix, Acunetix Web Vulnerability Scanner, 2011, http://www.acunetix.com/blog/web-security-zone/articles/sql-injection-prevalent-hack/]

[Open Source Vulnerability Database (OSVDB), 2011, http://osvdb.org/]

[Improving Web Application Security, Threats and Countermeasures, patterns & practices, Microsoft Corporation, Microsoft Corporation, 2003, http://msdn.microsoft.com/en-us/library/ff649874.aspx]

Page 15 /15

http://msdn.microsoft.com/en-us/library/ff649874.aspx

http://msdn.microsoft.com/en-us/library/ff649874.aspx

http://osvdb.org/

http://www.acunetix.com/blog/web-security-zone/articles/sql-injection-prevalent-hack/

http://www.acunetix.com/blog/web-security-zone/articles/sql-injection-prevalent-hack/

http://www.sans.org/top-cyber-security-risks/

http://weblogs.java.net/blog/caroljmcdonald/archive/2009/10/02/top-10-web-security-vulnerabilities-number-2-injection-flaws

http://weblogs.java.net/blog/caroljmcdonald/archive/2009/10/02/top-10-web-security-vulnerabilities-number-2-injection-flaws

https://www.owasp.org/

http://h20195.www2.hp.com/v2/GetPDF.aspx/4AA3-7045ENW.pdf

Technology

Software Security - Vulnerability&Attack