6

I recently had a call from BELL concerning a virus on our Linux ( Debian ) Server. Apparently Google emailed our client about an Italian Database found on our server that was doing phishing. They asked Bell to block our IP if we couldn't find it within an hour.

The folder was called "Show" and inside it was an index.PHP and a bunch of other files. I deleted it and now it's fine.

The folder rights were root:root. I believe it was added when the site admin uploaded a file from his PC. But how would the file ownerships be root:root?

How do I prevent such problems. Is there any Linux packages that would help?

***In case its relevant the client is using phpMyFaq and the folder "Show" was inside the folder "Attachments".

P.s in my access.log I have a lot of these:

- 69.158.XXX.XXX - - [02/May/2011:12:32:18 -0400] "\x16\x03\x01" 501 368 "-" "-"
- 69.158.XXX.XXX - - [02/May/2011:12:32:18 -0400] "\x16\x03\x01" 501 368 "-" "-"
- 69.158.XXX.XXX - - [02/May/2011:12:32:18 -0400] "\x16\x03\x01" 501 368 "-" "-"
- 69.158.XXX.XXX - - [02/May/2011:12:32:18 -0400] "\x16\x03\x01" 501 368 "-" "-"

where XXX.XXX is a real IP...

Could it be related? After Googling these codes I always get something about SSL's.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
Adam
  • 77
  • 2

3 Answers3

7

First things first: you must (I insist, must) wipe out your hard disk and reinstall from scratch. Any half-witted attacker or mere virus which could gain root access on a system will certainly not stop after adding a folder. It is highly probable that one or several backdoors have been installed, in various system utilities and/or the kernel itself, in ways which you will not be able to detect from the machine itself. So backup data files, reinstall the system, and copy back the files only after a through verification (in particular PHP source files).

A SSL/TLS connection begins by a first message sent by the client, and beginning with a header whose three first bytes will have value 0x16, 0x03 and 0x01, in that order (assuming that the client implements TLS 1.0, which is the most common case). Your log lines look like someone tried to connect to your HTTP server as if it was a HTTPS server -- and your server, unable to make sense of the bytes sent by the client, responded with an appropriate HTTP error message (which the client probably did not understand either, since it was trying to establish a TLS connection, not to exchange HTTP messages). This is probably harmless and quite possibly fully unrelated to your intrusion issue.

To prevent any further intrusion, you must only use software which has no bug -- which is not possible with current earth-based technology. The closest you can get is to maintain your system up-to-date with known security fixes; you should check for security updates on a daily basis (with Debian, this is a matter of apt-get update && apt-get dist-upgrade).

Community
  • 1
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
3

from my perspective this would be a 3-pronged solution. Actually, solution is a bad word to use... "mitigation" is much more applicable. First off I would agree with @Thomas Pornin and say that you need to wipe the system. After that step, the three prongs are as follows:

  1. Monitor the system for filesystem changes. One great option here is tripwire. This tool needs to first be run on a clean system (completely new, fresh installation is the best) to gain a baseline. Then, based on a cron job, the files specified on the system will be checked for changes.
  2. Monitor system logs. This way you will be able to follow the paper trail to the source int he future. The best way to do this is via a SIEM solution (i.e. OSSIM)
  3. Monitor possible attack vectors. Use some sort of vulnerability scanner. This will clue you in to opening which may allow for attacks. One possible solution is nessus.

Therare many solutions for all of these tools. Some other things to look at are network monitors and profilers like nagios and OrionNPM which can be used for a bit more analysis. I'm not sure of the alerting abilities of Orion, but I would guess that it could alert if there are suspicious connections, new network hosts, denial of service attacks, or any event you would like to create a profile for.

This seems like a lot of work if you have a small operation, but it can be a major help. I think all but orionNPM are free solutions (or a legal free version can be found).

If you have valuable data or services that others rely on, as far as I'm concerned, all these practices are part of the asset handler's due diligence (or security officer, admin, or whoever would be in charge of its security).

Keep in mind that this answer is regarding tools that you could have used or can use in the future to help prevent this type of attack from happening. Please also keep best practices in mind.... staying up to date, using secure communication channels, using strong passwords, controlling account permissions tightly, restricting resources of logged-on users, etc....

P.S. tripwire is defiantly in the ubuntu apt-get repos, as well as the vulnerability scanner openVAS (but i've had problems trying to implement openVAS).

Ormis
  • 1,940
  • 13
  • 18
0

A file owned by root:root isn't a problem. In fact if you are having trouble with your web application being defaced then doing a chown root:root -R /var/www will prevent the compromised application from changing the permissions on the file. Doing a chmod -R 555 . /var/www along with root's ownership is a great idea. These permissions will make it impossible for a PHP based virus to deface your web application.

Although the root of the problem is that there is vulnerability in your web application. Its likely that your using an old application or library that is vulnerable to attack.

rook
  • 46,916
  • 10
  • 92
  • 181