0

I'm recovering a server from getting hacked and there is one thing I can't fix:

When I ssh (or scp) to the server, no matter what password I give, it lets me log in. I don't know much about the ssh protocol but I'm pretty sure it's not supposed to do that.

I've checked in the sshd_config file and the only changes are the ones that I've made (as far as I can remember).

Another thought that I had was that there might be something screwed up in the /etc/passwd file that I'm missing. Has anyone seen this?

nodapic
  • 103
  • 1
  • 7
    Please do a clean reinstall. You can't be sure where any backdoors left behind might be hiding. – fuero Oct 28 '13 at 21:52
  • Right - I should have mentioned that - I am planning on a clean install but management doesn't want the resources offline for just a little while. So I'm left with patching for the moment... – nodapic Oct 28 '13 at 22:04
  • @nodapic Inform management that by leaving a ***known compromised host*** on your network you are risking further damage/intrusions, as well as substantial legal liability (if the host is used to launch attacks, or if customer data is compromised from an incomplete clean-up). You'll find a lot of sympathy for your situation here, but any procedure other than "Isolate the machine, wipe it out, and rebuild from clean sources" is *Doing It Wrong*, and it's part of your job as a professional to make sure management understands that... – voretaq7 Oct 29 '13 at 15:31

1 Answers1

2

This would sound like there is a modified SSH binary set on your server, I would suggest running rkhunter and/or chkrootkit if there are any backdoors installed, if any are found I would suggest reading up on them and cleaning them up.

Also check your root accounts history to see what is happened, if the attacker left any traces.

You can also reinstall the SSH package ( or any other package that would be exploited )trough your package manager ( rpm/apt-get or any third package manager ) that would replace the binaries with the default binaries, rerun the rkhunter and see if there are still any matches.

And lastly, you could do a check which packages have the files modified, an example for RPM based systems:

Following command would list any changes to the RPM packages:

rpm -qa | xargs rpm --verify --nomtime | less

If the verification fails, it would show you which part did fail:

c %config configuration file
d %doc documentation file
g %ghost file (i.e. the file contents are not included in the package payload).
l %license license file.
r %readme readme file.
S file Size differs
M Mode differs (includes permissions and file type)
5 MD5 sum differs
D Device major/minor number mismatch
L readLink(2) path mismatch
U User ownership differs
G Group ownership differs
T mTime differs

Above is from the RPM manual - http://www.rpm.org/max-rpm/s1-rpm-verify-output.html

Another solution, would be to backup your data and reinstall the system when time allows, as it seems that you are in a tight spot right now.

Tabiko
  • 310
  • 1
  • 8
  • Thank you - this was very helpful. The project will be wrapping up in the next days and I'll be able to a full re-install. – nodapic Oct 31 '13 at 21:43