DNS Hijacking by Cox

Tue Jul 24 00:14:11 UTC 2007

On 7/23/07, Perry Lorier <perry at coders.net> wrote:
> With my Undernet admin hat on, we have regular issues with botnets and
> the like for years and probably will for the foreseeable future.

> In my personal experience we see a new "crop" of script kiddies about
> every 6 months to a year.  Generally they start with whatever publically
> available tools they can get their hands on [...]

Agreed

> doing it[1].  If you're interested in finding people that Undernet
> detects as being open proxies or such like, put an IDS rule looking for
> ":[^ ]* 465 [^ ]* :AUTO ".

I'm not so sure Undernet is the only IRC network to ever begin
a banned reason message with the word "AUTO".

I suspect it would be most useful if "detected drones" by most major IRC network
would be visible to cooperating ISPs for further analysis, not just Undernet.

What I would see as ideal is for some form of "detected BOT" incident
reporting protocol to be utilized at both ends.

Rather than use IDS to snoop for our "user banned" messages, let IRC
networks run their automated bot detection methods, and when a bot is found,
post that fact to a short-term real-time incident database of some
sort that would
limit visibility of the information (to the ISP responsible, or to
someone asking a
Yes/No question about a specific ip address and approximate date & time).

The ISP would then be able to use the database as a geiger counter and
apply more exhaustive (CPU-intensive) monitoring to the activities of
a bot-reported connection
for a short time, and ascertain if they can verify the "user is a bot" claim,
and maybe take some abuse response if the user is actually infected with
a spambot or floodbot.

Due to the massive volume, automation would be a must, however.

This relies on the IRC network's bot detection heuristics being kept
up to date, but
for the IRC networks' sake, they already have to be.

And unfortunately also relies on someone maintaining a database, that
could be costly,
and would all be a waste if no ISP was able to utilize it to actually isolate
bot-infected computers, or if no IRC network actually reported to the DB.

> them harder to find and ban.[2]  Also the constant reconnects themselves
> can almost overwhelm a server.  I almost want to submit patches to the

Not just "almost"; the constant reconnects are themselves a DDoS
against the server that has banned them, or the entire network, depending
on the "target" of the reconnects.

Merely perhaps, an unintentional one, rather than deliberate attack.

Use of firewall rules in addition to ordinary K-Lines should serve well
to mitigate some of the incidental reconnect spam's negative impacts on IRCD.

Firewall rules are just impossible to implement across all servers on most IRC
networks, as each server is administered independently, and contacts to make
the necessary changes are not likely to all be available or on IRC at the same
time.

(Plus there's no automated tool I'm aware of an IRC network can use
that says "mass-firewall all channel members of  channel #botnet for 96 hours,
on all servers, even if all admins of the IRC network ceded some
firewall control
to other admins)

> botnet codebases to implement exponential back off, or infact /any/ kind
> of reasonable delay between connection attempts.

I suspect boxes IRC Servers run on should enforce something like "sane delay",
such as  with "new connection throttling" at the OS level.

By that I mean, for instance, more than 3 connects to port 6667 in 60
seconds would
be met with all SYN packets dropped from that source for a few minutes
thereafter...

Or the IRC server could be designed as to impose a delay before
transmitting the 465 numeric to notify the bot that they are banned.

Maybe you drop them from the IRC network, send the 465 numeric, and leave the
connection open for a few minutes.

Until the bot gets the disconnect, the probability of a reconnect is
essentially 0%....

Malware is generally too dumb to notice the connection is "hung" and all its
messages are silently going to /dev/null.

I used to have an alternative to /KILL called  /HURT or /HUSH, which instead of
disconnecting a user, would cause IRCD to blackhole the session and
yet pretend to hold the connection open.

I never met a bot that automatically noticed this had happened and responded by
dropping/attempting to reconnect...

--
-J