Journal Alioth's Journal: Spotted on a friend's blog... 7
http://www.secureworks.com/research/threats/gozi/
Note how long it was between the first infection, and antivirus products listing the malware.
There are still people out there who think that strict egress firewalling on corporate networks is 'corporate IT nazism'. Hopefully, this'll give 'em a clue why it's not.
Funnily enough, about three or four years ago I had a fairly big battle with corporate IT on why the latest Internet Explorer vulnerability needed patching. The security and firewall guy simply didn't believe a client side hack was a threat at all; after all they had a firewall - and scoffed at the proof of concept. The attitude only changed after I escalated it to the information security officer with a LONG and detailed essay on why the exploit in question was so bad, and how trivial it was to exploit (and we have a LOT of information that bad guys will want to steal). That exploit was the same one which was used to steal the Half Life 2 source code from Valve, too (so I even got to say 'told you so').
On a slight tangent, it's interesting to see how insecure the malware mothership servers are themselves - the researcher could just pick his way through the server, and get all the data they had collected and most of their CGI scripts. You'd think they'd know better, knowing that they are using easy-to-exploit weaknesses to not just leave the front door wide open. I have some personal experience of this - about four years ago, someone tried (and almost succeeded) to hack my web server using a 2-stage process:
1. a buggy PHP script that one of my users had installed
2. using that to then exploit a local root vulnerability.
Fortunately, I've long held the opinion that there is no such thing as a local root vulnerability - they are all potentially remote root vulnerabilities: all it takes is a bug-ridden CGI or php script for them to become remote root. So I had patched the particular kernel bug in question already, so their exploit just hung (and left itself in the process table for me to see).
So I followed the logs back, to the hacker's server, which was based in the Netherlands. The server had the *exact same* PHP 'shell' that they had used in the exploit against the buggy PHP code... and get this - they were running the kernel that was vulnerable to the root exploit they had tried on mine!
I was so, so tempted to root their server and do some really evil things. No, not an 'rm -rf *', but much more subtle, bastardly things. Like randomly corrupt files, installing key loggers and the like, and then sending them anonymous messages about how they were going to get caught and go to prison, or perhaps changing their browsers home page to goatse.cx. But I decided that since I had a static IP address, it was probably a bit unwise to hack them back as the unintended consequence would be that I got prosecuted instead. So instead, I filed a complaint with their ISP, and just wall'd them a message (they had several interactive logins, and an X server running, so I knew they'd see it) that the next time they tried to hack my server there'd be "consequences". Their server vanished the next day, so either they pulled it themselves or their ISP pulled the plug on them.
Scoffing at "I told you so" (Score:2)
Funnily enough, about three or four years ago I had a fairly big battle with corporate IT on why the latest Internet Explorer vulnerability needed patching. The security and firewall guy simply didn't believe a client side hack was a threat at all; after all they had a firewall - and scoffed at the proof of concept. The attitude only changed after I escalated it to the information security officer with a LONG and detailed essay on why the exploit in question was so bad, and how trivial it was to exploit (and we have a LOT of information that bad guys will want to steal). That exploit was the same one which was used to steal the Half Life 2 source code from Valve, too (so I even got to say 'told you so').
My experience is that this sort of behavior, even though it is ultimately beneficial to the company, leaves the security and firewall guys with egg on their faces. Maybe it's only my personal luck but that's always been enuogh for them to want revenge of the worst kind. First there's insidious harassment coming from managers, then there's across-the-board denial of any sort of independent research request, then there's the denial of any credit for accomplishments made, then there are endless demands for
Re: (Score:2)
One thought on the "other" server (Score:2)
Egress filtering (Score:2)
I'm generally in favour of it, but I'm not sure how it would have helped here. Even with egress filtering, you pretty much have to allow outbound packets to port 80 and port 443. You can use a site wide proxy to ensure that only HTTP/HTTPS traffic is flowing over those ports, but a) this exploit only sent plain HTTP traffic, and b) if they wanted to send any other traffic, they could ju
Re: (Score:2)
If the company feels that general web access will help company morale, the answer to this is to provide an internet cafe in the breakroom that is entirely separate from the main company network - preferably on locked down configurations, running on a minorit