Overview
Recently, researchers at the University of Cambridge published a paper detailing how obfuscation
techniques can be used to inject malicious code into source code prior to compilation. Depending on the
compiler, the malicious source code would be hidden from the user’s view, yet still successfully
compiled into the software resulting in a trojan horse attack.
What Do We Know About This Attack?
To keep things simple: an attacker can write source code that contains comments with Unicode Left-to-
Right and Right-to-Left to inject malicious code which will be interpreted by a source-code compiler as
code, not a comment. For example, the following code could be interpreted given the correct Unicode
encoding to create the string “b a d c o d e” (Boucher & Anderson, 2021):
RLI LRI e d o c PDI LRI b a d PDI PDI
While the authors of the University of Cambridge paper make this attack out to be a novel approach to
infecting source-code, it is not. Assura has been able to find examples of the same or similar attacks in
source-code back to 2017, as well as other attacks outside of source-code injection which take
advantage of Unicode homoglyphs dating back to 2003.
Despite this attack not being a novel approach, it is worth noting that Advanced Persistent Threats
(APTs) have used supply-chain attacks several times over the recent years to conduct their campaigns,
notably the SolarWinds attack.
Assura’s Take
The research into this attack has brought to light that there is a credible threat against organizations
that compile their own code, as well as anyone who utilizes the resulting software. Which means,
essentially, everyone could be affected by this because everyone uses software. Now, does that mean
the sky is falling? Absolutely, not!
To successfully execute this attack, a threat actor would have to write code that executes both the valid
and malicious code without breaking the program and ensuring that the malicious code actually does
something useful enough for them on their end. This could be extremely difficult unless the attacker is
positioned to read the entirety (or at least enough to know they will not break it) of a program’s source
code to ensure the program continues to function as intended and the malicious code functions as
intended. You could equate this to Luke getting one chance to shoot the proton torpedoes into the
thermal exhaust ports of the Deathstar and guide them the length of the tube to the main reactor using
the Force. Is it possible? Yes. Can a normal X-Wing Pilot or back to reality hacker do this? Probably not.
To protect yourself and your organization against these types of threats you can do the following:
From a software development standpoint:
- Use a code-review toolset which displays Unicode. Not all of the text editors or IDEs you might
employ now render Unicode correctly; make sure you are aware of what your tools can and
cannot do. - Do not blindly compile blocks of Unicode into your software without understanding what they
do. - Do not accept pull-requests or source-code from untrusted sources.
- Follow a secure software development life cycle to help detect malicious code.
From a software consumer standpoint:
- Conduct software reviews prior to implementing any new software in your organization.
- Monitor software vendors for vulnerability announcements and conduct regular vulnerability
scanning and patching. - Utilize a Next-Gen Anti-Virus or Endpoint Detection and Response tool to help detect/prevent
zero-day attacks. Be extra cautious of open-source software. Check to see if open-source
software developers are accepting unreviewed code or if their review process matches your
own risk acceptability.
At the end of the day, it is good that this attack vector is getting some attention. However, it is not
something that we foresee currently gaining a lot of attention from attackers when there are many
other ways into environments that offer more bang for their buck.
If you’re an Assura client, please do not hesitate to reach out to your Virtual ISO or Assura SOC point-
of-contact if you have questions about this vulnerability or our response. Otherwise, please contact us
at [email protected].
References: