[Wolves] Wolves Digest, Vol 269, Issue 8

[Adam Sweet]

--- On Sat, 6/12/08, Wayne <waynelists at machx.co.uk> wrote:

> > 6 hours to get in, thats fast if the box wasnt being
> watched...do you think the box was random attacked? did the
> attacker brute force in, or did he have a key?

> No, like a dimwit , I'd also set up a user to catch
> email for a one off 
> event, let call him 'dave' and since I'm the
> only
> one in the building, and don't use ssh , I'd set
> the password as 'dave' - doh. 

No, never ever do that. If someone wants to get into a machine they will try common (user)names like root, admin, test, apache, mysql, dave, david, bob, andy, matt, robert and so on, firstly with no password, then with the password the same as the username and common passwords like 'password', 'test' and so on. Always disable root SSH logins. That's the first account anyone would go for.

On machines where I have to allow SSH from anywhere, I use denyhosts and set the thresholds really low. Anyone trying the root account gets locked out straight away. Anyone who tries to login to another account and gets the password wrong is locked out. I share my denied hosts with the denyhosts database and I use their denied hosts too. Any IP in the denyhosts database can't get an SSH login on my machines. Of course, it's whack-a-mole but it's better than nothing. You put your own known IP addresses in /etc/hosts.allow so you don't lock yourself out. It's a good tactic to firewall off outgoing connections from your machines so anybody who manages to break in can't pull down extra tools like your attacker did. It won't stop sombody SCPing files to your machine using the same login they found but it's another layer. Stopping outbound connections will break your update manager so you'll have to allow the connection when you need it.

> Tho the odds on someone trying all the users and
> then trying the
> name as password must be low? 

Not at all. Most attacks are automated. Most likely, they will have a big list of common usernames, a big list of common passwords, a big list of IP ranges and a little script which attempts SSH logins on each IP in those ranges using combinations of usernames and passwords. When it gets in, it will log the IP/username/password combination used for it's owner to play with later.

One worrying trend is automated brute force SSH attacks from a distributed botnet with a centralised database of logins. Each host makes one or two attempts and pass their results back to the master database, then the next host will try a couple. This makes it easy to slip under the radar.

http://www.theregister.co.uk/2008/07/14/brute_force_ssh_attack/

(Don't try the tool this guy wrote, it contacts every network provider listed under the whois details for each IP with a failed login, which includes the the continental network registries like RIPE and ARIN who won't want to know. That also includes your own network provider if you have a failed login, regardless of whether you're in /etc/hosts.allow.)

If you look at the logs of the login attempts you will probably see that all of the ones from the successful attack were within a pretty short period of time and maybe only a few seconds apart.

> Thats the way I assume they
> got in, the 
> logs show about 3000 failed attempts. Oh and Romania ,not
> Russia.
> They first tried to download a Windows file before moving
> to Linux 
> stuff, and the content of one of the tars seems to indicate
> a spam package.
> 
> I've deleted the account and run a couple of rootkit
> detectors which 
> seems to indicate it clean (and the payload files were all
> 2006 so I guess they must be known about).

I'd still be afraid if I were you. Quite often an attacker will cover their tracks by replacing the binaries you will use to see what's going on with ones which hide what's going on. So, they might replace ls, top, ps and netstat with ones which hides their files, processes and network connections. You might also consider that they may have used your router as a staging point for attacks on your internal machines.

The fact that this attacker didn't remove their bash history and logs of their login attempts is a good sign that they didn't do a lot and didn't tidy up after themselves, which means that they either weren't there long enough, panicked and left quickly when they saw you login or wasn't bright enough to cover their tracks. On the flip side, maybe they hid the serious stuff that they got up to.

If you insist on keeping this machine running (I wouldn't), I'd keep a very close eye on your bandwidth usage and firewall all your other machines. Get a known good copy of of stuff like /bin, /sbin and /usr/bin on a USB stick, I would put it in the machine and then run commands from it like /media/usbdisk/bin/ps ax instead of running them from the local machine's installed versions. That's not to say that the kernel hasn't be messed with in the same way as modifying your other programs.

> How hard is it to get control of root of system from a user
> account?

If your user Dave has sudo privileges then it's a walk in the park. If not then your attacker will probably look at your distro version, your kernel revision and your other package versions then do a search for vulnerablities which provides privilege escalation in your software. If they know what they're doing, they will already be aware of a bunch of vulns in F6. Then all they need is a compiler to build the exploit and run it on your box. So, while I don't know a great deal about doing it in practice, it wouldn't be hard for somebody that does.

As Peter Oliver pointed out, Fedora doesn't make for great servers because they stop supplying patches about 11 months after release. If you like the Red Hat way, go for CentOS.

Ad