Malicious File Execution

Photo: TCM Hitchhiker

Photo: TCM Hitchhiker

This is the third-part in a ten-part-series describing the OWASP Top 10. (See all the OWASP Top 10)

What is Malicious File Execution

Some web applications allow the user to specify input that is used directly into file streams or allows the user to upload files to the server. At a later time the web application accesses the user supplied input in the web applications context. By doing this, the web application is allowing the potential for malicious file execution.

When an application allows user to modify file streams, the application is trusting the user to operate within certain “rules” and may assume the user won’t break these rules.

If there aren’t preventions in place, an attacker can exploit the rules by attempting to include files stored on remote or local file systems.

Web applications that are vulnerable to malicious file execution break the simple security rule of trusting user input.

Allowing malicious file execution to exist in a web application can lead to the complete compromise of the server.

Examples of Malicious File Execution

Typical examples of malicious file execution are remote file includes and local file includes. Most people think of these as PHP functions, however, that does not mean an ASP or JSP server isn’t susceptible to malicious file execution vulnerabilities.

Here is a common example, Imagine the PHP function:

include $_REQUEST['filename'];

An attacker can then specify a file name of a remote URL that they control, say http://evilhacker.com/attack.php

How Do You Prevent Malicious File Execution

Malicious file execution needs to be prevented from the design stage. If the design stage of the web application has already been completed, then extra precaution needs to be taken.

Developers need to pay particular attention to code access security mechanisms to ensure that file names supplied by or influenced by the user do not allow security controls to be obviated.

Web applications should not allow users to insert input into a server-based resource. However, if the ability is needed, then developers need to be extra cautious about what input they accept. Developers should insure that file names supplied by the user do not allow security controls to be bypassed.

General preventions that can be taken include:

  • Strongly Validating user input using an only “accept known good” input.
  • Adding firewall rules that prevent web servers from making new connections to external websites will aid in preventing remote file include vulnerabilities.
  • Implementing a sandbox to isolate applications from one another.

Depending on your environment, specific preventions can also be taken. For instance, with J2EE developers should ensure that the security manager is enabled and properly configured. More information about specific environment preventions can be found at OWASP’s full article on malicious file execution.

Advertisements

BlackHat USA 2009 – Day 2

Photo: Stephan Geyer

Photo: Stephan Geyer

This is the second in a two-part-series on BlackHat USA 2009. (Part 1)

As we stepped into the taxi the driver asked us, “Where To?”

“Caesar’s Palace.” I said.

“What are you guys in town for?” He said to the four of us in back seat of his cab.

“BlackHat.”

“You guys are the hackers?!”

“Yes, We are ‘the’ hackers.”

“I talked to some of you last year. They told me  they could listen to my typing and blow up my computer! How are they able to do that?”

“They do that, using the Asparagus attack. As long as you don’t eat asparagus you will be fine.”

This is a conversation that a few of us had with a taxi driver last year while we were in Las Vegas attending BlackHat. If you happen to get this taxi driver. Please explain the Asparagus Attack. He was full of questions regarding how it is done.

We are now on to Day 2. The hangover should be maintainable enough to see the following talks:

Day 2 – Thursday – July 30th

[10:00am] Zane Lackey linkedin , Luis Miras Luis Miras on LinkedIn

Attacking SMS

[~10:30am] Kevin Stadmeyer linkedin, Garrett Held Garrett Held on LinkedIn

Worst of the Best of the Best

[11:15am] Jeremiah Grossman twitter, Trey Ford Trey Ford on LinkedIn

Mo’ Money Mo’ Problems: Making A LOT More Money on the Web the Black Hat Way

[1:45pm] Haroon Meer twitter, Nick Arvanitis Nicholas Arvanitis on LinkedIn, Marco Slaviero Marco Slaviero on LinkedIn

Clobbering the Cloud!

[~2:15pm] Tony Flick Tony Flick on LinkedIn

Hacking the Smart Grid

[~3:45pm] Peter Guerra Peter Guerra on LinkedIn

How Economics and Information Security Affects Cyber Crime and What It Means in the Context of a Global Recession

[4:45pm] Panel Discussion

A Black Hat Vulnerability Risk Assessment


Blackhat USA 2009 – Day 1

Photo: Roadsidepictures

This is the first in a three-part-series on BlackHat USA 2009. (part 2)

A dark cloud is about to approach Las Vegas. The city of sin will soon get cold sweats at night when they realize what is approaching. At the end of July, Las Vegas will be pounced upon by hundreds of security professionals at the annual BlackHat convention.

BlackHat is the most well known computer and Internet security conference in the world. I always have a hard time deciding what talks to go see. I typically end up flagging way too many talks, and get burned out rather quickly. In addition, there are the security booze-hounds/gamblers that are very persuading in swaying you away from the talks.

This year, I thought I would try something different. I am listing the talks I want to see on this blog in an attempt to make sure I show up to them. We will see if this happens.

Day 1 – Wednesday – July 29th

[10:00am] Rod Beckstrom Rod Beckstrom on Twitter

Beckstrom’s Law: A Model for Valuing Networks and Security

[11:15am] Nathan Hamiel , Shawn Moyer

Weaponizing the Web: More Attacks on User-Generated Content

[1:45pm] Nitesh Dhanjani Nitesh Dhanjani on Twitter

Recoverable Advanced Metering Infrastructure / Psychotronica

[3:15pm] Mark Dowd , Ryan Smith , David Dewey

The Language of Trust: Exploiting Trust Relationships in Active Content

[4:45pm] Thomas H. Ptacek , David Goldsmith , Jeremy Rauch

Hacking Capitalism ’09: Vulnerabilities In Markets And Trading Platforms

[6:00pm] The Pwnie Awards


Injection Flaws

