Jump to content

earthworm

Members
  • Posts

    68
  • Joined

  • Last visited

Posts posted by earthworm

  1. I'm really appreciating all the replies here.  My main goal was to bring attention to this issue and have people check their servers to ensure they haven't been compromised.  I doubt I'm the only one who has this problem.  It's possible it started with the CRON file and when that event fired it infected NGINX.

  2. I don't know.  I've been running jlesage/nginx-proxy-manager for years and haven't touched it since the initial configuration.  It may not even be related to that.  I've only noticed issues with the CRON files but dismissed them as being potentially file corruption and didn't think anything of it at that time.

     

    I run the sudo grep -al LD_L1BRARY_PATH /proc/*/environ | grep -v self/ command on the host directly and not from within a container.  Every time I run it I receive a new process ID.  I don't know if the process is restarting itself or if every instance is a new attack on my server.  There is never more than one process returned by this command.

     

    There's supposed to exist /dev/shm/php-shared but my /dev/shm folder is empty.  Not sure if this is normal for Unraid or not.

     

     

  3. I don't post much but I feel this is important to those using NGINX on their servers.

     

    Technical details are here:

    https://www.bleepingcomputer.com/news/security/new-malware-hides-as-legit-nginx-process-on-e-commerce-servers/

    or, more directly:

    https://sansec.io/research/cronrat

    https://sansec.io/research/nginrat

     

    Summary:

    A vulnerability in NGINX allows a threat actor to install a RAT running virtually undetectable on your server.  One of the options is for it to also hide in CRON with a date of Feb 31.

     

    I mention this because I believe my server got hit and it's very likely others could be vulnerable as well.  In the past I have noticed what I thought was a corrupt cron.d/root file and I've manually cleaned that file in the past.  Where I'm stumped is on how to clean the NGINX infestation.  I can identify the malicious processes and their solution is to just terminate them, however, every time I check, the process ID is different.

     

    If anyone else has detected this activity on their server, I would really like to find a way to permanently eradicate NginRAT from my server.  All I've done so far is block the payload IP address on my router.  I only discovered this issue today.

  4. 22 hours ago, J89eu said:

    Can this run on AMD GPUs? I have a Vega 56 and it seems the Windows app does work with GPU but perhaps not on Linux?

    I have 2 older AMD GPUs (5xxx, 6xxx) and neither of them has ever received a work unit which is disappointing because they would certainly be faster than any CPU I own.  My systems are running Windows.

  5. Something also happened to my server after upgrading to 6.6.

     

    Server was named storage but was renamed to storagemain for testing.

    Added DNS record so both storage and storagemain both point to the same IP.

     

    "ping storage" - works fine

    "ping storagemain" - works fine

    \\storagemain - works fine

    \\storage - FAILS

    http://storage/ - works fine

    http://storagemain/ - works fine

×
×
  • Create New...