4

TL;DR I didn't ask how to take care of my compromised server. I asked how to detect if a file is anomalous/extraneous/non-official. So this is not a duplicate of the question on compromised servers. This is obvious to anyone who take 2 minutes to read both questions before flagging as duplicate.

This morning we had a report of anomalous huge outgoing traffic from one of our debian servers. I tried to launch netstat -tpe as root and i found this. unama is an unknown process, i searched online and i couldn't find any reference to it.

I launched a whois 173.254.230.36 and i found that the ip belongs to a chinese organization named meiyunla.

Then i tried with which unama, just to discover that it is an unreadable binary file located at /bin/unama.

Does anyone knows how to detect if this unama file is an official package to have or if it is something anomalous?

edit

Just for info, in the end it was some kind of a virus, which made our server part of a botnet. Deleting the file was useless, as after some minutes it was there again, using from 60% to 100% of the cpu.

We had to shut down the server and launch a new one, reinstalling all the software from scratch.

Just one thing: never use ssh password authentication on a public ip :)

pietrovismara
  • 159
  • 4

1 Answers1

4

unama is definitely not a "normal" file from an official package, see packages.debian.org.

You an check whether it comes from any installed unofficial package by running dpkg -S /bin/unama. This will either show the name of the installed package it comes from, or show nothing if this file is not associated with any currently installed package.

scai
  • 2,199
  • 1
  • 12
  • 16
  • As a result i get: `dpkg-query: no path found matching pattern /bin/unama`. Does this mean it's not associated with any currently installed package? – pietrovismara Nov 25 '15 at 10:25
  • Ok i checked online and it means that. So if it's not an official package, and it's not associated with any currently installed package, it must be something anomalous. Am i correct? – pietrovismara Nov 25 '15 at 10:30
  • 1
    "Anomalous" in the sense of "not part of any official debian package". That doesn't mean that it's a malicious file, although it *could* be one. – scai Nov 25 '15 at 11:00
  • 2
    Yes, but since it's not official, on a clean debian server install on which i installed only certain packages i know, the only way the file could be there is that someone put it there. And it wasn't me. But that's another story, thank you anyway! – pietrovismara Nov 25 '15 at 11:04
  • 1
    You have to delete the following files: /bin/ps /bin/netstat /sbin/lsof /sbin/ss getty getty.lock (forget which dir they're in) and look for instances of DbSecuritySpt and selinux under /etc/rc.d/, see that they all link to /bin/unama, and delete them, and then reboot. If you don't want to delete those executables (but look at the sizes or md5 them, they're all identical to unama), turn off the x perm bit and copy them to another dir. I also deleted cron.hourly/0anacron but I'm not sure that's part of the hack. – Eric Dec 07 '15 at 21:48
  • I'd also be interested in finding out how my server (or yours) was hacked, but obviously don't want to swap this information publicly. Maybe a ServerFault admin can suggest an appropriate avenue to establish trust and then communicate. – Eric Dec 07 '15 at 21:50
  • 1
    @Eric, I've been hacked in this manner as well, same files and locations pretty much. Thanks for the advice on what to delete – SoluableNonagon Dec 10 '15 at 18:42
  • @Eric My best guess is that since the server had an open public ip and ssh password authentication, instead of an rsa key based one, the hacker had an easy time just brute forcing the password. Do you think it's possible? Our other closed servers (accessible only by vpn, accessible only with rsa keys) were left untouched. Thank you for the suggestions anyway, i'll keep it in mind. – pietrovismara Dec 10 '15 at 20:36
  • @Cuz If you used a fairly simple password then yes. – scai Dec 10 '15 at 21:22
  • 1
    @SoluableNonagon There's also an extra line in /etc/resolv.conf - you should be able to figure out which. – Eric Dec 10 '15 at 22:39
  • @Cuz my last log doesn't show any suspicious logins, but the nginx log showed a request consisting of 100s of 0x01 bytes. I suspect a buffer overflow exploit that somehow gave the attacker root permissions. I must admit the server is a hobby project of mine and badly needed patching – Eric Dec 10 '15 at 22:41
  • @Eric If the process has root permissions it can basically alter the logs to hide intrusions or activities doesn't it? – pietrovismara Dec 10 '15 at 23:09
  • @Cuz true, but the hack didn't seem that sophisticated to me. Unless its sophisitication is to make me think that. – Eric Dec 11 '15 at 18:22
  • 2
    For people coming to this later on - the exploit that got them into my system was the Redis one that was in the wild late last summer. www.theregister.co.uk/2015/06/19/sys_admins_push_the_red_button/ – Withnail Jun 02 '16 at 12:50
  • Great to know! My server had Redis too, so this make sense. – pietrovismara Dec 03 '16 at 18:36