Where Obfuscurity Meets Negligence
2009-10-21 19:24:42 by jdixon
There are people out there who would argue that Security through Obscurity is better than no security at all. They advocate port knocking or running applications on "random" ports. Certainly, I'm not one to go around broadcasting my attack vectors to random visitors (oops!), but that doesn't mean it's a rational means of protection (honest, I'll pull out this time).
Patching your applications isn't just smart security, it's your responsibility as a member of Team Internet. While I'm happy that your patched system is safe from intruders, I'm overjoyed that it's one less zombie attacking mine. If you choose to further obfuscate your exposed services, grace be unto you.
All of this segues nicely into some juicy news from the twittersphere today. Apparently the admin birds over at Twitter are running numerous services with security vulnerabilities. The following output is from one of many identical servers running outdated Apache, PHP and OpenSSL versions.
Apache Server Status for twitter.com
- Server Version: Apache/2.2.11 (Unix) PHP/5.1.6 mod_ssl/2.2.11 OpenSSL/0.9.8e-fips-rhel5
- Server Built: Jul 22 2009 22:31:11
- Current Time: Wednesday, 21-Oct-2009 18:55:43 UTC
- Restart Time: Tuesday, 20-Oct-2009 20:37:49 UTC
- Parent Server Generation: 0
- Server uptime: 22 hours 17 minutes 53 seconds
- Total accesses: 9240915 - Total Traffic: 114.7 GB
- CPU Usage: u76.24 s34.37 cu0 cs0 - .138% CPU load
- 115 requests/sec - 1.5 MB/second - 13.0 kB/request
- 316 requests currently being processed, 28 idle workers
WWWWWWWWWW._WW_WWWWW_WWWWWWWWWWWWWWWWWWWWWWWWWWW_.W.W_WWW_WWWW.W W.WWWWWWWWWWWWWWWWWWWWW_WWW.WWWWWWWW_WWWWWWWWW_WWWWWWWWW.WW.WWWW WWWW_W..WWWW.WWWWW_WWWW..WW.W.WWWWW.WW..WWW_WWW.WWW.WWWWWW.W.WW_ ...W.._WWWWWWWWW__W.W.WWW_WWWWWWWWWWWWWW.__WWW_W.W.WWWW_WWW_WWW. ._W_.W.WWWWWWWW.WWWW.WWWW.WWWWCWWWWWWWWWWWWWW.W.WWWW.WWW.WW.WWWW WWWWW__WWW..WWWWWWWWWW.WWWW.W._WWWWWWWWWWWWWW.WWWWW..WWWWWWWWWWW W.WW._W.WWWWWW.WScoreboard Key:
"_
" Waiting for Connection, "S
" Starting up, "R
" Reading Request,
"W
" Sending Reply, "K
" Keepalive (read), "D
" DNS Lookup,
"C
" Closing connection, "L
" Logging, "G
" Gracefully finishing,
"I
" Idle cleanup of worker, ".
" Open slot with no current process
Srv PID Acc M CPU SS Req Conn Child Slot Client VHost Request 0-0 1533 0/37/116147 W 0.05 1 0 0.0 0.22 1542.45 10.25.35.68 twitter.com GET /account/rate_limit_status.json... 1-0 27699 0/480/115023 W 0.64 1 0 0.0 4.85 1558.44 10.25.35.68 twitter.com GET /statuses/user_timeline/FactoryM... 2-0 32551 0/125/115592 W 0.17 1 0 0.0 0.71 1548.73 10.25.35.68 twitter.com GET / HTTP/1.1 3-0 1360 0/50/113004 W 0.08 0 0 0.0 0.31 1527.64 10.25.35.68 twitter.com GET /statuses/user_timeline/16332734... 4-0 32686 0/112/111350 W 0.17 2 0 0.0 1.91 1505.79 10.25.35.68 twitter.com GET /statuses/user_timeline/30058865... 5-0 28142 0/432/111851 W 0.67 7 0 0.0 3.77 1458.97 10.25.35.68 twitter.com GET /statuses/replies.xml?count=100&...
Obfuscators would view this as the perfect example of a bad information leak. Au contrere, mon frere. This will be the spark that lights a fire under the operations team to get this fixed immediately, and probably cause management to address their patch compliance processes. Nobody likes chum in the water, especially when your users are the sharks.
Exploitable systems are still exploitable. It doesn't matter whether this was reported today, tomorrow or never; the systems still need to be patched. Stop feeding the zombie sharks.
- Comments (0)
Add a comment: