Hacker News Reader

Comment by fny | Hacker News Reader

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...

[0]: https://gist.github.com/Antelox/020c727e1917bd018441cb6425ca...

[1]: https://reaqta.com/2016/06/raa-ransomware-delivering-pony/

View on HN

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.

This. South Korea's insistence on using 2001 technologies today has made Windows almost unmanageable in a highly secure environment.

Can't you block ActiveX altogether through GP? I mean... doesn't help if you're in Korea, but for the rest of us.

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.

Those variable names though.

it's beautified from obfuscated code. it's understandable.

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.

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.

It's probably not so much a minifier than an obfuscator.

Reply on news.ycombinator.com