dow.ngra.de

About 10 years ago a friend of mine showed me an exploit. It was written in C and it tried to spawn a shell at a remote host. It seemed pretty cool. I did not understand the code but the mere idea that almost anybody equipped with a script like that could deface a webpage seemed scary.

You did have to compile the c file, have the right devel packages installed and use the correct flags. And then you had to figure out how to use it. A 14yr old could do it.

Today I spent many hours grepping logs, checking the filesystem for new/changed files to figure out how an old Wordpress instance was hacked and what had the hacker done there.

Going through the changed files I stumbled upon a php file which had some code prepended. The script had a very long line that started like this:

Ok, lets check what does the script do. Lets assign the long string to a variable and base64 decode it and inflate the compression.

The output was not what I expected.

The strings looked similar and I was already looking for an error in my code. Nope, code is correct. There is a slight change in the string. It seems it was compressed and encoded couple of times. Wow, it means I can have many evals inside evals. Fun!

After 11 iterations I got the code. Kind of reminded me a challenge that was posted to a mailing list and the question was what was the output of the program. That time it was more difficult: base64 encoded perl, that outputted base64 encoded bytecode, that outputted Java source file with a byte array that was byte code for the class file of the solution.

Anyways the 11 iterations gave me this (shot is made from my home computer).

Lets see the functionality that it has to offer:

• Full blown file manager
• Quick menu for
• Finding all suid files
• Finding all sgid files
• Finding all htaccess files
• Finding all writeable folders
• …
• Interface for the UNIX tool find
• Input field for executing commands as webserver user
• Tools for installing a backdoor
• Perl/C flavoured programs that are downloaded from a Singapore server
• Compiled/Interpreted – depending what is available
• Processes viewer
• FTP brute force cracker using users from /etc/passwd
• System info (CPU, Memory, installed binaries, passwd file, configuration files)
• SQL dump utility
• Interface for executing PHP code
• Self removal
• Adding a password for the script
• Fancy design!

I’m just amazed. This is way too eazy. So this is how it works:

• Lets scan the internet for Wordpress installation (automated)
• Look for vulnerable versions (automated)
• Exploit (in this case themes were filled with hidden links – semi automated)
• PROFIT! (automated)

How to avoid being hacked:

• Keep an eye on your Wordpress installations
• Subscribe to WordPress release emails/RSS and upgrade when needed
• Monitor for changed files (for example fcheck)
• Run Apache in chroot to minimize the available software for the Apache user
• Any other ideas?

PS. The script is 2500 lines of code, supports Windows and Linux and looks great :)

There are two main ways to associate a session state with a user — session cookies and session URL parameters. However for public sites there may be some risks for the URL-based approach.

Cookies are saved on the computer and are only ever sent in requests to the domain that has saved them. They have always been a focus of security attacks and thus they are pretty well protected. E.g. they cannot be accessed by the included third-party JavaScripts, which is important considering the current proliferation of web widgets.

On the other hands URLs are definitely accessible to the third-party scripts. What’s even worse, is that the browser will send the URL of the previous page as Referrer, when you click a link to go to the third-party site. Since most web servers will log the Referrer the owner of that site can access the logged-in user session as long as it’s live and possibly access private user data.

We hit this issue, when watching the statistics for ZeroTurnaround and clicking on a referrer link to JavaBlogs.com, which uses URL-based sessions. To our surprise we could access the logged in user data. Of course on JavaBlogs there’s not really that much data to access, but on another site this could be a serious issue.

For all I know this issue could be a very old and well-known one, but I never heard of it and apparently neither have JavaBlogs owners. If you’re making a public site make sure to keep this in mind.