In an Effort to "Protect Us," Big Companies are Making Us More Insecure

One of the provisions of the oft-talked about SOPA (Stop Online Piracy Act) was (until yesterday when Lamar Smith was convinced to remove it) DNS editing to prevent access by American ISP subscribers to  foreign websites. Essentially, while the US does not have authority to physically remove a foreign site (at least theoretically), they can force US-based ISPs to block their domain name in the domain name resolution system, preventing people from accessing "somebadsite.com" and instead forcing them to use the archaic system of IP addresses. One of the biggest warnings from technology and security experts that came out of this provision was that people were going to begin using rogue DNS servers to access their content. News of how to bypass SOPA DNS restrictions would spread like wildfire, and soon, torrent-loving Americans everywhere would be using foreign-based, non-authoritative DNS servers to access content blocked under SOPA. This is a major security risk. It's something I think our elected leaders certainly failed to recognize (at least until recently). But it got make thinking of an entire market of services and applications where people are forced, because of the government or big-company regulations, to access the content they want in less-than-secure ways.

Rogue DNS servers are not a terrible problem at the moment. They certainly exist, but due to the current freedom and openness of the web, people are rarely forced to search for or even concern themselves with them. Under SOPA, this would certainly change. But today, millions of people are constantly bypassing security mechanisms elsewhere, and it is having a huge impact on the security of their devices. Think for a moment of smartphones like Android or the iPhone and the Market and App Store that accompany them. Many wireless providers like Verizon, AT&T, and T-Mobile have a fair amount of control over the applications that can be downloaded onto their phones from those app markets. This fact has been highlighted recently as tethering applications are continually yanked from the Market. It's quite clear; the carriers do not want those kinds of applications to be used on their networks. But in reality, do you think the average user looking to use a tethering app is just going to... give up when it can't be found in the Market?

Search Google for "tethering apps" and you will receive millions of hits. Almost every one of those hits includes links to APKs for tethering applications, the Android version of a .exe that allows the program to be installed on the device, bypassing the Market. These links usually include instructions on how to "side-load" the application. Side-loading is definitely a useful feature; developers use it constantly and it allows users to install applications otherwise blocked by the carriers. However, therein lies the security risk. The average consumer has no idea what side-loading is; they see it as a necessary step to get an app they want.   They have been trained to leave the protection (or quasi-protection) that the Market or App Store provides and instead search for the applications they want elsewhere. In an effort to prevent their customers from accessing blocked content, Verizon, AT&T, and other carriers have just taught their users to download the applications from a less-secure source. Anyone can upload an APK that does anything. If a consumer finds out that by simply Jailbreaking his iPhone, he can access all the Apps he wants, why wouldn't he, especially when all he has to do these days is visit a single website to auto-jailbreak the device?

This issue extends beyond just phones. People continually visit questionable, foreign-hosted sites to find TV shows, movies, music, etc. all because there is no legal, simple alternative. The RIAA and MPAA have a tight grip on the industry, but that grip is forcing people to turn to piracy and at the same time, insecure, often shady websites. The trend has become "if I can't do it legally or through my provider, search Google and blindly follow the instructions." This is bad. We have finally gotten to the point where most people are somewhat aware of banking scams, etc. But tell someone that they can watch the NFL online for free and they'll follow any steps necessary, including downloading malicious programs.

The point here is that such strict regulation by companies like Verizon, AT&T, Universal, etc., not only forces people into piracy, but also into insecure lifestyles, if you will. They are unknowingly trained by these companies to find round-about ways of getting what they want with little or no thought to the security implications involved. You may not "download a car," but I can guarantee that if you label a virus "car," someone, somewhere will download it.

Chrome Extension for Easy XSS Insertion

I decided to venture into the world of Chrome extension-making this week. Surprisingly, it was extremely simple to make a basic extension. Getting the extension to interact with the actual code on the page (such as getting the element ID, etc.) was a bit more difficult, but only took a few hours to get working.

