Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Monday November 18 2019, @05:47PM   Printer-friendly
from the keep-up-with-updates dept.

New NextCry Ransomware Encrypts Data on NextCloud Linux Servers

A new ransomware has been found in the wild that is currently undetected by antivirus engines on public scanning platforms. Its name is NextCry due to the extension appended to encrypted files and that it targets clients of the NextCloud file sync and share service.

The malware targets Nextcloud instances and for the time being there is no free decryption tool available for victims.

xact64, a Nextcloud user, posted on the BleepingComputer forum some details about the malware in an attempt to find a way to decrypt personal files.

Although his system was backed up, the synchronization process had started to update files on a laptop with their encrypted version on the server. He took action the moment he saw the files renamed but some of them still got processed by NextCry, otherwise known as Next-Cry.

“I realized immediately that my server got hacked and those files got encrypted. The first thing I did was pull the server to limit the damage that was being done (only 50% of my files got encrypted)” - xact64

Looking at the malware binary, Michael Gillespie said that the threat seems new and pointed out the NextCry ransomware uses Base64 to encode the file names. The odd part is that an encrypted file's content is also encoded this way, after first being encrypted.

The malware has not been submitted to the ID Ransomware service before but some details are available. BleepingComputer discovered that NextCry is a Python script compiled in a Linux ELF binary using pyInstaller. At the moment of writing, not one antivirus engine on the VirusTotal scanning platform detects it.

[...] Another Nexcloud user named Alex posted on the platform’s support page about being hit by NextCry ransomware​​​​​​. They say that access to their instance had been locked via SSH and ran the latest version of the software, suggesting that some vulnerability was exploited to get in.

In a conversation with BleepingComputer xact64 said that their Nextcloud installation runs on an old Linux computer with NGINX. This detail may provide the answer to how the attacker was able to get access.

“I have my own linux server (an old thin client I gave a second life) with nginx reverse-proxy” - xact64

On October 24, Nextcloud released an urgent alert about a remote code execution vulnerability that impacts the default Nextcloud NGINX configuration.

Tracked as CVE-2019-11043, the flaw is in the PHP-FPM (FastCGI Process Manager) component, included by some hosting providers like Nextcloud in their default setup. A public exploit exists and has been leveraged to compromised servers.


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: 3, Informative) by edIII on Tuesday November 19 2019, @12:18AM

    by edIII (791) on Tuesday November 19 2019, @12:18AM (#921766)

    The important details [github.com]:

    The full list of preconditions

    1. Nginx + php-fpm, location ~ [^/]\.php(/|$) must be forwarded to php-fpm (maybe the regexp can be stricter, see #1).
    2. There must be a PATH_INFO variable assignment via statement fastcgi_param PATH_INFO $fastcgi_path_info;. Also SCRIPT_FILENAME must be set using fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; (there might be a constant path instead of $document_root). At first, we thought these are always present in the fastcgi_params file, but it's not true.
    3. There must be a way to set PATH_INFO to an empty value. This exploit assumes that fastcgi_split_path_info directive is there and contains a regexp starting with ^ and ending with $, so it tries to break the regexp with a newline character.
    4. This particular exploit assumes that PATH_INFO is set after REQUEST_URI in the config.
    5. No file existence checks like try_files $uri =404 or if (-f $uri). If Nginx drops requests to non-existing scripts before FastCGI forwarding, our requests never reach php-fpm. Adding this is also the easiest way to patch.
    6. This exploit works only for PHP 7+, but the bug itself is present in earlier versions (see below).

    Just check your main config or all includes and make sure the try_files directive is being used.

    --
    Technically, lunchtime is at any moment. It's just a wave function.
    Starting Score:    1  point
    Moderation   +1  
       Informative=1, Total=1
    Extra 'Informative' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3