FireEye takes on Ozdok and Recovery Ideas
The folks over at FireEye report (http://blog.fireeye.com/research/2009/11/smashing-the-ozdok.html) on one of their takedown efforts of the Ozdok (aka Mega-D) botnet. Victims of this infection have pop-up advertisements pushed their system and they are used to send spam—a significant amount of spam according to M86 Security (http://www.m86security.com/TRACE/traceitem.asp?article=510). More information is available from Joe Stewart: http://www.secureworks.com/research/threats/ozdok/.
This is good news. A major spam source has been disrupted. Unfortunately we’re still left with thousands of machines that have been infected. In many cases of adware/spyware infection the malware with disable or impede Anti-virus programs, leaving these machines unprotected to follow-on infections. Taking down Command and Control servers and registering the future/fallback domains is time-consuming and expensive. Yet compared to the effort required to clean up all of the infected systems it’s only the tip of the iceberg.
A centralized plan or organization to drive such an effort is doomed to fail. The response needs to be community-driven, decentralized, and personalized. Organizations may be able to support an incident response team, but individuals cannot. Law Enforcement treats this as an individual’s problem, the individuals’ think law enforcement should act, and ISPs are stuck in the middle. There are opportunities there, but it’s risky. I’m fond of the idea of walled-garden services—I’m more fond of optional walled-gardens (which brings more expense to the ISP.)
Although the information about what is a bad URL and what isn’t can be centralized, its delivery has to be decentralized. Services like OpenDNS are attractive and I have hopes that it will be successful. Web filtering services can have a big impact on not only malware, but also phishing attacks. There’s one feature that I haven’t found in the web filtering services yet (I hope they’re reading this.) I would like to have the option to block access to all domains that are younger than X days. For some folks, 1 or 2 days is fine, other organizations might like 7 or more. This shouldn’t be too hard to implement with some whois-lookups, right? Or better yet, allow the new domain in, if it’s been categorized by the filtering service, but block it if nobody has evaluated it yet. Perhaps someone could write a FireFox plugin to implement this block for folks who can’t afford a web-filtering service?
Even More Thoughts on Legacy Systems
Legacy systems have been a popular topic here recently (see http://isc.sans.org/diary.html?storyid=7528 and http://isc.sans.org/diary.html?storyid=7546). Any environment of sufficient size, complexity or age will have its share of legacy systems. While we can work with policy and management to phase them out, in the meantime one has to deal with the fact that they’re on the network and vulnerable, which makes your network vulnerable. Does it have to be that way?
Consider this simplified example: your company makes widgets, the widget-making machine is computer controlled, and the company that wrote the software is now out of business, so there is no chance of upgrades or patches in your future. A bad-case example scenario: a consultant from Acme Industries comes into your facility with a laptop infected with an old worm (say Downandup,) and when they connect to your network it infects your widget-making machine. Hilarity ensues.
A possible solution is to reconsider why that legacy machine needs to be on the network. Do you know why? It’s probably serving a web application, or someone is VNCing into the system to manage, or it has to send out status emails, etc. That’s the first step: understand what services are required. Then, use another device (because if you could lock down the legacy system it would already be locked down, right?) to isolate that system. Old techniques like Access-Control-Lists, and Virtual LANs won’t block a dedicated human attacker, but against automated malware it can be quite effective. If you have to expose a vulnerable service, limit that exposure to known and trusted systems on your network, not to everyone on you network. Also, make sure that the isolation works both ways, if something manages to get into the system, you can at least limit it from spamming out to the rest of your network.
This approach also works when you have to plug a vendor’s “Appliance” into your network.
iPhone worm in the wild
Couple of days ago there were a lot of discussions about an attack on iPhone users in the Netherlands where the attacker installed a backdoor that asked the iPhone owner to pay 5 EUR to get rid of the Trojan.
The attack was aimed exclusively against jailbroken (hacked) iPhones – these phones allow the user to run unofficial code and bypass Apple's official App Store. In other words – it allows users to run (often) pirated programs.
One of the problems with most jailbroken iPhones is that they run various services, including SSH among the others. The installation of SSH service is terribly insecure and, besides allowing remote root login, also leaves a default password on most jailbroken iPhones. This "vulnerability" was used by the hacked in the Netherlands and the same thing is exploited by the worm named iKee that was published today.
The worm is written in C and contains a lot of comments – one can see that the author was not the most experienced C coder but nevertheless he managed to get the worm to work.
The worm is actually very, very simple. After execution it will scan certain IP addresses (you can see the list on the screenshot above). All IP addresses belong to 3G customers in Australia and are hardcoded in the worm. If an IP address is reachable, the worm uses a Cydia application to try to login to the IP address as root – it presumes that it is an iPhone since only 3G networks are scanned.
If the login was successful, the worm will copy several files (including itself) to the vulnerable iPhone, will kill SSH (so the phone can't be infected again or by a different attacker) and will change the background as well.
While this is maybe the first iPhone worm that was actually detected in the wild, and while it is very simple, it definitely highlights the risks of running unauthenticated code, something that a lot of people using hacked/jailbroken iPhones are not aware of. Similarly as not running a pirated version of an operating system on your machine, one should not try to evade security mechanisms implemented in phones, especially since they can contain a lot of sensitive personal information.
--
Bojan
INFIGO IS
Comments