Before I could create an extension, I needed an idea. So I decided to make an XSS, mySQL injection snippet manager. It's a fairly basic, but potentially useful little extension that adds a menu to Chrome's right-click context menu. When a user right clicks on a text box, the menu appears, allowing the user to select from a variety of popular XSS attack scripts. When they click one, it's added to the text box and the user can then submit the form and see if the site is vulnerable.

I am only advocating the use of this extension for testing web applications that you own. Do not use this on any other sites. Most of the XSS scripts come from http://ha.ckers.org/xss.html (with permission), an excellent XSS resource.

Download Link: http://matthewdfuller.com/content/WebSec_Toolbox_Chrome_Extension.crx

GitHub Source: https://github.com/matthewdfuller/WebSec-Toolbox-Chrome-Extension

Screenshot:

I Need a Project...

[Note: This post is just a brainstorm session. I apologize for the run-on sentences and possibly confusing flow, but I wanted to just pour out my ideas in the exact manner in which I think.]

I'm back from Fall break and getting ready to dive back into classes here at RIT for the Winter. I'll be taking classes in Wireless Networking, Databases, Computer Crime, and Sociology. I'm looking forward to a great quarter, but at the same time, I need a project. Not something for school, just a regular personal project. I'm still continuing to learn a lot about web application firewalls, and I'm thinking something along those lines, but maybe from a different approach. Brainstorming now:

I've been working on a number of Perl scripts for competition-based hack and defend scenarios. Scripts that lock users out, watch for un-authorized users to a system, etc. I can keep doing that, but I need a more detailed project.

I need to improve my PHP skills. I'm thinking about a vulnerable web app that teaches exploitation. That way it will help me, since I need to code the site and purposefully add vulnerabilities, and then I can secure it with a WAF when I'm done. But Damn Vulnerable Web App already exists. But it's not that detailed, only a few pages and very basic exploits. I'm thinking of something that can be more of a learning experience, something with step-by-step walkthroughs and demos of exploitable security flaws. It should also show the code/techniques necessary to protect against that vulnerability as well. I like this idea. 

I'm trying to think of other ideas, but I keep coming back to a vulnerable web app / tutorial / teaching guide. There really needs to be a good, solid guide to web application vulnerabilities that lets the user see exactly what is happening. I think I'm going to run with this. To the drawing board!

Mod Security Presentation