http://www.flickr.com/photos/justin_case/

Photo: Justin_Case

This is the second-part in a ten-part-series describing the OWASP Top 10. (See all the OWASP Top 10)

What are Injection Flaws

Injection flaws are a class of security vulnerability that allows a user to “break out” of the web application context. If your web application takes user input and inserts that user input into a back-end database, shell command, or operating system call, your application may be susceptible to an injection flaw.

A user exploits this by breaking out of the intended “context” and appends additional and often unintended functionality. By allowing injection flaws in your application you are allowing an attacker to create, read, update, or delete any arbitrary data available to the application.

Examples of Injection Flaws

There are many types of injection flaws. The most common being SQL injection. In addition there is LDAP injection, XML Injection, XPath Injection, OS command injection, and HTML injection. Injection flaws however are not limited to just these. If your web application inserts user input into any interpreter or process, your web application can contain these vulnerabilities. You can see an example of how an injection flaw works here.

How Do You Prevent Injection Flaws

Before calling an external function, verify that the data is what you expect. This is referred to as validation. For instance, if you expect your function to be passed a string that contains a user’s first name, should it contain any special characters? John is a valid name. But, J<o>hn isn’t. Both user names need to be ran through a validation function and in order for the web application to determine whether the data is what the developer expects.

There are certain exceptions however that can get you in trouble. Single Quotes (‘) are valid characters in people’s last names. However, if you allow a single quote in a last name field, you can be introducing SQL injection into your application.

In cases where you need to allow a single quote (‘), in addition to validation, you should also sanitize (encode) the input. Sanitizing the input is determining a way that the input can be transformed into “non-threatening” data. This needs to be done on a case by case basis.

For example, If you understand that the sanitized data will always be returned in a browser, you could simple HTML encode or URL encode the string. A quote becomes, ' (HTML encoding) or %27 (URL encoding).

When sanitizing input, it is important to make sure you decode the string before it is displayed to the user. It can be embarrassing if John O’Brien’s name is printed as: Tim O%27Brien

SQL Injection – Primer

Photo: XKCD

Photo: XKCD

SQL Injection is an injection flaw where a web application allows a user to send un-sanitized input into a SQL query.

The textbook example is that a web application has a username field that inserts the user’s input into the following SQL query:

statement = "SELECT * FROM users WHERE name = '" + userName + "';"

The user then types a' or '1'='1 into the username field. This creates the following SQL statement:

SELECT * FROM users WHERE name = 'a' or '1'='1'

If the statement variable is used for the authentication procedure then the evaluation of the SQL statement will always be true.

An attacker can cause damage if they appended something like, '; DROP TABLE users;--

This would produce the following SQL statement:

statement = "SELECT * FROM users WHERE name = ''; DROP TABLE users;--';

Which would result in the users table being deleted from the Database.

OWASP Top 10


When developing a security strategy for web applications many companies have no idea where to begin. The Open Web Application Security Project (OWASP) understood this problem and developed the OWASP Top 10.

The OWASP top 10 are the top 10 vulnerabilities that are found in web applications. This will begin a 10-part series dedicated to each of these vulnerabilities.

If you are a developer, you should understand these vulnerabilities. Understanding them is critical into introducing less vulnerabilities into your code.

The OWASP Top 10:
A1 – Cross Site Scripting (XSS)
A2 – Injection Flaws
A3 – Malicious File Execution
A4 – Insecure Direct Object Reference
A5 – Cross Site Request Forgery (CSRF)
A6 – Information Leakage and Improper Error Handling
A7 – Broken Authentication and Session Management
A8 – Insecure Cryptographic Storage
A9 – Insecure Communications
A10 – Failure to Restrict URL Access

Don’t Click That Link!

Photo: B.G. Lewandowski

Photo: B.G. Lewandowski

Why did you just click that link? Most likely you have came to this site by clicking a link from another site. Why did you do that? Did you trust the person who sent you the link? Did you click a link from Twitter, Facebook, or an email someone sent you?

When you click a link, you are telling your browser, “I trust this person.” However, this is not the way we use the Internet. We click on links all the time. We click on links from “untrusted” sources. We click links from people we don’t know and we even click on URL’s that have been modified. On Twitter, a person is much more inclined to click the shortened link http://bit.ly/5hXRW then they are to click http://somewherebank.com/transfer.jsp?amount=1000&to_account=56777564. Even though the shortened link could redirect to the somwherebank.com site.

But, why would someone trick you into clicking a cleverly disguised link? The site that you are redirected to may seem harmless. It could also be extremely malicious.

What happens if this page, (the one you are currently viewing), was filled with Cross-Site Request Forgery (CSRF) links? This web page could be setup with all types of malicious intent. However, you didn’t know that when clicking the link. Now, it is too late.

If this site did have Cross-Site Requests, I could do things such as:

  • Change the password on your Facebook account
  • Transfer the money from your on-line bank account to another account
  • Enact trades from a financial institution such as E*Trade

The sites that I exploit would have to be vulnerable to CSRF. But researchers, such as Mike Bailey and Russ McRee, are constantly finding CSRF vulnerabilities in web applications.

An example of how clicking links from untrusted sources is never good was demonstrated in Billy Rios and Nitesh Dhanjani, Bad Sushi talk. In their presentation they described sending phishers a word document stating their account numbers were inside. They sent this email to 25 known phishers. 10 of the phishers opened the word document and were presented with this. In addition, there was another link that said, “Actually, my account information is here.” 3 of the 10 clicked on that link. Even the phishers click links they shouldn’t.

What should be done? Who knows. It is human nature to trust people and we can’t get things done if every time someone sends us a link we open up a VMware image to view a link. So continue using the Internet the way you have been and remember, “These aren’t the droids your looking for.”