For those who are interested in the guts of this, you can find the beautified code on Github[0] and a detailed breakdown here[1].
In short, Windows completely exposes its filesystem through ActiveX and WScript, skipping the need to package Node for filesystem access. Then bundle native JS crypto along with some nasty string-encoded binaries, and you've got everything you need to hold a PC hostage.
Makes me wonder if there's a way to commit such evils with AppleScript and/or JavaScriptCore...
Not "completely", there are ways to disable this sort of thing with AD policies. This corner of Windows has been de-emphasized ever since the "security push" of XPsp2, and it's all but been replaced by Powershell. Microsoft being Microsoft, they have not completely removed cscript.exe for compatibility reasons but they'll likely do it at some point.
In fact, I bet this "exploit" doesn't work on a properly-secured box with UAC on where a user is not running as a local admin, at least not for the part about Volume Shadow Copy.
It's a shame because I personally like CScript/WScript, it's the little scripting engine that could. Unfortunately, the Windows security model is too haphazard to let something like this free to run.
In Korea banks, by law, have to secure their Web sites with ActiveX plugins, which probably means this stuff is going to be around way longer than it should be.
Thanks for the reminder. I disabled scripting via GPO for this reason months ago, but I forgot to actually remove the logon scripts from all of the AD accounts. This mechanism has become largely redundant anyway, tasks like drive and printer mapping are better done in other ways.
When build tools run an uglifier on your code this is what the variables comes out as. Takes all your logically named variables and shortens them like a-z. They can make it "beautified" by un-minifying (not all on 1 line) but you can't get their original variables name without the original source.
I think they may have been referring to the names right down at the bottom - a minifier wouldn't use "NWvQtGjjfQX" without having used all the two, three four or five letter variable names.
Beautifiers should use something like Gfycat uses for their URLs instead, that would be prettier and simpler/faster to understand.
> Most randomly generated URLs look like this: G1XeD4SwlHReDA. We thought it would be fun to do it differently. Our URLs follow the nomenclature: AdjectiveAdjectiveAnimal This is enough to give us a namespace of billions, while also letting humans write them easier. You’re welcome!
https://gfycat.com/about
Wouldn't that just make the code more confusing? You'd get some random name that doesn't mean anything to what its intended purpose is. Keeping the simple 'a-z' scheme the beautifier does allows people to not use the variable name as a descriptor of what it handles.
Nothing new about this as they've been around for a long time.
As a sysadmin myself we have set all computers to open .js files with notepad by default (rather than the Windows Scripting Engine) so they will not execute if opened accidentally.
It has read and execute. However, the JS file is not _executed_; it's _read_ by the interpreter. So an executable bit wouldn't matter as the file could still be read by any interpreter.
You can do, but because Linux has a mechanism for launching the correct interpreter which honours the +x bit it's unusual for anything to do this automatically, whereas on Windows associating interpreters with scripting formats is exactly the same as associating editors with document formats.
Amusingly this was changed with PowerShell in that .ps1 files do not have powershell.exe registered to run them when double-clicked. As a result people complain about it and resort to writing a .bat wrapper around the script.
This reminds me of some worm/virus/??? I'd see on people's computers back in the Kazaa days. It seemed like it would copy itself into the shared folder, picking filenames based on what was already there: e.g. Alanis Morisette - Ironic.mp3.js
I never looked at what its payload was. It's good to see that js viruses have also made their way to modern coding standards.
Why? JavaScript is just a language. A browser is just one platform it happens to run. Scripts running in a browser have certain restrictions. Scripts running directly on the host OS typically have unfettered access to the whole filesystem. If they're written in Python, batch, JavaScript, Ruby, etc... shouldn't have any role in deciding how much access the script has to the filesystem. Similarly if browsers were to support running Python that code shouldn't automatically have full filesystem access just based on the language it's written in.
Are variables being assigned multiple times needlessly here? What's going on, is that just obfuscation? Search the code for "this._hash.words" and have a look.
It's a bit of obfuscation, but mostly it takes advantage of the fact that `var` assignments are sequential to cram an entire MD5 block compression into a single `var` statement. Think of it simply as a long sequence of statements without the `var` prepended and it makes much more sense.
I've received several emails recently discussing a court order or some such, with a zip file attached containing a lone *.doc.js file. Of course I've never tried running it, but I do wonder if it's the same sort of thing.
Further, my university (University of Calgary) was recently hit by ransomware, and I have heard that some Calgary companies have also been hit by ransomware in the last 4-6 weeks. If the attack is this prevalent, and arguably this easy for non-expert users to accidentally execute over a whole network, I think we need to seriously consider how we train our users and what kinds of default permissions we allow.
Edit: For those who don't believe that JS can't be low-level, please see Wikipedia's definition of "low-level programming language"[1]:
"a programming language that provides little or no abstraction from a computer's instruction set architecture—commands or functions in the language map closely to processor instructions"
If you know literally anything about JavaScript, how it runs, or how processors run, you'll know that JS is not even in the ballpark of "low-level".
Perhaps the parent comment was referring to "JavaScript without frameworks, third-party libraries, or heavy abstractions," which is still not exactly a complex or mystifying arena.
Nit: asm.js (http://asmjs.org/) is low-level JavaScript - a subset of JavaScript which is explicitly compiled into equivalent machine code ahead-of-time by supporting browsers (and interpreted otherwise). asm.js imposes significant restrictions on JavaScript in order to produce efficiently compilable code, and its operations map almost 1:1 to machine instructions.
And as you correctly note, the ransomware code does not come close to qualifying as "low-level".
I received something like this in a spam email (I didn't get infected though), it was a fake 'court order' intended to be accidentally ran with the windows scripting engine, which has a JavaScript interpreter.
Good, now I'm going to be even more paranoid typing
` npm install `
` pod install `
And the likes.
You know, third party services which we wholeheartedly trust and let them execute whatever they download from github on our development machines.
Ransomware is very close to being a perfect crime and I don't see why people would ever stop doing it.
Expect it to become really widespread and evolved.
That being said, if you are developing and deploying ransomware, then you are doing a very wrong thing, spiritually.
You may not believe in karma, because it's convenient to you, but the message from our ancestors has always been this - all the shit that you cause in life is going to come back to you OR your children in one form or another - multiplied.
So just don't.
all the shit that you cause in life is going to come back to you OR your children in one form or another - multiplied.
Almost all worldviews share a similar idea, but that does not make it a proven fact. Ultimately, they are all premised on a omniscient and vindictive entity (either explicitly or implicitly). I'm of the opinion that these views originate more from a desire to soothe victims than to discourage offenders.
We should do better than vague threats to improve society.
This is quite a poetic and esoteric comment to read on a thread about JavaScript security exploits. It sounds like you may have just had a healthy dose of psychedelics (or perhaps just meditation) yourself.
I can't say that I believe in the existence of karma as I don't believe morality is absolute (nor do negative actions or consequences always stem from malicious intent). Science (and religion and spirituality for that matter) are not inherently "good" or "bad". They do reflect the will of humans, however, and that is what manifests in ways which we come to agree is either "good" or "bad". So when evil people reap what they sow, I would argue that it is not karma but retribution - either overt or as a reaction to one's own corrupting nature - that is at play.
In short, Windows completely exposes its filesystem through ActiveX and WScript, skipping the need to package Node for filesystem access. Then bundle native JS crypto along with some nasty string-encoded binaries, and you've got everything you need to hold a PC hostage.
Makes me wonder if there's a way to commit such evils with AppleScript and/or JavaScriptCore...
[0]: https://gist.github.com/Antelox/020c727e1917bd018441cb6425ca...
[1]: https://reaqta.com/2016/06/raa-ransomware-delivering-pony/