How to effectively detect and mitigate Trojan source attacks in Javascript?

Javascript allows website developers to run any Code they want when a user visits their website. Naturally, website developers can be either good or bad. Also, cybercriminals continuously manipulate the code on a number of websites to perform malicious functions. But javascript is not an insecure programming language. Code issues or improper implementations can create backdoors that attackers can exploit. And here issues take birth. When you browse a website, a series of Javascript(.js) files are downloaded on your PC automatically. Attackers redirect users to compromised websites. These can be either created by them or they can be legitimate websites they’ve hacked into. It has been analyzed that 82% of malicious sites are hacked legitimate sites. Also, traditional code editors and code review practices miss detecting bidirectional characters present in the source code. This allows actors to inject malicious code that looks benign. And this issue was made public on 1st November 2021. 

If you are also facing the same Trojan attack issues, then this blog is for you. Here you’ll get the complete guide on how to detect and mitigate Trojan source attacks in javascript. 

What is a Trojan Source Attack?

Trojan source is a new type of source code and supply chain attack that causes the source code viewed by humans to be different from the actual software generated by the compiler- which means the behavior of software won’t match what the source code appears to say. 

Trojan source is a development style of attack that makes the source code read on the screen by humans significantly different from the binary code generated by a compiler through the use of Unicode control characters.

Let’s see the snippet from VS code of a Trojan Source attack as is employed in javascript source code:

// running internal logic for privileged users:

var accessLevel = “user”;

if (accessLevel != “user‮ ⁦// Check if admin⁩ ⁦”) {

    console.log(“You are an admin.”);

}

What about this-

2    var accessLevel = “user”;

3    if (accessLevel != “user‮ ⁦// Check if admin⁩ ⁦”) {

4   console.log(“You are an admin.”);

5 }

Did you catch the issue with the above source code? If not, try to examine the code snippet.

Here, this is a case of Stretched String type of attack. Code in line 3 makes it looks like the conditional expression checks whether the accessLevel variable is equal to the value of the user.

Have you seen the comment at the end of the line about logic checks, and it may look harmless but the truth is quite different. The use of Unicode bidirectional characters on line 3 hides the actual string value of the accessLevel variable check. Here is the real line 3 as the compiler would run it:

If (accessLevel != “user // Check if admin”) {

There are several types of abusing bidirectional control characters to inject malicious code into the source: Stretched String, Commenting-Out, Invisible Functions, and Homoglyph Function. Though the use of bidirectional control characters is a novel approach, this kind of attack is not actually new and has been cited in prior mailing lists and discussion boards. 

Detecting Trojan Source attacks in source code-

Code editing and code review processes may be on platforms or tools that don’t support the highlighting of these dangerous bidirectional Unicode characters. This means you may already have those bidirectional characters in your codebase. How do you find out if you have source code with bidirectional Unicode characters?

To help with that, an anti-trojan source scans a directory, or reads input from standard input STDIN) and scants it for any such Unicode characters that may be present in the text. 

You can use npx to scan files as-

npx anti-trojan-source –files=’src/**/*.js’

Or if you’d like to use it as a library in a Javascript project:

import { hasTrojanSource } from ‘anti-trojan-source’

const is dangerous = hasTrojanSource({

  sourceText: ‘if (accessLevel != “user‮ ⁦// Check if admin⁩ ⁦”) {‘

})

Preventing Trojan Source attacks in JavaScript with ESLint-

Better than only finding existing issues is to proactively safeguard the codebase to make sure that no Trojan Source attacks make their way to the source code at all. Generally, the Javascript community rely on ESLint and its various plugins to enable control of code quality and code style standards. 

Hence, with the use of eslint–plugin–anti–trojan–source, now you can include the ESLint plugin to ensure that none of the programmers or continuous integration and build systems are wrongly merging code that is potentially malicious because of bidirectional Unicode characters.

Let’s see an example of ESLint configuration for a Javascript project:

“eslintConfig”: {

    “plugins”: [

        “anti-trojan-source”

    ],

    “rules”: {

        “anti-trojan-source/no-bidi”: “error”

    }

}

Example output for a vulnerable code that slipped into codebase:

$ npm run lint

​​/Users/lirantal/projects/repos/@gigsboat/cli/index.js

  1:1  error  Detected potential trojan source attack with Unicode bidi introduced in this comment: ‘‮ } ⁦if (isAdmin)⁩ ⁦ begin admins only ‘  anti-trojan-source/no-bidi

  1:1  error  Detected potential trojan source attack with Unicode bidi introduced in this comment: ‘ end admin only ‮ { ⁦’                    anti-trojan-source/no-bidi

/Users/lirantal/projects/repos/@gigsboat/cli/lib/helper.js

  2:1  error  Detected potential trojan source attack with Unicode bidi introduced in this code: ‘”user‮ ⁦// Check if admin

How is the ecosystem mitigating Trojan Source attacks?

IDEs like VS Code have released versions to highlight these Unicode characters so that developers would take note of them and act with proper context at the time of code reviewing and code editing. Similarly, GitHub published warnings so that code bases will highlight the use of this potentially dangerous trojan on GitHub if they use bidirectional characters:

But keep in mind that, not all types of trojan malware attacks are being highlighted by Github. For instance, consider the following case that dubs invisible functions-

1 #!/user/bin/env node

2 

3 function isAdmin() {

4       return false;

5 }

6

7 function isAdmin() {

8      return true;

9 }

10

11 if (isAdmin()) {

12   console.log(“You are an admin\n”);

13 } else {

14  console.log(“You are NOT an admin.\n”);

15 }

As you see in the above javascript code, there’re not any warnings from GitHub when reviewing this code. What’s happening there?

The function declaration on line number 7 is written with the use of zero-width space Unicode control character identified as U200B, that makes it look visually as if this is the case of legitimate function isAdmin function.

You can verify this if we print out the code using tool such as bat, that is a clone of UNIX cat tool, with better syntax highlighting and Git integration:

1 #!/user/bin/env node

2

3 function isAdmin() {

4    return false;

5 }

6

7 function isAdmin() {

8    return return;

9 }

10

11 if (isAdmin() {

12    console.log(“You are an admin\n”);

13 } else {

14   console.log(“You are NOT an admin.\n”);

15 }

Should compilers and runtimes mitigate Trojan Source attacks?

Now, what about language runtimes and compilers? Lots of languages, including Node.js, have decided against updating their compiler from denying Unicode characters. Effectively transitioning the risk to code editors and humans, those need to be more careful when reading code and performing code review processes.

Some language runtimes such as Zig have been considered to employ a compiler error when detecting the use of Unicode bidirectional characters in source code, and allow to bypass the errors with comment.

Wrap up-

From this, you came to know about how to detect and mitigate Trojan source attacks in Javascript. If you’re still confused about javascript issues, consult with Solace experts. We are here to help through consultation and Javascript development. You can also hire skilled javascript developers of the Solace team for effective javascript development. Connect with Solace and get a free quote for javascript development. We will be happy to help you. 

---

Referral links-

The post How to effectively detect and mitigate Trojan Source attacks in JavaScript codebases with ESLint first appeared on Blog.