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 analysed 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- means the behaviour 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 human significantly different from the binary code generated by a compiler through 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 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 user.
Have you seen the comment at the end of 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 actual string value of accessLevel variable check. Here 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 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.
How To Detect Trojan Source Attacks In Source Code?
Code editing and code review processes may be on platforms or tools that don’t support highlighting of these dangerous bidirectional unicode characters. 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, 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 Javascript project:
import { hasTrojanSource } from 'anti-trojan-source'
const isDangerous = 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 codebase to make sure that no Trojan Source attacks make their way to source code at all. Generally Javascript community rely on ESLint and its various plugins to enable control code quality and code style standards.
Hence, with the use of eslint-plugin-anti-trojan-source, now you can include ESLint plugin to ensure that none of 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 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 adminHow 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 these potentially dangerous trojan on Githubs 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 #!/usr/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 #!/usr/bin/env node
2
3 function isAdmin() {
4 return false;
5 }
6
7 function is<U+200B>Admin() {
8 return return;
9 }
10
11 if (is<U<U+200B>Admin() {
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 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.
