Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Macunfadebo]

http://robots.hp.af.cm/

[zombie urist]

I don't think its a good idea to let people submit javascript to execute.

[Macunfadebo]

it runs in the browser, not in the server, so it's alright!

[wierd]

Javascript is a fully featured language, despite its inadequacies in strong typing, and insanity incarnate in the DOM.

Even just running in the user's browser, you shouldn't overlook the potential for mayhem, especially if other people's javascript is potentially executable.

This is one of the major issues with driveby advert attacks; crosslinked JS being executed outside the adhost, that does very naughty things. If your service let's naughty people put bootstrap scripts in, and allows other people to execute it, your service is now a vector for malware, even if your server is itself never compromised.

(Situation: Abuser uploads his malicious code snippet, in typical trojan style. It does something innocuous and exactly what it bills itself as, except it calls an outside script. That script then dos bad bad things. Abuser uses your site to distribute his naughty script to other users, to zombify them, and make them do his bidding doing who knows what.  )

If you do enable a service like that, that allows uploaded javascripts, make sure that crossloaded javascript is forbidden, and that all scripts submitted are clean of crosslinking, bootstrapping routines, and malicious actions.

That is a very tall order.  That's why most people don't offer a service like that, and also why advert companies continue, to this day, to get abused as vectors for driveby infections.

[Macunfadebo]

sorry, maybe I didn't think it through, but isn't javascript mostly harmless?

what's the worst it could do, aside from opening lots of tabs and crashing the browser?

[zombie urist]

No. Its a good concept, but instead of having users submit code try using event handlers and such.

[Macunfadebo]

what do you mean event handlers? what kind of events?

[wierd]

Javascript is capable of writing files in the user's cache folder, and in shell-executing system resident executables, among other things. This combination is especially dangerous when coupled with zero day exploits, such as those in older versions of the JVM, and older security holes in browsers, like the EMF code execution exploit.

Basically, a javascript can function as a dropper, drop malicious executables into the user's cache foler, then shell execute say, javaw.exe on it, and escallate out of the browser using that-- or, on an older and vulnerable browser (like IE6 that refuses to fucking die!) They could drop a harmless looking EMF image file that contains malicious executable code, and make use of a horrible kludge from the old win3.11 days to do very nasty things indeed.

If the user is foolish enough to be driving under an admin capable account already, then the shell executed script can do whatever the hell it wants to!

If I were a malicous program maker, I would first call in a new javascript file offsite that does a background check on the browser using its useragent string, and a few probes of other resouces, to determine what exploit to attempt, or simply to stop gracefully. It would then call the appropriate exploit script from aother external dependency, and do its nsty business.

From your end, looking at the trojan vector snippet, all you would see is a suspicious call to "secretsauce.js", which is obfuscated javascript. Being obfuscated, unless you are super good, you won't be able to read it, while the browser can. (That's the point!).

The only way to prevent this, is some very hard rules about cross linking javascripts. NO OUTSIDE SCRIPTS, NO OBFUSCATED SCRIPTS, NO LOCAL FILE WRITES.

Such rules would have to be backed up with viggorous enforcement and active policing, especially if the site became popular.

Much like with the advert industry, the desire to do those very things by customers is VERY high. (Google "evercookie"). As such, the advert servers invariably become unwhitting hosts to malware, as uploaded attack scripts enter the system faster than they can be reported and removed.

[Macunfadebo]

can't I just undefine any file importing function?

[wierd]

I don't know. I've never tried to purposefully break features of the api.

I do, however, know that you can write files, even binary data files, to the cache folder and in some cases, others as well, and that you can shell execute activeX and other mechanisms, including but not limited to, the flash player plugin, java VMs, silverlight, and others. IIRC, you can also invoke the windows scripting host, but that requires some doing.

Since DEP is turned off by default for anything other than critical processes, they can often tims just use a buffer overflow to smash a stack and hijack the browser's process, among other things.

I'm not a malware writer though, I just took some javascript classes back in the early 90s, and when I learned that I could do those things, had red flags and alarms go off in my head.

Javascript in the wrong hands can be quite dangerous. Blindly treating it as harmless is foolish in the extreme.

[miauw62]

Thanks for the explanation, wierd. It's an interesting read.

[Killjoy]

I just took some javascript classes back in the early 90s

Yes, because web technology totally has not evolved since then..

Javascript in the wrong hands can be quite dangerous. Blindly treating it as harmless is foolish in the extreme.

JavaScript is a language. Nothing more.

It cannot do anything on its own. You can eat up some stack/heap space with it, but that is harmless in today's world. Browsers sandbox Javascript VMs, so they never create some runaway situation where they denial the host of resources.

The only danger is in the web/browser API. But web/browser APIs have come a very long way since IE 6/7.
ActiveX is dead. Flash is being phased out. Silvertime never took off, and the JVM is getting harder and harder to reach.

