4 ms·

First Node.js-Based Ransomware: Nodera

62 points by el_duderino 7y ago

fludlight 7y ago
Most languages, distros, large applications, etc have their own packaging system. Some are more laissez-faire than others. Does someone know a good article from the POV of the maintainer of a packaging system ecosystem that describes the tradeoffs made by different approaches over the past ~30 years?
- hiccuphippo 7y ago
  There was a few articles about go's search for a new package system from 2018. Edit: See https://blog.golang.org/versioning-proposal https://blog.golang.org/versioning-proposal and related articles at the bottom.
- asdfasgasdgasdg 7y ago
  To be clear, as far as I can tell, the ransomware is built using nodejs. It is not a ransomware that's installed via a compromised package. Although if you happen to be a bad guy, it seems like building a quality bitcoin-related package, waiting until you have a big installed base, and then owning all your users, might be an effective way to set yourself up for life.
  - carlmr 7y ago
    I thought Bitcoin can't effectively be mined on CPUs anymore, only some AltCoins that are too difficult to compute with ASICs
    - Wowfunhappy 7y ago
      Well, yes, but "effective" is context-dependent. If you have a million computers mining for you, and you're not paying their electricity, it doesn't really matter how individually efficient they are.
    - asdfasgasdgasdg 7y ago
      I'm not talking about a miner. I'm talking about a wallet or some utility module. You'd wait until you have a big installed base then change your module to silently steal coinbase credentials. Wait a few weeks until you have enough of them and then own all the accounts at once. Something like that. The Bitcoin aspect of the module is just to target effectively.
  - weare138 7y ago
    >as far as I can tell,the ransomware is built using nodejs Oddly enough, that's what it is. It even drops a full 17MB copy of nodejs to run it and just renames the executable.
    - aussieguy1234 7y ago
      Node processes can also be renamed on the fly, process.name
robertkrahn01 7y ago
Site is currently down; https://web.archive.org/web/20200122181519/https://blogs.quickheal.com/first-node-js-based-ransomware-nodera/ https://web.archive.org/web/20200122181519/https://blogs.qui... The article mentions the ransom message with the date March 1 2018. This probably means this malware is two years old?
- ecmascript 7y ago
  Ironically, the archive link you provided also doesn't load for me.
  - deleted 7y ago
    [deleted]
  - msla 7y ago
    If it's just a blank screen, it's a longstanding issue nobody seems to acknowledge: https://news.ycombinator.com/item?id=21765389 https://news.ycombinator.com/item?id=21765389 > There's a problem with the Wayback Machine in specific which can kill your ability to access it quite silently, unless you know how to use the browser's development tools and interpret headers. > It has to do with cookies: Somehow, the Wayback Machine sets cookies... and sets cookies... and keeps setting cookies, until it overflows its own ability to accept cookies. At that point, your browser tries to access a Wayback Machine page, handing the server all of the cookies it currently has, and the server refuses to deal. It absolutely denies everything, sending an error header and a blank page. You have to clear all web.archive.org cookies to get anything at all, at which point it works perfectly. > I've completely solved this problem by blacklisting web.archive.org in browser cookie blacklists. I haven't had it happen since then. As far as I'm concerned, the problem is diagnosed and just needs to be solved. At their end.
- grammarxcore 7y ago
  > This ransomware seems to be in development phase and has some flaws as mentioned below: > ... > Hard code destruction time of Private Key “March 1 2018”. Quite possibly. I'm not sure what that language means and they don't provide more analysis of the HTML page that comes from. If it's in development maybe some dude has been sitting on this idea for a few years and their virus scanner just picked it up recently.
asdfasgasdgasdg 7y ago
One of these modules' owners should update their modules to check if they are running as part of the ransomware, and kill the program if so. That would certainly be an interesting turn of events.
duxup 7y ago
So as I read it this is ransomware that was built using nodejs... not a compromised npm package or anything like that. Is that right?
- grammarxcore 7y ago
  That's what I took away from the article as well. It's installed via a VBScript file. Edit: I'm also not able to find any other record of it (yet). Everything links to the OP link or analysis on the OP link.
jlv2 7y ago
"The sample received in our lab was vbs script which has multiple embedded js scripts. On execution, it creates a directory “GFp0JAk” at location “%userprofile%\AppData\Local\”." Why is this even possible?
- carlmr 7y ago
  Can't everybody write to their own user's AppData folder?
  - judge2020 7y ago
    Yes, but it's not granular per-application [i believe]. On an install script you can create folders in %localappdata% without needing elevated permissions meaning that %localappdata% and any files/folders you create are owned by the current user; unless a script does something with the file permissions, any other application can scan, access, and modify other applications (same goes for all of your user files but that's just par for the course for win32).
- penagwin 7y ago
  If applications can't write to the Application Data folder then what's the point of an application data folder? > Why is this even possible? Well they said "on execution" so that's what made it possible. Now if it could install to that location without being explicitly executed (say on download or via a browser bug) then THAT would be a much bigger deal.
  - zamadatix 7y ago
    It's not so much the "applications can write data to application data" as it is "application data is executable by default". It's simply a design choice from before security was important. Nobody would defend that design today and Microsoft recognized this when they created appx which separates installers, executable programs, and data into separate content types treated with separate security policy.
krinchan 7y ago
I wonder how long until instead of installing itself it finds and infects an existing Electron app?
nikkwong 7y ago
Count me in as being one who is disappointed that the code is not being made available. I know releasing it to the public is inherently dangerous, but, I can't help but to be curious as to how these programs work top to bottom.
- zamadatix 7y ago
  https://send.firefox.com/download/29f34c9a6a4a30b6/#RBSP9jz2K5FpiieaUKUpyA https://send.firefox.com/download/29f34c9a6a4a30b6/#RBSP9jz2... password hackernews. I've set it to the maximum option of 100 downloads so it won't last forerver but should last long enough.
CapacitorSet 7y ago
Interestingly enough the JS source is not obfuscated, merely minified with no name mangling.

62 points by el_duderino 7y ago

Most languages, distros, large applications, etc have their own packaging system. Some are more laissez-faire than others. Does someone know a good article from the POV of the maintainer of a packaging system ecosystem that describes the tradeoffs made by different approaches over the past ~30 years?

hiccuphippo 7y ago
There was a few articles about go's search for a new package system from 2018. Edit: See https://blog.golang.org/versioning-proposal https://blog.golang.org/versioning-proposal and related articles at the bottom.
asdfasgasdgasdg 7y ago
To be clear, as far as I can tell, the ransomware is built using nodejs. It is not a ransomware that's installed via a compromised package. Although if you happen to be a bad guy, it seems like building a quality bitcoin-related package, waiting until you have a big installed base, and then owning all your users, might be an effective way to set yourself up for life.
- carlmr 7y ago
  I thought Bitcoin can't effectively be mined on CPUs anymore, only some AltCoins that are too difficult to compute with ASICs
  - Wowfunhappy 7y ago
    Well, yes, but "effective" is context-dependent. If you have a million computers mining for you, and you're not paying their electricity, it doesn't really matter how individually efficient they are.
  - asdfasgasdgasdg 7y ago
    I'm not talking about a miner. I'm talking about a wallet or some utility module. You'd wait until you have a big installed base then change your module to silently steal coinbase credentials. Wait a few weeks until you have enough of them and then own all the accounts at once. Something like that. The Bitcoin aspect of the module is just to target effectively.
- weare138 7y ago
  >as far as I can tell,the ransomware is built using nodejs Oddly enough, that's what it is. It even drops a full 17MB copy of nodejs to run it and just renames the executable.
  - aussieguy1234 7y ago
    Node processes can also be renamed on the fly, process.name

robertkrahn01 7y ago

