Español | English
rss facebook linkedin Twitter

"If you see that your neighbor is being shaved...

get ready to be shaved," as the old Spanish saying goes. What I'm trying to say is that we should be aware of the problems arising in other countries that use technologies similar to ours. More precisely, as my colleagues in Mexico pointed out in the Spanish version of this blog, I'm talking about incorrectly customized broadband routers delivered to new users, which cause unnecessary security weaknesses.

Unluckily for us, the Mexican issue is not an isolated one. Here in Spain we have quite an accute problem, especially in ADSL routers. I recently read in Bandaancha that it's no longer necessary to trojanize the computers in order to make DDoS attacks. Incorrectly preconfigured ADSL routers can be used as additional zombies on the wild, replying to DNS queries from the WAN side. At least for the moment, no profit can be made from it, but the attackers gain the ability to remotely manage routers. What if they include a sniffer in a vanilla firmware that reports back to a botnet any logged data? This is not as easy as using traditional methods, but it's still a chance.

I was concerned after reading it, but I didn’t think it was strange at all. We have a long-term, unresolved problem. It started when the first ADSL lines appeared. Simply put, ISPs couldn't cope with the growing demand of ADSL lines, so there was no time for them to worry about security. A lack of both know-how and capability of foreseeing future issues have not helped either. Until today, the number of broadband users has been increasing, and the security problems in the routers that the clients receive from ISPs remain unresolved.

To summarize, most ADSL routers for home clients still come with these security flaws:


  • Poor wireless preconfiguration
  • Default users
  • Lack of proper remote management
  • Lack of automatic updates

Yet it seems that computers are still regarded as the most vulnerable target, ignoring the poor router configuration factor. It's important to keep in mind that, today, routers are not that different from PCs; they feature their own CPU, ROM, RAM and, usually, embedded GNU/Linux OS. Cable providers have had a more thoughtful approach when deploying network devices, as the users aren’t supposed to configure the router by themselves. They come already configured out-of-the-box, with DHCP hosted at the cable ISP.

I think that those who should worry the most are ISPs offering ADSL services. Sure, there are daring users who might, unwittingly, misconfigure their routers, but those are the minority. Most home users don’t change their router’s settings. Problems like DNS Amplifictation shouldn't exist, because all that’s needed to avoid them is proper configuration and remote management. Today, no one would expect a mail administrator to configure the company MTA in an open relay. Such behavior would be considered unprofessional, to say the least. Why shouldn’t the same apply to network engineers?

Is it possible to solve the problem remotely with some kind of massive firmware upgrade and reconfiguration, or is the system fatally wounded and the routers need to be entirely replaced, much like what happened with SECA/NAGRA? I'm afraid the latter is more likely to happen, with the added problem that the cost is considerably higher than that of sending one million bug-free smartcards. So why do they keep installing flash memories on the routers? It may be worth going back to the good-old mask ROM much cheaper and with a nice retro look.

Álvaro Ramón
S21sec labs





New ZeuS binary

The evolution continues. Some days ago a new ZeuS binary appeared with the version number 1.3.0.26. This new development is an attempt to improve the stealth techniques used to date, as stated in one of the TODO files found some time ago. After just a quick look, one can notice the following changes:

  • When it's executed and the system isn't infected yet, it copies itself in the directory %SystemRoot%/system32, but with a different filename in each execution. Also it gets the basic file information from the %SystemRoot%/system32/ntdll.dll file (creation, last access and modification dates).
  • If it finds a previous ZeuS version installed it deletes the binary, leaves and shows the hidden files in the next reboot. To give an idea of the situation, one of the latest samples with sdra64.exe as executable filename is the 1.2.12 one.
  • Apparently the configuration and data files are not stored on disk anymore but they're exclusively stored in memory.

In addition to these important modifications, it’s worth mentioning the use of an IP instead of a domain name in the dropzone URL. Also, there doesn't seem to be a complete panel in the URL directory, but a small PHP file – probably a redirection. This is not something new, but maybe it's this version’s new way to hide and make difficult the analysis.

However, we've seen some samples with the version number 1.3.1.1 but featuring the usual behaviour (except deleting previous binaries): sdra64.exe as binary filename and storing configuration and data files on disk. Perhaps this is due to multiple options when creating the binary (builder) or to the existence of different authors.

As you can see, some of the techniques posted on this blog for detecting ZeuS have slightly changed in this case. Basically, all of them are still valid with the exception of the location of hidden configuration and data files function, which apparently don’t exist anymore.

This is only a preliminary analysis of this new binary, but we'll post more details as soon as we have them. Tune in again!


Jose Miguel Esparza
S21sec e-crime







(+34 902 222 521)


24 hours a day, 7 days a week



© Copyright S21sec 2012 - All rights reserved


login