New Ransomware Written Entirely In JavaScript (scmagazine.com)
An anonymous reader writes: Security researchers have discovered a new form of ransomware written entirely in JavaScript and using the CryptoJS library to encode a user's files. Researchers say the file is being distributed through email attachments, according to SC Magazine, which reports that "Opening the attachment kicks off a series of steps that not only locks up the victim's files, but also downloads some additional malware onto the target computer. The attachment does not visibly do anything, but appears to the victim as a corrupted file. However, in fact it is busy doing its dirty work in the background. This includes deleting the Windows Volume Shadow Copy so the encrypted files cannot be recovered and the ransomware is set to run every time Windows starts up so it can capture any new information."
"It's a little bit unusual to see an actual piece of ransomware powered by a scripting language," one security executive tells the magazine, which suggests disabling e-mail attachments that contain a JavaScript file.
"It's a little bit unusual to see an actual piece of ransomware powered by a scripting language," one security executive tells the magazine, which suggests disabling e-mail attachments that contain a JavaScript file.
https://it.slashdot.org/story/...
Why do browsers and email programs have -any- access to anything? Sandbox the fuckers and call it a day. The fact that they aren't is a sign that companies aren't concerned enough about the problem.
Bye!
What has it been, maybe three decades of this kind of thing? At some point, do we expect people to develop enough technical literacy to avoid this kind of problem?
Note that I'm not saying it is the user's fault. It is the fault of the people writing the ransomware, pure and simple. But it's like walking through the bad part of Philly at night flashing bling all over and being visibly drunk. Yes, it's the muggers fault when you get mugged... but it is still worth pointing out that maybe your choices made your risk be higher than it had to be.. That is not "victim blaming". It's victim helping.
Since malware has been around for a long time, it's pure wishful thinking to imagine it's going away any time soon. So, you have to protect yourself.
Running executable and/or scripted email attachments from NigerianPrice204@notmalware.ng or ThisIsBeckyFromAccounting@No.Really is not how you protect yourself. It's been 30+ years of this. The details change, but the problem remains. Maybe it's time for people to start learning.
So ... stupid question, what's stopping people from obtaining the ransomware, and messing around with it, modifying it?
If you believe in privacy, and believe you have "nothing to hide" at the same time, you're a goddammed idiot
Write once, debug everywhere.
Excuse me, but please get off my Pennisetum Clandestinum, eh!
That will help, but a more effective strategy is to find the breaker box and flip them all off and stuff.
However, be aware that the FBI can, and does, monitor the water flowing up to your house for subtle vibrations caused by voices and footsteps.
They do the same thing with natural gas.
They even put vibration sensors on the cable, telephone, and electrical lines that physically attach to your home from that pole out there.
The only real solution is to move out.
They will know you did, though.
It little behooves the best of us to comment on the rest of us.
A long white back, for a PhD project, a guy named Alexia (or previously Henry, the name the thesis was submitted under) Massalin, wrote an OS kernel called Synthesis. The aim there was to improve efficiency by using runtime code synthesis. In the modern world, along with sandboxing using processes and memory protection, given that we now have LLVM, it would be worth someone exploring an OS where binaries are more akin to the LLVM representation (or some high level representation), and importantly, there is no static list of kernel syscalls: rather at install time, a list of required syscalls is compiled, and possibly custom versions synthesised so that the process is restricted, at the binary level, to what it can access. Something like that. If you look at the system calls a process makes, how many of the available ones does it use? And of the calls that modify files, or use network sockets, how much of the potential of those calls actually gets used? What I am suggesting is basically using LLVM to enforce something close to the principle of least authority at the kernel syscall level using code synthesis.
John_Chalisque