Javascript exploits vs executables

Hi

I'm wondering if an experienced wilder could answer this.

What are the limitations of javascript vs an executable file ?
For example can javascript create an entry in the registry ?

In this exploit Javascript can access browser plugins and launch Adobe;
https://www.wilderssecurity.com/showpost.php?p=1452618&postcount=33

and in this one it has knowledge of the location of the startup folder.
https://www.wilderssecurity.com/showpost.php?p=1451638&postcount=6

Basically i'm wondering why malware writers go to the trouble of downloading an exe file , if they already have a browser exploit available to them with javascript ?

Is it because each browser exploit is very specific and only allows a small part of javascripts total functionality available to them ?

 

You'll need to search technical discussions for a definitive answer. My understanding is that javascript cannot access the Registry. But ActiveX and VBScripts can.

using a vbs script to add reg value
http://www.computing.net/answers/programming/using-a-vbs-script-to-add-reg-value/15420.html

In Web-based attacks, this would require Internet Explorer.

In the examples you cite, the script downloads an executable file which is precompiled to carry out the payload commands. Another example would be the Mebroot MBR trojan. There are many aspects to an exploit that cannot be executed by just a script, and need a binary executable file.

However, some exploits do run entirely on javascript, such as the current bogus WinAntiVirus tricks. A typical site contains this code to download javascript files:

Code:

script src='fileslist.js'
script src='progressbar2.js'
script src='common.js'

Each of the javascript files contains the elements needed for the fake scan and to prompt the user for the bogus program. I looked at one of these in detail earlier this year:

http://www.urs2.net/rsj/computing/tests/winantivir2009/

Javascript also triggers the Cross Site Scripts XSS exploits. No binary executable required. The recent Twitter exploit is a good example:

Twitter worm copycats
http://isc.sans.org/diary.html?storyid=6187

Twitter StalkDaily Worm Postmortem
http://dcortesi.com/2009/04/11/twitter-stalkdaily-worm-postmortem/

In these cases, simply disabling javascript in the browser prevents the exploits from starting.

The best way to understand what is going on behind the scenes is to read the analyses of exploits. Many are very technical and beyond my comprehension as to the details of coding, etc, but after awhile you learn what to look for regarding the payload. Once you get that, you know exactly what you are protecting against and what preventative measures to take.

The example of the PDF exploit that you cite: Early articles on the web gave information such as,

All the user has to do is connect to the web site and the PDF file serves up the malware.​

Now, of what use is that information other than to scare the reader? It was even worse in the latest case since Adobe did not patch the Reader immediately.

Doing a little searching, it became evident that at least five requirements are necessary for the exploit to work in any browser:

• javascript enabled
  
• PDF file opens automatically
  
• unpatched version of the Reader
  
• no firewall prompt for Acrobat Reader connecting out to retrieve the malware
  
• no protection against the downloading of an unauthorized executable.

Just think of that: taking care of any one of those five points would render the exploit ineffective.

Careful security-minded people do their own research.


----
rich

 

There is no comparison.

Javascript is a language. So how it's used depends on the engine that parses the code and code itself. Even if code is malicious, if the engine is written correctly, validates input and has no holes, nothing major can happen.

Speaking of browsers, JS can't interact with local filesystems, unless there's a major problem with the engine. The problems with JS begin when it's used to interact with other plugins, which might have their own vulnerabilities.

It comes down to breaking out of the sandbox and potentially running a process outside the assigned memory space, which could then cause all sorts of problems.

But if the engine is good, the browser runs in a sandboxed mode, JS disabled in the first place, no plugins used, good plugins used, good plugins and additional measures, like interaction, download prompts, etc, the chances of something bad happening with JS are low.

Executables are well - just about anything.

Mrk

 

Thanks Mrk for clarifying that!


----
rich

 

Cheers!

The big problems started with IE when they put it in the FSO.
Once you can tamper with local files, the browser is just another extension to creating trouble.

Mrk

 

Thanks Mrk

If I understand you right there JS can't do anything on a system unless :

If it can cross than hurdle , then it has the same abilities as an exe.

So if it got past all those stages , then it could process - say create an outbound connection.

Is that correct ?

 

Hello,

You, you're right there. The browser is running as a process already, with calls to its JS engine as needed, so the script is an extension of that ability.

It might be possible to start an outbound connection. For instance, launch perl and open a udp socket. But this would require right privileges and of course, the right vulnerability in the browser/engine.

It also depends how browser sits on the system. Again, a sandboxed browser like FF or Opera are less likely to be able to interact with system. On Linux, they can't. In Windows, the protected mode, LUA, DropMyRights, etc also help.

Overall, the risk is not that high.

Mrk

 

You may wish to Google: javascript port scanner