What you are left with is a few Web APIs that are highly restricted. A clone of each API module is pushed into each sandbox on demand, so one process will never affect another.

Creating malicious code in JavaScript is extremely difficult. The basic set of web APIs are impossible to exploit, they don't modify the state of the host in any way. They are highly peer reviewed by security experts (Chrome and Firefox source is available for anyone interested in studying them), and the few exploits there has ever been have long since been patched up.

Chrome, which is probably the browser that takes security most serious, considering google have given away almost a million dollars to hackers over it 5 year lifecycle for any type of exploit they discover and report, even if they are minor.

Chrome had its sandbox broken only once by their own API.

The funny thing is, the hackers did not use any magic memory corruption tricks. They essentially exploited being able to open iframes into into higher privilege internal chrome pages.

What I am trying to say is, "Stop being paranoid"
Whenever your computer communicates with the outside world, it is a potential security flaw.

JavaScript is not really dangerous as the only few people who can actually exploit it are usually security researchers working in places where they make stupid amounts of cash, and not russian hackers that usually exploit old software installations trying to obtain your creditcard infomation.

[wierd]

Here's a simple attack vector.

http://4umi.com/web/javascript/filewrite.php

This writes a complete HTML document to a local file, using a hidden iframe. That HTML document can be a .HTA, which windows at least, considers executable. Structurally, it is nearly identical to a normal HTML file.

.HTA files can make use of a very wide range of scripting languages and functions, and have much looser local filesystem allowances than does a normal browser session, AND, by default, always execute with IE, and not EG, Chrome, or Firefox. (when shell executed anyway) This means you can tune the vector specifically for IE specific actions.

Inside the .HTA, you can call WScript.Shell with the Run command, and execute any arbitrary executable that can run under the current user's credentials.  Moreover, you can structure the .HTA to not show a browser window at all while it does this invocation.

http://blogs.technet.com/b/heyscriptingguy/archive/2005/10/31/how-can-i-start-an-application-from-an-hta.aspx

The extended scripting capabilities of the .HTA lets it create a binary file of any type in the local filesystem:
http://stackoverflow.com/questions/14324634/write-to-a-text-file-using-an-hta

It uses an ActiveX legacy object structure-- The same one I mentioned 3 posts above-- and can get away with it, because it is executing inside IE, and not Chrome or Firefox. So, that doesn't matter. You can output raw bytes into the file, and give it an arbitrary extension. 

Combined, you use the first script to write out the .HTA file. A good place to write that is in the legacy RUN folder of the start menu. (Since it uses the save-as functionality, you CAN write there!) On the next reboot, windows will automatically run the .hta for you, being so helpful that it is. Once it does, the .HTA creates the malicious .exe file, and uses wscript to execute it.

You are now pwned.

[Killjoy]

You are now pwned.

No, but I really wish that was the case. Even writing a boring old text file to the host system is worth a lot in Google rewards system.

Look, browser security has gone up a lot over the past decade. JS is not allowed to communicate with the host system in any meaningful way. Each tab in Chrome/Firefox run in their own virtual machine, so interaction is very tightly controlled. As I said, the only time someone managed to break the sandbox in Chrome was when they piped through no less than 14 sibling iframes into a top layer page with elevated privileges. Since then they made sure iframes can only open http: pages, so no similar trick will ever be possible.

I don't care about IE, anyone using it is asking for viruses anyway. At my work we like to pretend IE does not exist, it makes creating and managing a web service a much more pleasant job.

[wierd]

You clearly *did not* read what I wrote, or read the linked articles.

The first one uses the browser's "save as" functionality to save a webpage. You can change the extension.

There is a kind of "program" on windows called an "HTML Application".  It uses the extension ".hta" *IT ALWAYS EXECUTES WITH IE. IT IGNORES THE BROWSER SECURITY MODEL.

Don't believe me, make a hello world javascript html document, save it as .hta, and open it. It will open with IE. Every. Single. Time.

So, writing that simple text file DOES mean a lot.

You populate the hidden iframe with the .hta data, save it using the automated save as invocation, save it as .hta, and save it in the c:\%systemroot%\programs\run folder. On the next reboot, it will run as a trusted local executable under the user's credentials, and can do anything the user is allowed to do, without upsetting the UAC.

What chrome and firefox do is not relavent. The engine that executes .hta files is always IE. Always. It's patented.

As such, your "la la la I can't hear you, chrome fixed that" line of argument does not apply here.
Reiterating that chrome only allows http data is irrelevent. An .hta *IS* valid html data, served from a valid HTTP source, when it gets put in the iframe. Nothing unkosher happens there. It just tells the browser that it would like to save an offline copy of the static html of that page. That is not normally a risky behavior, and it doesn't get treated like one.

It is the way microsoft blindly trusts .hta files that is the real deal.

Actually look, and try again.