[code light=”true”]SunOS a-ess-wwwi 5.10 Generic_139555-08 sun4u sparc SUNW,SPARC-Enterprise[/code]
means they haven’t kept up with OS patches. [-1 patch management]
[code light=”true”]celerra:/wwwdata 985G 609G 376G 62% /net/celerra/wwwdata[/code]
tells us they usefor web content.
last‘ dump shows they were good about using normal logins and (probably) ‘
sudo‘, and used ‘
root‘ only on the console. [+1 privileged id usage]
They didn’t show the running
apache version (just the config file…I guess I could have tried to profile that to figure out a range of version numbers). There’s decent likelihood that it was not at the latest patch version (based on not patching the OS) or major vendor version.
[code light=”true”]Alias /CFIDE /WEBAPPS/Apache/htdocs/CFIDE
Alias /coldfusion /WEBAPPS/Apache/htdocs/coldfusion
LoadModule jrun_module /WEBAPPS/coldfusionmx8/runtime/lib/wsconfig/1/mod_jrun22.so
JRunConfig Bootstrap 127.0.0.1:51800[/code]
Those and other entries says they are running Cold Fusion, an Adobe web application server/framework, on the same system. The “mx8” suggests an out of date, insecure version. [-1 layered product lifecycle management]
[code light=”true”] SSLEngine on
(along with the file system listing) suggests the @lulzsec folks have everything they need to host fake SSL web sites impersonating
[code light=”true”]LoadModule security_module modules/mod_security.so
# Turn the filtering engine On or Off
# Make sure that URL encoding is valid SecFilterCheckURLEncoding On # Unicode encoding check SecFilterCheckUnicodeEncoding Off # Only allow bytes from this range SecFilterForceByteRange 0 255 # Only log suspicious requests SecAuditEngine RelevantOnly # The name of the audit log file SecAuditLog logs/audit_log # Debug level set to a minimum SecFilterDebugLog logs/modsec_debug_log SecFilterDebugLevel 0 # Should mod_security inspect POST payloads SecFilterScanPOST On # By default log and deny suspicious requests # with HTTP status 500 SecFilterDefaultAction "deny,log,status:500"
shows they had a built-in WAF available, but either did not configure it well enough or did not view the logs from it. [-10 checkbox compliance vs security]
[code light=”true”]-rw-r–r– 1 cfmx 102 590654 Feb 3 2006 66_00064d.jpg[/code]
(many entries with ‘102’ instead of a group name) shows they did not do identity & access management configurations well. [-1 IDM]
apache config file discloses pseudo-trusted IP addresses & hosts (and we can assume @lulzsec has the passwords as well).
As I tweeted in the wee hours of the morning, this was a failure on many levels since they did not:
- Develop & use secure configuration of their servers & layered products + web applications
- Patch their operating systems
- Patch their layered products
They did have a WAF, but it wasn’t configured well and they did not look at the WAF logs or – again, most likely – any system logs. This may have been a case where those “white noise port scans” everyone ignores was probably the intelligence probe that helped bring this box down.
Is this a terrible breach of government security? No. It’s a public web server with public data. They may have gotten to a firewalled zone, but it’s pretty much a given that no sensitive systems were on that same segment. This is just an embarrassment with a bit of extra badness in that the miscreants have SSL certs. It does show just how important it is to make sure server admins maintain systems well (note, I did not say security admins) and that application teams keep current, too. It also shows that we should be looking at all that log content we collect.
This wasn’t the first @lulzsec hack and it will not be the last. They are providing a good reminder to organizations to take their external network presence seriously.