We all love our code but some of us love it so much that we don’t want anyone else to read or understand it. When you think about it, that’s understandable – hours and hours of hard dev work, days of testing and weeks (months?, years?) of fixing bugs and after all of this, someone steals, changes or modifies your hard work.
To address these concerns, many developers will obfuscate their code.
Obfuscating Your Code
You’ve got your code, you love it and you want to protect it. You are not able to use a premium solution, and so revert to a free solution. There are many available to us, for us as developers our focus is to ensure our work can’t be easily ripped off.
You employ one of the several free solutions, copy&paste your script and the result looks great!!
You take this garbled, unreadable text, copy it to your site or your customers site and all seems well. Everything works as expected. In a few days / weeks / months though, strange SPAM starts to appear on your site.
You leverage all the latest tools, run the greatest scans in the world, but nothing is amiss. You can’t find the culprit.
Validating by Deobfuscating
I recently had such a scenario on a clients website. My colleague, Bruno Zanelatto, pushed a case to us in the Research group with the exact characteristics described above. At first, I thought, “it’s just a False Positive”, but after closer look I found things to be everything but ok.
My focus turned to the elements I couldn’t see (the obfuscated code). Everything else was looking good, the database was fine, and the code base for the application was fine. It took approximately 5 seconds, I add that as a note to developers to demonstrate that obfuscation is not as safe as some might believe it to be.
The script itself was a food recipe generator but in the end, I noticed something strange:
The original legitimate script was really obfuscated and added to the site source, but what’s this appendChild thing? For that url (I crafted some requests which looked as if they were coming from the real site, but it returned empty content). This was very curious, I had to understand where that appendChild was coming from and what it was doing. This forced my attention to the obfuscator itself to understand how it was doing it’s work.
This rendered some interesting findings.
After checking the service, I noticed that when obfuscating one of my scripts the obfuscator would add this to my script:
I intentionally commented out the original script and related document.write (I got this whole block after two layers of deobfuscations). What’s not commented out is a code that has nothing to do with the codebase. The authors of this service (htmlobfuscator.com) are appending their code to the existing codebase.
In the original case, it pointed to their domain. In this second case, the code generated on their site pointed to another (very suspicious) domain: jqueryapi.info. I was not able to get anything by crafting a series of requests, but this is not uncommon. This doesn’t mean they can’t return such requests at any other time. Those responses can vary as well, including infection of your website with spam, malicious redirect, phishing or any number of nefarious actions.
In Bad Company
After some more digging, I noticed, there are other domains hosted on the same server. And the names speak for themselves:
We leveraged VirusTotal to parse through these domains and get more information, the results were not surprising:
Widespread Use of Malicious Obfuscators
During my research, it turned out, that this obfuscator seems to be widely used! Based on the original infected file name, I realized that it was also part of a legitimate WordPress plugin – Simple Converter (and it might not be the only one):
Last year when this plugin was updated: 2013 and the author evidently used a free service to obfuscate his code. A code which he loved, he developed and which he wanted to protect and serve for free. Well, nowadays, almost nothing is for free.
Keep your eyes open and stay safe!