Blogging Techstacks

OMG! A *JBoss* Worm!!

I nearly fell out of my chair when I came across this post at the Internet Storm Center:  JBoss Worm.  JBoss certainly has come a long way--now it's got a worm!  The JBoss Community article "Statement Regarding Security Threat to JBoss Application Server" has some additional information but both the ISC and JBoss Community articles are a bit short on information--for example, I'm kind of interested what kind of code gets executed once infection as occurred.  (Update:  OK, I take that last sentence back.  The first comment descibes what the worm does in very nice detail)

The worm spreads by connecting to unsecured jmx consoles and then executes code as the user jboss runs as.  If you hadn't followed the instructions in "Securing the JMX and Web Console" to restrict access to the jmx console, placed your app servers in your DMZs, and figured running them on port 80 as root was fine because "it's *just* jboss...who hacks jboss?" then you're in for a rough night and/or weekend.

If you are front-ending your jboss servers with Apache and figured setting a ProxyPass and ProxyPassReverse for "/" to your app servers was fine, it wasn't.  The same applies to those mod_jk JkMount's for "/*".

GlobalSign Temporarily Ceases SSL Certificate Issuance

See this article on ABC News for more details as Belgium-based Certificate Authority GlobalSign has temporarily ceased ssl certificate issuance in the wake of the announcement yesterday from comodohacker that he(?) has managed to breach 4 other major CAs. GlobalSign was the only one of the four high-profile CAs specifically named.

Mitigating the Apache Range Header DoS on Ubuntu Apache 2.2

If you are running apache 2.2 (the current version in Ubuntu Server on my recently created VM being 2.2.17) and you wish to mitigate your web server against exploitation by the Apache Range Header Denial of Service vulnerability and the killapache exploit, below is the mitigation steps that worked best for me.

Ubuntu's Apache 2 implementation utilizes httpd.conf for user specific server configuration changes. The mitigation suggestion from the Apache Software Foundation that had the most favorable impact was scrubbing the Range Header if an incoming request contains more than 5 ranges within that specific request. Please note that this fix may not help with future versions of the exploit.

The workaround makes use of mod_headers, which, on a stock ubuntu server apache2 installation, is not enabled. You can enable it using the command line:

sudo a2enmod headers

Once that is complete, modify your servers httpd.conf and add the following directives:

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

If you want to enable logging of hosts sending you those range requests, modify the configuration file for your virtual server—if you add it to the httpd.conf, the log file will get created but nothing will get logged. For example, if you are using the instance, modify the /etc/apache2/sites-available/default configuration file and add the following line somewhere that makes sense:

CustomLog /var/log/apache2/range-CVE-2011-3192.log common env=bad-range

That's all you need to do. Pretty straightforward workaround but hopefully a more formal fix will be made available by the Ubuntu Server team soon.