When “Encryption” can be bad for sysadmins?

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.

6 Responses to “When “Encryption” can be bad for sysadmins?”

I don’t think that sysadmins have any deference between encrypted/unencrypted PHP files, because he don’t understand both of them.
I mean even if the programmer put a backdoor in his PHP files without encrypting the sysadmin will not be able to discover the backdoor.
In my opinion, if you you have security risk around your website you should not depend on third party softwares, unless it’s very authenticated and tested.

I my self as a sysadmin and php programmer can’t trust any encrypted code on my server (even I am who encoded it :D).
previously, I used cxs tool (ConfigServer eXploit Scanner) for scanning scripts files (php, perl, cgi, ….etc) on my server, cxs is a bit good tool since it has a variety rang of signatures of malicious scripts, but you can’t just depend on tools to securing your server.

In other hand, (in my opinion) responsibility of sysadmins is securing the server from attacks that could down it or any other type of attacks, and protect each user’s accounts form attacks that could came from others account on the same server, but they can’t protect users that allows attackers to crash them accounts, this is the responsibility of the user himself,

Nice post Xacker!
Is it really accurate or even correct to call what Zend Guard does “an encryption” ?
I think it’s only an encoding and obfuscation tool. and that’s why there are so many “dezenders” out there 🙂

it is true if u speaking about 1 file or 2 files script
but when it comes to large projects it is no matter even if the script is not enc. the attacker or even the programmer can inject an backdoor so easy and the code will still look smooth. and the programmer will not make an function for the backdoor xD i think it will looks like and normal code but have some hard to find security vulnerability in files in the script .
so i think it will not help even if u are a good php guy