Archive for February, 2011

Encryption has always been a man’s best friend, but is it really true for sysadmins with encrypted applications?

Imagine this scenario, and allow me not to be – so – brief in order for non-technical people to understand the security issue.

– A PHP programmer distributes a web application.

– To protect his property from snooping eyes, he decided to encode his PHP files with something like Zend Guard, IonCube, etc.

– Unfortunately, the poor programmer missed a security vulnerability in his application.

– An attacker finds the vulnerability, of course, remember… no matter that the application is encoded, we’re talking runtime here.

– The attacker gains access to the PHP files source-code one way or another.

– The attacker is capable of decoding the encrypted content thanks to tens of freeware tools on the Internet that targets such encryption (Google: “dezend”, “zend decoder online”, …)

– The attacker needs to inject a backdoor in the system for future use to gain access in case the security vulnerability has been fixed.

This is were the security behind encryption fails.

All the attacker needs now is to decode one of the original files (for example), insert his evil shellcode among the original code, encrypt the file again and replace it on affected website.

If I’m a sysadmin (and I am :P), I would get VERY suspicious about encrypted content in one of my website pages, but that is not going to be the case if all my website content were originally encrypted by the programmer and I’m aware of that from the beginning.

How do you even trust an encrypted content on your website in the first place? What if the programmer himself originally placed a backdoor among the safe source-code? How can you tell then?

I think web masters should run this thought in their heads and think long before they accept running any encrypted stuff on their websites.

Here is something quick from the latest experience I had in the past month.

I found a website vulnerable to an SQL injection attack, which was originally caused because of a human-error.

The original web application was not vulnerable, but some administrator modified the page to provide users with a flexible use of information. Information passed by the users were not sanitized at all, therefore, vulnerability was born from ashes.

The funny part is that the vulnerable parameter was an integer, which all you need to sanitize it is to use the PHP function: intval() – as simple as that!

Using the SQL vulnerability I was able to read database data using a somewhat complex SQL query. I had to extract the information one byte at a time using Boolean expressions, scan the page for a certain text that appears when the expression returns True, to decide if I got the right byte, i.e:

This method worked well, however, it took me a very long time to extract the information I wanted even after I wrote a Python script to automate the process and improved it couple of times to avoid scanning the whole possible alphabet set.

Two days later I changed my query to another complex one using MySQL function: load_file() – not that I haven’ thought of it before, but at the time of discovery it wasn’t possible to go right ahead and use it just like that.

I was able to get the result with one single shot.

For my surprise (not really), I found that the current MySQL user was ‘root’ with the almighty privileges 😛

Went ahead and extracted the root password hash, it was of MySQL 3.23 type… (that shouldn’t be hard!) but it was 😦

The hash wasn’t found in any database of tens I’ve searched in. I’ve even created my own rainbow table (loweralpha_numeric_1-6) but got no result (I know it’s not the superb rainbow table settings but that what I could afford creating in couple of days on my CPU).

Hmm… so what now? Give up and run away with what I’ve got before I get hammered?

Not yet baby. I have ‘root’ privileges remember? Means I have ‘FILE’ privileges. Means I can read any arbitrary file on the affected server, time for the SAM 😉 (oh yeah, I’m doing a Windows server)

SAM database contains the NTLM hashes of the system groups. Only problem is that on Win2k and later, the SAM database is protected by the syskey, which is stored in another database encrypted with AES-128 😦 unfortunately, the syskey was enabled by default. Hence, it would be a waste of time trying to get my hands on both files.

Hmm… and now? Easy man 🙂 in order for PHP to communicate with the database, the SQL connection requires the username & password, which are luckily stored as plaintext }: ]

So with ‘FILE’ privilege, I went ahead and acquired a copy of several PHP files (one by one, scanning for any include, include_once, require, require_once). To make things even more challenging, the files were encoded by Zend Guard 😦

No problem, deZend tools are all over the Internet. Got one, decoded the files and there was it, the root password in plaintext on a silver plate.

Using the password I was able to connect to the database through PHPMyAdmin control panel.

Enough? Nooo.. the fun has just started.

I need to own the system now. But how? Well, a PHP shell is more than enough 😀

Wrote a PHP shell, converted it to hexadecimal, inserted the hexadecimal content into a table on the affected server, and with a simple query:

SELECT shell INTO DUMPFILE ‘c:/wamp/www/shell.php’ FROM stupid_table

I dropped the shell into the affected server J

Thanks to the PHP shell I’m now able to control the system, upload/download/edit/delete/copy/move files, browse disk drives, execute system commands, use the server as zombie to attack different servers… you name it!

I didn’t even have to crack over 700 hashes, I simply modified the login page to save a plaintext copy of the password before resuming the normal functions… in approx 10 hours, I had over 300 logins 😀

What next?

To be honest … I’m going to attack the rest of the network, there are several systems attached to the affected server… and I’m curious about their contents.

How am I going to do that? “Pass-the-Hash” attack 😉

In conclusion:

SQL injections can lead to full system compromise if running with high privileges.

As for the time being… I better get back to my work before my boss come break my neck :s