Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Monday July 15 2019, @09:15AM   Printer-friendly
from the NASty dept.

QNAPCrypt is malware that specifically targets Linux based Network Attached Storage (NAS) file storage systems. This unusual breed of malware is currently in the wild and spreading via 15 separate campaigns.

NAS servers are an attractive target to ransomware authors for multiple reasons.

First, they often contain large amounts of important data, so people and companies will be more desperate to recover them than a typical client system.
Second, it is rare to deploy endpoint protections to them that watch for encryption activity, making it less likely to detect the malware before it has completed its business.

"What often happens in a ransomware attack would be that a desktop machine, which is Windows or OS X, would be compromised through an existing vulnerability or phishing campaign," [Chris Morales, head of security analytics at Vectra] explained. "Once the host is infected, malware is designed to propagate across user systems and encrypt network file servers that are connected to those systems. By targeting the network file server directly, it is highly likely the attack is circumventing detection by endpoint security tools that are monitoring for the local encryption behaviors."

The QNAPCrypt malware was initially stalled by Malware analysis tool company Intezer which took advantage of a design flaw in the generation of bitcoin wallets on the Command and Control (C2) server to effectively Denial-of-Service (DOS) the malware.

"[the C2 server] does not create a new wallet for each new victim in real time, but rather it pulls a wallet address from a fixed, predetermined list," explained the researchers.

Secondly, the list, being static, is also finite. "Once all of the wallets are allocated (or sent), the ransomware would not be able to continue its malicious operation in the victim's machine," they said.

This opened the door to Intezer being able to mount what was essentially a denial-of-service (DoS) attack by simulating the infection of more than 1,091 victims, forcing the attackers to run through their list of unique Bitcoin wallets to supply to their victims.

Once on a network, the malware attempts to scan and find NAS devices

Intezer determined that the initial attack vector for the campaigns is SSH brute-force attacks, so administrators should take care to update their credentials with strong passwords in order to avoid an infection.

Full Analysis of the QNAPCrypt Ransomware


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by zocalo on Monday July 15 2019, @10:57AM (6 children)

    by zocalo (302) on Monday July 15 2019, @10:57AM (#867138)
    Actually, the linked article in TFS doesn't even confirm whether this is specific to QNAP NAS appliances or if it is more generic (e.g. default SSH credentials) and could potentially target other vendor's appliances as well; QNAP is definitely not the only vendor with a Linux-based OS and a default login on SSH/HTTPS ports, and looping through a sequence of "admin/root" "admin/password" combos is trivial. At least Anomali seems to confirm that the "known vulnerabilities" as QNAP specific, but even so I certainly wouldn't make assumptions based on the use of "QNAP" in the name that this is absolutely limited to QNAP devices, let alone that it will remain that way.

    Also, I really liked the bit about Intezer simulating compromises and exhausting the pre-generated list of Bitcoin wallets; some good thinking there! You'd think malware writers would have already got wise to that kind of flaw after Marcus Hutchins crippled WannaCry just by registering a specific domain, but there you go. Expect lessons to be learnt pretty quickly though; next time dodging the bullet probably won't be so easy...
    --
    UNIX? They're not even circumcised! Savages!
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 0) by Anonymous Coward on Monday July 15 2019, @12:10PM (5 children)

    by Anonymous Coward on Monday July 15 2019, @12:10PM (#867151)

    You are correct but I would like to add that most QNAP boxes are BusyBox, not Linux.

    • (Score: 2) by RS3 on Monday July 15 2019, @01:00PM

      by RS3 (6367) on Monday July 15 2019, @01:00PM (#867163)

      > "BusyBox, not Linux"

      Huh? Not trying to be pedantic, but although many Linux distributions are simply referred to as "Linux", Linux is an OS kernel.

      BusyBox is a whole bunch of *nix utilities consolidated into one binary executable.

    • (Score: 2) by hendrikboom on Monday July 15 2019, @01:30PM (3 children)

      by hendrikboom (1125) Subscriber Badge on Monday July 15 2019, @01:30PM (#867173) Homepage Journal

      And what's the kernel busybox runs on? BSD?

      • (Score: 3, Funny) by choose another one on Monday July 15 2019, @01:54PM (2 children)

        by choose another one (515) Subscriber Badge on Monday July 15 2019, @01:54PM (#867182)

        > And what's the kernel busybox runs on? BSD?

        GNU

        • (Score: 3, Informative) by pTamok on Monday July 15 2019, @02:16PM

          by pTamok (3042) on Monday July 15 2019, @02:16PM (#867185)

          Errm, no. A major reason for Busybox's existence is to avoid the need to have 'a bunch' of separate GNU utility programs on a device, and as such Busybox does not depend upon the presence of GNU utilities. It is, nonetheless, GPL2 licenced [busybox.net]

          Quoting Busybox's README [busybox.net]:

          What is busybox:

              BusyBox combines tiny versions of many common UNIX utilities into a single
              small executable. It provides minimalist replacements for most of the
              utilities you usually find in bzip2, coreutils, dhcp, diffutils, e2fsprogs,
              file, findutils, gawk, grep, inetutils, less, modutils, net-tools, procps,
              sed, shadow, sysklogd, sysvinit, tar, util-linux, and vim. The utilities
              in BusyBox often have fewer options than their full-featured cousins;
              however, the options that are included provide the expected functionality
              and behave very much like their larger counterparts.

              BusyBox has been written with size-optimization and limited resources in
              mind, both to produce small binaries and to reduce run-time memory usage.
              Busybox is also extremely modular so you can easily include or exclude
              commands (or features) at compile time. This makes it easy to customize
              embedded systems; to create a working system, just add /dev, /etc, and a
              Linux kernel
          . Busybox (usually together with uClibc) has also been used as
              a component of "thin client" desktop systems, live-CD distributions, rescue
              disks, installers, and so on.

              BusyBox provides a fairly complete POSIX environment for any small system,
              both embedded environments and more full featured systems concerned about
              space. Busybox is slowly working towards implementing the full Single Unix
              Specification V3 (http://www.opengroup.org/onlinepubs/009695399/), but isn't
              there yet (and for size reasons will probably support at most UTF-8 for
              internationalization). We are also interested in passing the Linux Test
              Project (http://ltp.sourceforge.net).

        • (Score: 1, Interesting) by Anonymous Coward on Monday July 15 2019, @10:03PM

          by Anonymous Coward on Monday July 15 2019, @10:03PM (#867341)

          It does make you think, if you ran BusyBox on HURD would Stallman insist on you calling it HURD or BusyBox+HURD?

          Does remind me of a guy, with a stellar-looking resume and application, that talked himself out of a job when, during our interview with him, he kept insisting on calling it GNU/Linux, even after being informed that the stack he would be dealing with used BusyBox for the core utilities. Later, after a mention of how he would write a "systemd socket file" to solve a hypothetical problem, he was told that systemd was not running on the machines and could not be installed on them. He said, "Oh, I see the confusion, you are running a [finger quotes] B. S. D. Unix-like operating system [end finger quotes]. In that case I'd just install it from ports. It works just fine, I've done it before." My manager just got up and walked out. The email summarizing his thoughts on that candidate was a sight to behold.