I can't see how a javascript can run the malicious code and automatic install the RAT into our/visitors PC and gaining access to their PC.
Javascript in and of itself cannot - the implementation of javascript usually has very, very limited access to the local system by design. That's assuming all works as designed.
Software systems rarely do; the larger the piece of software, the more likely bugs are to creep in. If one of those bugs happens to let you run arbitrary code, that's a problem.
To be clear, this arbitrary code is typically actually a specially crafted piece of input into the program. For example, let's assume there's a bug in the .image
renderer (a file type we've made up for the purposes) where I read data that should look like this:
FF 00 99 00 00 00
For reasons unknown, I've chosen to do crazy things like storing this RGB code in strings and am assuming string terminates with 00
and there's actually only one character. I don't know, maybe I'm anticipating bazillion colour screens. This may be a poor example. It's late. Bear with me. Anyway, let's assume I just use standard string functions in by renderer to copy that information out of the file. Now, if I send a valid file, great. However as an attacker, I could send a file that looks like this:
FF 00 99 11 11 11 11 11 11 <lots of 11s> 11 11 <some code> 00
How could I send that file? Easy. Include it in the html of the web page with bog standard img
tags. The browser will then open/render the image (as it does with jpgs, pngs etc) and my broken dodgy code happily executes that buffer overflow. I might even be sneaky and display: none;
it via css, but only if the browser still processes it.
At this point, those instructions in <some code>
get executed, which allows me to do whatever I need to. Typically, this downloads an executable of some sort and runs it, which means the exploit only needs to be small and I can download something meatier if the exploit worked.
From there, the "payload" can begin attempting to elevate privileges and installing backdoors. You already have a good answer on what a backdoor could do and how it might work.
I've chosen to make up an image file with a very simple mistake nobody should make; however, in the real world there are all sorts of media which have very complex results:
- Javascript - it's a programming language, needs parsing etc.
- PDF - a document format with bells and whistles, also includes javascript.
- PNG/JPG/GIF - I'd expect a bug in these to be rare, but I believe it has happened (not sure if it caused a remote execution vulnerability though).
- More complex movie formats, e.g. MP4 etc.
- Flash.
Now, two scenarios are slightly more complicated:
- Java applets allow arbitrary code execution - in Java. There are three possible outcomes here:
- You can avoid the signing dialog display via some mechanism and so load your class without user interaction, giving you the ability to download/exec code.
- You can find a bug in the classloader or jar parser that you can exploit.
- There is some bug in the Java language and/or runtime you can convince the user to use.
- ActiveX controls: these are, effectively, DLLs or EXEs with "special magic". It's Open Season with one of these; the only barrier here is avoiding (by getting a valid signature, social engineering or a bug) the authenticode (code signing) screen you (should) get before running one.
Baaasically, the browser environment is incredibly complicated and there are a lot of moving parts that must all read untrusted input and correctly handle it.
Now, where does Javascript come into the mix? Well, it might not contain the vulnerability itself, but it certainly can enumerate lots of useful client side information to determine what vulnerability to send - much more than simply the browser version. This could be part of the attacker's landing page, for example, to decide what if any exploits can be run.
Now, that little comment of Rory's:
Point 5 is dramatically understating what the attacker can do.
Massively, really, megarly (that's a word now) understating what the attacker can do. Since a remote access trojan has full control of your PC, a few things an attacker may do:
- Install further code, on demand, to carry out or co-ordinate attacks on other systems. This is commonly referred to as being part of a botnet.
- Harvest any interesting-looking information from the current system.
- Go around damaging things. Quite rare these days.
- Drop payloads onto any media/medium likely to enable the attacker to an exploit another system, e.g. infecting all USB drives that are plugged in.
The possibilities are pretty limitless; the first point is actually reasonably likely, as is the last.
I can haz tl;dr?
Javascript is usually used to perform reconnaissance on the target system; beyond that, an exploit allowing arbitrary code execution must exist in the browser or one of its plugins. From there, you can persuade the computer to download more information, and from there, the computer is your oyster.