Testing ‘Apache Killer’

I ran the tool to attack this server as well as my employer’s load balanced array of servers. It is clear that only those servers running an older version of Apache (i.e. 1.3) and those not protected by a firewall are at risk.

My underpowered virtual private server crashed just a few seconds after the attack began. The tool revealed that my employer’s web sites did not appear to be vulnerable.

Is there a solution?

While a solution from Apache.org has not been published, some of the contributors have identified the issue and are working on a patch. In the meantime, you can add the following rule to your virtual site definitions, if you own your sever, or .htaccess file if you’re in a shared-hosting environment.

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^(HEAD|GET) [NC]
RewriteCond %{HTTP:Range} ([0-9]*-[0-9]*)(\s*,\s*[0-9]*-[0-9]*)+
RewriteRule .* - [F]
</IfModule>

The preceding rule blocks “get and head requests with multiple ranges in the Range HTTP header.”

After applying this rule, feel free to attempt to kill your server, it will not crash. You should inspect your traffic logs to verify the incoming traffic is denied access with an HTTP status of 403, or forbidden.

Dirk-Willem van Gulik from Apache published this workaround for versions 2.0 and 2.2:

<IfModule mod_setenvif.c>
# Drop the Range header when more than 5 ranges.
# CVE-2011-3192
SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range

# optional logging.
CustomLog logs/range-CVE-2011-3192.log common env=bad-range
</IfModule>

This disclosure was found by a couple of researchers:

We’d been discussing doing a visualization of mobile data, and while he was researching into what was available, Alasdair discovered this file. At first we weren’t sure how much data was there, but after we dug further and visualized the extracted data, it became clear that there was a scary amount of detail on our movements. It also became obvious that at least some other people knew about it, but it wasn’t being publicized.

So I decided to follow the instructions and extract this data from my phone backups, using the Python script and SQLLite plugin for Firefox referenced in the researchers’ post, which turned out to be more fun than scary. AT&T customers data is stored in the CellLocation table while Verizon users data is saved in the CDMACellLocation table.

My private data revealed

I was not impressed by the amount and quality of the data. I’ve only had my iPhone since Verizon began to offer it, but I expected more than 980 rows of data. So I proceeded to download the timestamp and location information to a comma separated value file that I promptly uploaded to Open Heat Map and the following map was revealed.

Here is where I think the premise of evilness by Apple falls apart. This data is useless. As far as I can tell, since I’ve had the phone in my possession from day one, some of the locations are completely off. I have not frequented a place near the Jersey shore or Long Island, NY.

It’s obvious this data represents cell tower locations more than it does my normal travel if you were to map it with a GPS.

Don’t fear the big bad Apple. At least not yet.

Sky News Video: Apple iPhone tracking device raises privacy issues

UPDATE: Alex Levinson destroys the premise that Apple is using this data for malicious purposes here.

Right now there is a worm making its way around old, unpatched versions of WordPress. This particular worm, like many before it, is clever: it registers a user, uses a security bug (fixed earlier in the year) to allow evaluated code to be executed through the permalink structure, makes itself an admin, then uses JavaScript to hide itself when you look at users page, attempts to clean up after itself, then goes quiet so you never notice while it inserts hidden spam and malware into your old posts.

Here are two quick steps to avoid unnecessary risks:

Turn off user registration

This one is simple. Just log in to your administrator screen and visit the “General Settings” screen (listed under Settings) and make sure the checkbox labeled “Anyone can register” is not checked.

Block access to your blog’s admin area

This can be accomplished with simple authentication.

If your site runs on Apache, you can create an .htaccess file in your /wp-admin/ directory to require authentication before the page is displayed. This post provides the necessary steps.

The task becomes a lot easier under Apache. So I threw away the plugin code and added the following rule to the Apache configuration:

<directory "/public_html/mysite.com">
RewriteEngine on
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*) https://%{HTTP_HOST}/$1	[R,L]
</directory>

The directive above can be placed inside a VirtualHost or Directory directives, but this usually requires access to the Apache server configuration, which is not typically possible in a shared hosting environment — in that case, the rule can be added to the .htaccess file.

Alternatively we could have used the SSLRequireSSL Apache (2.x) directive, but this would only block access to the non HTTPS address. In our case we want to automatically redirect the users instead of displaying an error message.

Academic researchers have found an exploitable hole in a popular form of wireless networking encryption. The hole is in a part of 802.11i that forms the basis of WiFi Protected Access (WPA), so it could affect routers worldwide. German graduate student Erik Tews will present a paper at next week’s PacSec in Tokyo coauthored with fellow student and aircrack-ng team member Martin Beck that reveals how remnants of WPA’s predecessor allow them to slip a knife into a crack in the encryption scheme and send bogus data to an unsuspecting WiFi client.

In an interview from Germany, where he is a PhD candidate studying encryption at the Technical University of Darmstadt, Tews explained that an existing attack on Wired Equivalent Privacy (WEP) was modified to provide a slim vector for sending arbitrary data to networks that use the Temporal Key Integrity Protocol (TKIP). (Tews’ collaborator Beck is a student at the Technical University of Dresden; Tews credits Beck with the discovery, after which they jointly developed the paper that Tews will present at PacSec.)

With the Tews/Beck method, an attacker sniffs a packet, makes minor modifications to affect the checksum, and checks the results by sending the packet back to the access point. “It’s not a key recovery attack,” Tews said, “It just allows you to do the decryption of individual packets.” This approach works only with short packets, but could allow ARP (Address Resolution Protocol) poisoning and possibly DNS (Domain Name Service) spoofing or poisoning.

The paper, Practical Attacks against WEP and WPA, is now available for download.

So even though TKIP is not broken, the best way to protect your network is by switching from TKIP to AES with a relatively random password at least 20 characters long.