Site is currently down; https://web.archive.org/web/20200122181519/https://blogs.quickheal.com/first-node-js-based-ransomware-nodera/ https://web.archive.org/web/20200122181519/https://blogs.qui... The article mentions the ransom message with the date March 1 2018. This probably means this malware is two years old?

ecmascript 7y ago
Ironically, the archive link you provided also doesn't load for me.
- deleted 7y ago
  [deleted]
- msla 7y ago
  If it's just a blank screen, it's a longstanding issue nobody seems to acknowledge: https://news.ycombinator.com/item?id=21765389 https://news.ycombinator.com/item?id=21765389 > There's a problem with the Wayback Machine in specific which can kill your ability to access it quite silently, unless you know how to use the browser's development tools and interpret headers. > It has to do with cookies: Somehow, the Wayback Machine sets cookies... and sets cookies... and keeps setting cookies, until it overflows its own ability to accept cookies. At that point, your browser tries to access a Wayback Machine page, handing the server all of the cookies it currently has, and the server refuses to deal. It absolutely denies everything, sending an error header and a blank page. You have to clear all web.archive.org cookies to get anything at all, at which point it works perfectly. > I've completely solved this problem by blacklisting web.archive.org in browser cookie blacklists. I haven't had it happen since then. As far as I'm concerned, the problem is diagnosed and just needs to be solved. At their end.
grammarxcore 7y ago
> This ransomware seems to be in development phase and has some flaws as mentioned below: > ... > Hard code destruction time of Private Key “March 1 2018”. Quite possibly. I'm not sure what that language means and they don't provide more analysis of the HTML page that comes from. If it's in development maybe some dude has been sitting on this idea for a few years and their virus scanner just picked it up recently.

asdfasgasdgasdg 7y ago

One of these modules' owners should update their modules to check if they are running as part of the ransomware, and kill the program if so. That would certainly be an interesting turn of events.

duxup 7y ago

So as I read it this is ransomware that was built using nodejs... not a compromised npm package or anything like that. Is that right?

grammarxcore 7y ago
That's what I took away from the article as well. It's installed via a VBScript file. Edit: I'm also not able to find any other record of it (yet). Everything links to the OP link or analysis on the OP link.

jlv2 7y ago

"The sample received in our lab was vbs script which has multiple embedded js scripts. On execution, it creates a directory “GFp0JAk” at location “%userprofile%\AppData\Local\”." Why is this even possible?

carlmr 7y ago
Can't everybody write to their own user's AppData folder?
- judge2020 7y ago
  Yes, but it's not granular per-application [i believe]. On an install script you can create folders in %localappdata% without needing elevated permissions meaning that %localappdata% and any files/folders you create are owned by the current user; unless a script does something with the file permissions, any other application can scan, access, and modify other applications (same goes for all of your user files but that's just par for the course for win32).
penagwin 7y ago
If applications can't write to the Application Data folder then what's the point of an application data folder? > Why is this even possible? Well they said "on execution" so that's what made it possible. Now if it could install to that location without being explicitly executed (say on download or via a browser bug) then THAT would be a much bigger deal.
- zamadatix 7y ago
  It's not so much the "applications can write data to application data" as it is "application data is executable by default". It's simply a design choice from before security was important. Nobody would defend that design today and Microsoft recognized this when they created appx which separates installers, executable programs, and data into separate content types treated with separate security policy.

krinchan 7y ago

I wonder how long until instead of installing itself it finds and infects an existing Electron app?

nikkwong 7y ago

Count me in as being one who is disappointed that the code is not being made available. I know releasing it to the public is inherently dangerous, but, I can't help but to be curious as to how these programs work top to bottom.

zamadatix 7y ago
https://send.firefox.com/download/29f34c9a6a4a30b6/#RBSP9jz2K5FpiieaUKUpyA https://send.firefox.com/download/29f34c9a6a4a30b6/#RBSP9jz2... password hackernews. I've set it to the maximum option of 100 downloads so it won't last forerver but should last long enough.

CapacitorSet 7y ago

Interestingly enough the JS source is not obfuscated, merely minified with no name mangling.