Apache Struts Zero Day and Mitigation
Thanks to Gebhard for letting us know about a new vulnerability in Apache Struts.
If you recall the classloader vulnerability of few months ago, the fix for that seems to be case and punctuation sensitive (using [] instead of "." was not accounted for)
In any case, they have posted a mitigation how-to here: http://struts.apache.org/announce.html#a20140424
This affects all versions up to 2.3.16.1
Find more information on this here:
http://www.pwntester.com/blog/2014/04/24/struts2-0day-in-the-wild/
================
Rob VandenBrink
Metafore
Fun with Passphrases!
As systems administrators and security folks, we've all had our fill of our users and customers using simple passwords. Most operating systems these days now enforce some level of password complexity by default, with options to "beef up" the password requirements for passwords.
The prevailing wisdom today is to use passphrases - demonstrated nicely by our bud at xkcd - http://xkcd.com/936/
So I routinely have very long pass phrases for public facing accounts. Imagine my surprise when I was creating a new account on major cloud service (the one that starts with an "O" and ends with a "365"), and found that I was limited to a 16 character password.
Needless to say I have a case open to see if that limit can be removed. I'm not looking for no limit / invitation to a buffer overflow status on the password field, but something bigger than 16 would really be appreciated !
Be Careful what you Scan for!
After some fun and games at one customer site in particular, I found that the SSL services on the earlier versions of the HP Proiliant Servers iLo ports (iL01 and iLO2) are not susceptible to heartbleed.
However, their implementation of SSL is fragile enough that scanning them for the Heartbleed vulnerability will render them inoperable. This affects Proliants from G1 all the way up to G6, as well as many of the HP Bladesystems.
A complete power down of the entire system - as in remove both of the AC cables - is required to reset the iLo card and bring it back to life. While this may seem like a quick fix for a single server, if that server is running a Hypervisor, or if it's a bladesystem with Hypervisors running on the blades, this can multiply to be a huge issue. Especially if your client scanned the server subnet, and effectively bricked all their iLO cards before they realized there was a problem (oops)
(And yes, the fact that we worked this out Easter weekend is somewhat ironic.)
Full details are in HP Support Document c04249852
This illustrates that even when scanning for simple things (with NMAP, Nessus or any other scanning tool really), it's best to scan a few test systems first - or if you have a test VLAN that replicates your production systems, even better! This isn't a problem with the scanners, almost always the problem is the fragility of the service being scanned. Many services are only written to deal with "the right" inputs, which is not how most scanners (or most attackers) tend to operate.
Safe Scanning Everyone!
========================
Rob VandenBrink
Metafore
Comments