I will be giving a presentation on Friday at SPARSA (RIT's Computer Security Club). I will be talking about my experiences so far using ModSecurity and how it can be used to secure web applications. For a preview of my presentation, check out the Google Doc Presentation below:

 

Working with Web Vulnerabilities and Web Application Firewalls [Part 5 - Mod Security]

[Note: this is part five of a multi-part series of posts detailing my experiences with securing web applications, creating test environments for practicing and installing and operating a web application firewall. Web security is an extremely important part of IT security since almost every major organization has a "web face." I will be exploring XSS, mySQL injection, and the use of web application firewalls to protect against these attacks.]

When we last left off in the series, I was demonstrating that Damn Vulnerable Web App is actually... vulnerable. But now it's time to move on and actually detect (and stop) hacking attacks through the use of a web application firewall known as Mod Security.

Intro to Mod Security

Mod Security is essentially a firewall module that can be added to an Apache web server to help detect, filter, and even block web attacks. It uses a complex set of rules based on signatures and regular expressions to determine whether or not a particular input is malicious. Unlike a traditional firewall, which merely analyzes source/destination addresses and perhaps port numbers or services, Mod Security is able to analyze the HTTP traffic that is passing over port 80 to the web server and determine the exact payload. This is extremely important because it enables us to block attacks that are entirely web-based.

Installation

Before installing mod_security, make sure you stop your server by running:

service httpd stop

Mod Security can be downloaded from http://modsecurity.org/download however, the simplest method is to issue:

 yum install mod_security

Mod Security has a default set of rules and pattern matching techniques that it uses to detect attacks. For right now, we will be using the default rules. Hopefully in a future addition to this series I will delve more into the intricate settings to create a custom-tailored firewall. For now, I'll demonstrate Mod Security's features out-of-the-box.

Testing

Restart your Apache server:

service httpd start

And now, return to your DVWA homepage and login. For this demo, I will be attempting the same SQL injection attack that was performed in part four of this series. Watch what happens this time...

Remember from before that the attack had succeeded, returning a list of every user account in the system. From a security standpoint, it's pretty obvious that the page you see above is a much-preferred response to an attack.

The Logs

Mod Security is extremely useful because, as shown above, it blocked the attack from occurring. However, it's also great to have logs of which events were blocked. Luckily, Mod Security does that as well.

The logs are stored in /var/log/httpd/modsec_audit.log. Looking at the logs immediately after attempting our OR '1' = '1 attack, the following log is shown:

This log message reveals why our attack was stopped. The attack matched a pattern that was outlined in the mySQL injection ruleset. The log entry also details the response that Mod Security took - in this case, displaying a 403 access denied error.

More to Come!

This example only scratches the surface (and barely, at that) of what Mod Security can do. The configuration and rules can be changed and modified as needed to fit the needs of any web application. I hope to explore a lot more of the functionality behind Mod Security and perhaps write some custom rules. Stay tuned!

Working with Web Vulnerabilities and Web Application Firewalls [Part 4 - Basic Exploitation]

[Note: this is part four of a multi-part series of posts detailing my experiences with securing web applications, creating test environments for practicing and installing and operating a web application firewall. Web security is an extremely important part of IT security since almost every major organization has a "web face." I will be exploring XSS, mySQL injection, and the use of web application firewalls to protect against these attacks.]

There are hundreds of ways to exploit a web application. Users can upload invalid file types to an app that doesn't check the file type, they can inject code into the pages, as well as retrieve data from a database that should not be retrieved. The focus of this series is mainly on using a web application firewall to prevent against attacks, so I will not be explaining every attack type with examples. However, I will be focusing on two injection attacks here that will demonstrate that the web application is vulnerable before I use a web application firewall to block those attacks. I will be giving basic examples of cross site scripting and mySQL injection.

Cross Site Scripting (XSS)

The first attack type I am going to attempt on our web application is cross site scripting. However, we must first understand what cross site scripting is and how it can be used against a web app. Remember in part one of this series, I mentioned that most web vulnerabilities come from users entering input that is not valid and that could contain malicious code. Cross site scripting takes advantage of the fact that a fair amount of web pages and applications fail to "sanitize" user input. Take a look at the following PHP code:

echo <pre>Hello $_GET['name']</pre>;

This code gets a variable called "name" and prints it out directly within the page as HTML code. The echo statement prints whatever follows it into the HTML code of the page. If we pass in the name "Robert," the following is reflected onto the page to the user:

Hello Robert

However, suppose we replace Robert with JavaScript code? We type the following into the name box:

 <script>alert('Hello')</script>

Now, the code we just typed is reflected into the actual code of the page as it is displayed.

echo <pre>Hello <script>alert('Hello')</script></pre>

This will cause an alert box to pop up for the user.

This form of XSS is known as reflected or non-persistent XSS because it only occurs if the additional code parameters are passed in at run time. The web page itself is not changed permanently. However, this vulnerability can be exploited by sending someone a URL with the parameters as seen in the screenshot above. A lot of XSS can be done directly through the URL bar. The example given above is very basic. However, imagine the security issues that could occur if instead of displaying an alert, an attacker loaded code from an externally hosted script (the "cross-site" in cross site scripting).

The second form of XSS (persistent or stored) allows users to inject code directly into the page that will be repeatedly reflected to users who load it. The code is usually stored in a database and then continually reflected. The attack is carried out the same way, except instead of simply being reflected back to the user, the script is saved an executed every time the page is loaded. Think of an visitor log that web page visitors can sign and leave comments. The information they submit is saved in a database and loaded each time the visitor log is displayed. If someone were to inject malicious code, it would be shown each time to the user. This form of XSS is much more dangerous.

mySQL Injection

mySQL injection is well documented around the web with thousands of tutorials on YouTube covering it. mySQL injection can range from a very simple, short line of code to an extremely complex and carefully crafted string to destroy a database. What it all comes down to, however, is creating a string that will "confuse" the PHP code into executing more commands than should be executed. Let's look at the following PHP code:

$name = $_GET['name'];

$result = mysql_query("SELECT * FROM people WHERE first_name='$name'");

while($row = mysql_fetch_array($result))

{

     echo $row['first_name'] . " " . $row['last_name'];

     echo "<br />";

}

It's fairly straightforward as to what this code does (prints out names from the database given a first name). But look at the way in which the code is outputting the user-entered input: it's treating it like a single piece of text that is just inserted into the mySQL command. Suppose that the user doesn't enter a name, but instead enters mySQL commands? Let's look at the following code:

' or '1' = '1

This code is extremely common for testing mySQL injection vulnerabilities. When the PHP code prints out this string as the "name" in the code above, a very important tick-mark (') causes the code to read as:

WHERE first_name=' ' OR '1' = '1'

Essentially, we are crafting a string of code that fits nicely within the given mySQL code. The tick-marks line up and a complete statement is made. The statement "OR '1' = '1'" is used because it will always evaluate to true. What we are telling the database to do is "return all the rows where 1=1." In other words, return all of the rows. This is a great way to view data in the database that should not be viewed.

Progressing beyond a simple OR '1' = '1' statement, pretty much any SQL code can by inserted into the statement. This can be used to view other tables, return all the lists of users, grab additional columns, etc. Here is a great link to some SQL statements that may be helpful in exploitation.

Next in the Series

Now that we've discussed injection techniques and very common vulnerabilities, we are going to be using a web application firewall to prevent those attacks. There are many ways to protect against injection attacks (most notably the filtering and sanitation of user input) but we will be leaving the application vulnerable for the purpose of learning about the firewall.

Working with Web Vulnerabilities and Web Application Firewalls [Part 3 - An Insecure Environment]

[Note: this is part three of a multi-part series of posts detailing my experiences with securing web applications, creating test environments for practicing and installing and operating a web application firewall. Web security is an extremely important part of IT security since almost every major organization has a "web face." I will be exploring XSS, mySQL injection, and the use of web application firewalls to protect against these attacks.]

Now that we have a basic database of information that we can use later on, we need a way of practicing our exploitation techniques (and eventually our protection techniques) on a web application. Luckily, there is a solution called "Damn Vulnerable Web App." DVWA is a PHP/mySQL environment that is designed with test pages and configuration that can make it purposefully vulnerable to a number of attack vectors. We will be installing it in order to eventually protect against the attacks, but also to attack (and learn).

Downloading DVWA

DVWA can be downloaded at the projects home page: http://www.dvwa.co.uk/. From the Fedora machine, download and extract the ZIP file from the download page. Next, the files need to be moved into the web directory. (If you don't have an Apache/PHP/mySQL server configured, please return to part two).

Installing DVWA

I will be using root for this exercise. I want to make the application as vulnerable as possible and running as root will increase our chances for exploitation.

[root@localhost current_dir]# mv dvwa /var/www/html

Next, we need to issue the following command:

setsebool -P httpd_read_user_content 1

Now, in the web browser, navigate to your site's address / dvwa. You'll see the following error:

Click the link to setup your database. Click the "Create/Reset Database" button. If it was successful, you should see:

If you search in your mySQL database via command line or phpMyAdmin, you should now see a "dvwa" database.

Logging In

If you return to /dvwa in your browser, you'll be presented with a login screen. The default login is:

Username: admin

Password: password

Finishing Up

Now that DVWA is installed, we need to edit some configuration files so that it can be as insecure as possible. PHP version 5.2.6+ will prevent most mySQL injection attacks. So we need to change the configuration to allow them (most PHP websites are a version or so behind, so it is safe to assume that a majority of sites are still vulnerable, despite a newer version of PHP).

In the HTML directory of /var/www, type:

vim .htaccess

Then, type the following into the file:

magic_quotes_gpc = Off

allow_url_fopen = On

allow_url_include = On

Then save and exit.

Next in the Series

Next I will be using the DVWA setup to test some common vulnerabilities such as XSS and mySQL injection. Following that, I will be installing a web application firewall in front of the application to determine how such a configuration can help protect against exploitation.