Serendipity install compromised

[marcusfriedman]

Hi, I've noticed that one of the blogs that I maintain has been compromised recently. This setup is based on Serendipity 1.4.1 with PHP 5.2.13, running on a Debian shared hosting server.
The index.php has been altered (starting with an "eval(base64_decode" ...), and the same has happened to other php files under the s9y directory.

This is a blog that I maintain for a friend, and it has been abandoned (meaning no new posts) for the last months. I noticed this problem when trying to reach some of its content through Google, which presented a warning indicating that the site might contain some kind of malware.

I have the following questions:

- Could this have happened because of some known vulneratiblity in this specific release of s9y?
- How can I prevent this from happening again? (I'm not very worried about this particular blog --which like I said is abandoned ATM--, but about many other blogs that I maintain and are based on s9y too)

I'd really appreciate any feedback you can supply with regard to this issue.


Thanks in advance,
Marcus Friedman

--------- Some more details --------------

This blog is hosted on its own domain (.net), where it's the only web-facing application currently installed.

The blog isn't popular in any way (few posts, no pagerank, almost no external links, no subscribers), and unless you write some very specific and well crafted query, it won't even show up in search engines.

[thh]

Hi, I've noticed that one of the blogs that I maintain has been compromised recently. This setup is based on Serendipity 1.4.1 with PHP 5.2.13, running on a Debian shared hosting server.

Are you sure that the break-in was done through that Serendipity installation and is limited to it? I.e. do you separate your installations (using suphp/suexec, chroot or something like that)?

Was the break-in done through an exploit or just by guessing unsafe passwords for FTP/SFTP/SCP access or access to the Serendipity admin area? Do you offer your users a secured channel for transmitting password (encrypted protocols - FTPS, SFTP, SCP instead of plain FTP, HTTPS instead of HTTP for logins)? Connecting from a public hotspot while transmitting unencrypted passwords may be enough ...

- Could this have happened because of some known vulneratiblity in this specific release of s9y?

Known vulnerabilities:
http://blog.s9y.org/archives/210-Securi ... lugin.html
http://blog.s9y.org/archives/217-Serend ... Xinha.html

(You do read security announcements for software installed on your server, do you? )

- How can I prevent this from happening again? (I'm not very worried about this particular blog --which like I said is abandoned ATM--, but about many other blogs that I maintain and are based on s9y too)

* Keep on top of known vulnerabilities in ALL software you have installed.
* Update to the most recent version (of Serendipity).
* Hope for no more vulnerabilities.
* Enforce encrypted transmission of passwords.
* Enforce strong passwords / check for weak passwords.
* Enable safeguards against brute forcing passwords.
* Harden your installation of PHP / of Apache or your other webserver / your server.
* Use IDS (intrusion detection systems).
* Monitor your webserver logs
...

The blog isn't popular in any way (few posts, no pagerank, almost no external links, no subscribers), and unless you write some very specific and well crafted query, it won't even show up in search engines.

Even more reason to check if only that blog was compromised and whether said compromise occured through that blog.

[kleinerChemiker]

I would recomend to check the server logs too, if it was an s9y exploit, you should find it in your logs.