What can the @lulzsec senate.gov dump tell us about how the admins maintained their system/site?
SunOS a-ess-wwwi 5.10 Generic_139555-08 sun4u sparc SUNW,SPARC-Enterprise
means they haven’t kept up with OS patches. [-1 patch management]
celerra:/wwwdata 985G 609G 376G 62% /net/celerra/wwwdata
tells us they use EMC NAS kit for web content.
The ‘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.
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
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]
SSLEngine on
SSLCertificateFile /home/Apache/bin/senate.gov.crt
SSLCertificateKeyFile /home/Apache/bin/senate.gov.key
SSLCACertificateFile /home/Apache/bin/sslintermediate.crt
(along with the file system listing) suggests the @lulzsec folks have everything they need to host fake SSL web sites impersonating senate.gov.
Sadly,
LoadModule security_module modules/mod_security.so
<IfModule mod_security.c>
# Turn the filtering engine On or Off
SecFilterEngine On
```text
# 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]
-rw-r--r-- 1 cfmx 102 590654 Feb 3 2006 66_00064d.jpg
(many entries with ‘102’ instead of a group name) shows they did not do identity & access management configurations well. [-1 IDM]
The 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.
No comments yet.