Often, the mechanism by which a malicious party gains access to a network is by getting an unknowing victim to run unsecured code inside that network. The third party can use applets to achieve this goal. Applets are essentially small applications that run within a larger piece of software. For example, you can embed Java applets in web pages, so that users run them in their web browsers.
With an adept social engineering attack, the malicious outsider convinces the victim to run an applet on a modified website that looks legitimate. The applet contains code that establishes a route into the network for the third party.
Many organizations (and the people within them) mistakenly believe that because applets won’t run unless a recognized authority signs them, this means the code within the applet must be safe. This is untrue in many respects.
The most literal aspect is that code signing merely verifies that the code has not been modified by anyone apart from its original author. But this doesn’t mean the code is safe. Just because a recognized code authority signs the code doesn’t mean the author wrote legitimate, safe code.
What normally happens in the code signing process is that people create code and they apply to get it verified by certificate authorities. The business of signing code and issuing certificates of validity is extremely competitive (and lucrative). What this means practically is that verification is minimal because the code signing companies want you as a customer.
I searched Google for “code signing services” and visited the order page of a leading code signing company’s website. I was greeted with the following fields to complete my order:
As you can see, the information requested is pretty bare bones. Any hacker worth their salt can easily clone a website and insert their own phone number onto the cloned web page. Poof! They’ve got a legitimate organization. The digital signing company calls the hacker to verify this legitimacy, which the hacker is able to easily do.
Another easy way around the verification would be to set up a domain with maximum privacy settings and create a one or two-page website that makes it look like a legitimate organization with a name and contact details. This does leave somewhat of a footprint because the hosting company has your payment details, though, so a prudent intruder into a network would deploy the first method.
False Security
Intruders into networks know that Java is extremely popular and likely to be used in some way on a network that they want to access. All it takes is a combination of technical skills and social engineering to shatter the false sense of security that code signing provides.
The intruder creates a website in the mold of something that would resonate with employees of a target organization. The pretext to visit this website is a convincing email that uses psychological manipulation, such as using flattery (asking for expert opinions), hinting at information that would benefit the target, and so on.
Upon visiting the phony website, an employee working at the target organization gets a request to run a Java applet, perhaps under the illusion that it is required to properly use this phony website. Up pops the standard reassurance that “the application security certificate has been verified” on the employee’s screen.
The target employee (perhaps understandably) thinks that the verification of this security certificate means the applet he’s about to run is safe. But he’d be wrong.
Upon execution, the malicious applet executes a payload that provides access to the internal network of a large organization, university, or government department. Et voila; the code signing has achieved nothing from a security perspective.
How is an organization to prevent employees from running signed applets that they think are safe? Good question. Personally, I think the only means of prevention is continuous employee education about social engineering attacks, particularly around emails.
Is Code Signing Useless?
Code signing is not useless; that’s not the point of this article. It is a useful idea insofar as it guarantees that code has not been altered since it was signed. But that doesn’t mean the unaltered code is, itself, safe, especially when hackers can so easily bypass the verification mechanisms in place at code signing services.
If you enjoyed this article, consider reading my other cybersecurity articles.