How Companies Are Hacked via Malicious Javascript Code?
JavaScript is dangerous. Maybe you’ve heard this sentence several times before. Actually, being dangerous or not dangerous is true under different circumstances. JavaScript can be dangerous if the proper precautions aren’t taken. It can be used to view or steal personal data even you don’t realize what’s going on. And since JavaScript is so ubiquitous across the web, we’re all vulnerable.
JavaScript is good for the most part, but it just happens to be so flexible and so powerful that keeping it under control can be difficult. It all end up with how JavaScript actually works.
Let’s take a quick look at the working mechanism of JavaScript.
What is Javascript? Javascript is called the language of the Web. Each new version of browsers pushes the speed bar for execution time higher in terms of JavaScript execution speeds. This is an important performance parameter these days as websites make extensive use of JavaScript. JavaScript led the Web 2.0 revolution with AJAX. Using JavaScript, websites can send HTTP requests behind the scenes and customize or update certain sections of the site, tailored to a particular user’s needs. This does away with complete page refreshes and makes the user interface a lot more powerful and user friendly.
The browser fetches a page which might have embedded any
JavaScript code, or refers to a separate JavaScript file in which case that the file is also fetched by the browser. Afterwards, depending upon what you want your JavaScript code to do and how you structured it, it will either execute as soon as the file loads or will wait for a triggering event (like a click, or load). Finally, when everything is OK, the code is executed line by line. JavaScript is an interpreted language, which means you don’t need to compile the code into another form to execute it. All of the changes you make, they instantly take effect.
Some people assumes that because JavaScript has “Java” in its name they are somehow related with Java. It seems that the name was intentionally selected to create confusion, and from confusion comes misunderstanding. JavaScript shouldn’t be interpreted as Java. JavaScript is a different language.
JavaScript codes live within a web page, it either provides additional features to the web page or create an application within the web page itself. Some video games have been developed using JavaScript, and they can be played right in the Internet browser window. Java programs can typically perform calculations and the main “thinking” process on the server side or within a Java applet which should be downloaded initially.
A JavaScript library is a library of prewritten JavaScript which allows for easier development of JavaScript-based applications, especially for AJAX and other web-centric technologies.
In JavaScript, the way we use it effectively is by using a library. A library is a JavaScript file that contains a bunch of functions, and those functions accomplish some useful task for your webpage.
Almost every web sites on the internet use JavaScript libraries. In a recent academic study shows JavaScript library usage across all the web. In this study, researchers crawl Alexa top 75k website and the websites which are located under “COM” top-level-domain separately. Results are given in the Figure below.
According to the results obtained, 87.7% of Alexa sites and 46.5 % of .com sites use at least one well-known JavaScript library, with jQuery being the most popular by a large majority.
Why ?
Now let’s think about the damage of a serious vulnerability in the JQuery or other widely used libraries.
In such a case the effect would be very much.
In the continuation of the article, we’ve explained what can be done with a vulnerability in any JavaScript library and how can we achieve established security infrastructures for JavaScript enabled websites.
What can be done with a vulnerability in a JavaScript Library?
JavaScript Lib. can be abused, and that abuse leads to scenarios
that make it possible to snoop around your Internet activity and violate your privacy. The cruel part is that your website can be hacked even if your website is secure enough, because of a vulnerability in a JavaScript library that you use in your website. We’ve benefited from this source to explain following three types of malicious usages of JavaScript.
1. Snooping The Words You Type
Attackers can track text boxes where users could make status updates, write wall comments, etc. using a bit of embedded JavaScript code. In July 2012, a pair of researchers sampled data from 5 million Facebook users in USA and UK. The researchers made it clear that they only use recorded content which is “the presence or absence of text entered” rather than “keystrokes or content”. Still it was possible to track keystrokes and content. They just chose not to. It is certain that the attackers will not behave the same way.
The notion is a scary one. A small amount of embedded JavaScript is all that’s needed to record any kind of activity on a webpage — even if you don’t actually submit anything! Web scrolling, mouse movements, keystrokes: all of them can be tracked and recorded against your will or without your knowledge.
2. Tracking Your Browsing Habits
Things which can be tracked with JavaScript is not limited only with keystroke content, a bit of embedded JavaScript code can track your browser cookies. Through the magic of browser cookies, companies can store all kinds of user-specific information: browser type, preferences, location, etc. A lot of websites are already tracking your browser cookies to be able to offer a better user experience. For any purpose, you may think that they are constantly watching you when you surfing on the internet (in my opinion).
3. Malicious Code Injection
One of the most sneaky uses of JavaScript is cross-site scripting (XSS). Simply put, XSS is a vulnerability that allows hackers to embed malicious JavaScript code into an legitimate website, which is ultimately executed in the browser of a user who visits the website.
If this happens on a website that handles sensitive user information, such as financial data, the malicious code could potentially snoop and steal that information. Taken one step further, XSS can be used to reproduce viruses and malware, which is what happened when Twitter was infected with the StalkDaily worm.
And there’s another vulnerability which is called cross-site request forgery (CSRF). This kind of malicious JavaScript code can exploit a user’s browser, cookies, and security permissions in order to perform actions on a separate website.
BeEF is a project which uses browser vulnerabilities to gain control of the target computer system.
BeEF is a framework similar to Metasploit. BeEF uses a javascript, hook.js, when this JavaScript code is executed by a browser, it gives a ho
ok to BeEF. With a hooked browser, you can have a list of array of exploits to use, like in metasploit. Some of them are used for viewing cookies or viewing browser histories but in the end, they aim to have more sophisticated attacks to get a shell.
So, how the attack works is as follows, the client visits a malicious page, which contains BeEF’s hook.js script running on it, or it can be executed via an XSS attack. Attackers can use the same way to hack the target computers using vulnerabilities on a JavaScript Libraries. When malicious code is executed, you can see that a browser is hooked to you on your BeEF control panel and finally, exploits are launched.
Let’s consider a possible scenario, as mentioned in Table I above, JQuery is widely used worldwide (%86 in alexa, %62 in Com). Today, JQuery has 66 different versions. More than half of these versions have at least one vulnerability. If attackers can add malicious code (e.g. hook.js ) to a website using any vulnerability, they can gain full access to the target machines. Considering that JQuery is so widely used, this situation may affect millions of people in a bad way. (Detailed information about these statistical informations are explained below.)
You may think that disabling JavaScript is exact solution to prevent these undesired hacking events. But if you do this, you’d lose out on a lot of awesome web functionality, such as the “infinite scrolling” feature that exists on many blogs, social networks, and news sites. But more so, some browser exploits are still possible even if you disable JavaScript. Disabling JavaScript due to security concerns is like wearing a bubble suit every time you go outside because you’re afraid of getting hurt. It won’t actually protect you from much, but it will make your life miserable.
If so, we need to take some charming precautions for our JavaScript enabled websites to be secure enough.
But How? It is a little complicated and there is some limitations.
About this topic, there is an academic paper which is published recently. In this post we’ve benefited strongly from the paper. If you want to read more detailed information, read this referenced paper.
In the referenced study, over 133k websites were analyzed, and they show that 37% of them include at least one library with a known vulnerability. While JavaScript is the de-facto standard for developing client-side code on the Web, at the same time it is notorious for security vulnerabilities.
Figure 1 shows details of the 11 libraries with vulnerability information. For each library, we show the total number of versions in our catalogue as well as the fraction of versions. The worst offender is Angular 1.2.0, which contains 5 vulnerabilities. Overall, we see that 28.3%, 6.7%, and 6.1% of these library versions contain one, two, or three known vulnerabilities, respectively. More than half version of JQuery has one vulnerability. (Source of figure: study )
Third-party modules such as advertising, trackers, social media or other widgets that are often embedded in web pages typically implemented in JavaScript. Furthermore, these scripts can also load libraries, possibly without the knowledge of the website administrator. If not isolated in a frame, these libraries gain full privileges in the including site’s context. Thus, even if a web developer keeps own library dependencies updated, outdated versions may still be arise from badly maintained third-party content. Also, some JavaScript libraries and many web frameworks contain their own copies of libraries that they depend on. Hence, web developers may unknowingly rely on software maintainers to update JavaScript libraries. (Source: study )
In the referenced study, results show that 36.7% of jQuery inclusions are known vulnerable in ALEXA, when at most one inclusion of a specific library version is counted per site. Angular has 40.1% vulnerable inclusions, Handlebars has 86.6 %, and YUI 3 has 87.3 % (it is not maintained any more). (Source: study )
First, there is no centralised repository of metadata pertaining to JavaScript libraries and their versions, release dates, and known vulnerabilities. This fact makes the management of vulnerability more difficult. There are no reliable vulnerability databases, no security mailing lists maintained by library vendors. They have almost no details on security issues contained in release notes. So, it is difficult to determine which versions of a library are affected by a specific reported vulnerability.
Second, web developers often modify JavaScript libraries by reformatting, restructuring or appending code, which makes it difficult to detect library usage in the wild. To include a library into their website, developers typically use the <script src=”url”></script> HTML tag and point to an externally-hosted version of the library or a copy on their own server. Library vendors often provide a minimised version that is whitespace removed, has comments and local variables shortened to reduce the size of the file. Developers can also concatenate multiple libraries into a single file, create custom builds of libraries, or use advanced minimising features such as dead code removal. This is another complicated reason. When a developer modifies a library and use it, detection of which library and its version were used in the website is very hard for an automated tool.
Third-party modules such as advertising, trackers, social media or other widgets that are often embedded in web pages typically implemented in JavaScript. Furthermore, these scripts can also load libraries, possibly without the knowledge of the site maintainer. If not isolated in a frame, these libraries gain full privileges in the including site’s context.
Attackers can use these capabilities to steal data from a user’s browsing session, initiate transactions on the user’s behalf, or place fake content on a website. Therefore, JavaScript libraries should not introduce any attack vectors into the websites where they are used.
Some libraries such as Google Maps, advertising and tracking libraries like Google Analytics, and social widgets typically do not publish version information. Fortunately, the vast majority of such libraries are hosted by their creators at a single, non-versioned JavaScript Library (e.g., GoogleAnalytics.js ). It means that all clients automatically include the latest version of the library. This is very good thing for the security.
