Caro lettore, il mining di criptovalute non è più una cosa nuova o sconosciuta ma ad ogni modo resto sempre stupito dalle pratiche illecite che i criminali informatici si inventano per minare a spese altrui.
Diversi giorni fa ho riscontrato dei carichi di lavoro abbastanza importanti su alcuni sistemi dovuti ad uno script che a prima vista poteva sembrare legato a WordPress ma che di fatto si è rivelato essere tutt’altro.
Con un banale ps wwauxf ho trovato questi processi:
utente1 20310 0.0 0.0 4276 740 ? Ss giu17 0:00 _ /bin/sh -c flock -w 0 ../path-precedente/wp-admin/wp-update.log -c "../path-precedente/wp-admin/wp-update -B -l /dev/null "
utente1 20318 0.0 0.0 10040 568 ? S giu17 0:00 _ flock -w 0 ../path-precedente/wp-admin/wp-update.log -c ../path-precedente/wp-admin/wp-update -B -l /dev/null
utente1 20320 0.0 0.0 4276 716 ? S giu17 0:00 _ /bin/sh -c ../path-precedente/wp-admin/wp-update -B -l /dev/null
utente1 20327 299 29.3 3014156 2401368 ? Sl giu17 4068:49 _ ../path-precedente/wp-admin/wp-update -B -l /dev/null
Con il comando:
file ../path-precedente/wp-admin/wp-updateho scoperto che il file wp-admin/wp-update altro non è che un eseguibile:
../path-precedente/wp-admin/wp-update: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=fa2b298d8c35b7f2116a4b24b4c98bae0716b12b, stripped
Quindi, di istinto ho dato un wp-admin/wp-update --help e la sorpresa è stata scoprire che di fatto l’eseguibile è un miner noto e opensource: XMRig
root@srv:/# ../path-precedente/wp-admin/wp-update --help
Usage: xmrig [OPTIONS]
Network:
-o, --url=URL URL of mining server
-a, --algo=ALGO mining algorithm https://xmrig.com/docs/algorithms
--coin=COIN specify coin instead of algorithm
-u, --user=USERNAME username for mining server
-p, --pass=PASSWORD password for mining server
-O, --userpass=U username:password pair for mining server
-x, --proxy=HOST:PORT connect through a SOCKS5 proxy
-k, --keepalive send keepalived packet for prevent timeout (needs pool support)
--nicehash enable nicehash.com support
--rig-id=ID rig identifier for pool-side statistics (needs pool support)
-r, --retries=N number of times to retry before switch to backup server (default: 5)
-R, --retry-pause=N time to pause between retries (default: 5)
--user-agent set custom user-agent string for pool
--donate-level=N donate level, default 5%% (5 minutes in 100 minutes)
--donate-over-proxy=N control donate over xmrig-proxy feature
CPU backend:
--no-cpu disable CPU mining backend
-t, --threads=N number of CPU threads
-v, --av=N algorithm variation, 0 auto select
--cpu-affinity set process affinity to CPU core(s), mask 0x3 for cores 0 and 1
--cpu-priority set process priority (0 idle, 2 normal to 5 highest)
--cpu-max-threads-hint=N maximum CPU threads count (in percentage) hint for autoconfig
--cpu-memory-pool=N number of 2 MB pages for persistent memory pool, -1 (auto), 0 (disable)
--cpu-no-yield prefer maximum hashrate rather than system response/stability
--no-huge-pages disable huge pages support
--asm=ASM ASM optimizations, possible values: auto, none, intel, ryzen, bulldozer
--randomx-init=N threads count to initialize RandomX dataset
--randomx-no-numa disable NUMA support for RandomX
--randomx-mode=MODE RandomX mode: auto, fast, light
--randomx-1gb-pages use 1GB hugepages for dataset (Linux only)
--randomx-wrmsr=N write custom value (0-15) to Intel MSR register 0x1a4 or disable MSR mod (-1)
--randomx-no-rdmsr disable reverting initial MSR values on exit
--astrobwt-max-size=N skip hashes with large stage 2 size, default: 550, min: 400, max: 1200
--astrobwt-avx2 enable AVX2 optimizations for AstroBWT algorithm
Logging:
-S, --syslog use system log for output messages
-l, --log-file=FILE log all output to a file
--print-time=N print hashrate report every N seconds
--no-color disable colored output
--verbose verbose output
Misc:
-c, --config=FILE load a JSON-format configuration file
-B, --background run the miner in the background
-V, --version output version information and exit
-h, --help display this help and exit
--dry-run test configuration and exit
All’interno della directory wp-admin di WordPress ho trovato 4 file legati al miner:
- wp-admin/wp-update
- wp-admin/wp-update.
- wp-admin/wp-update.log
- wp-admin/wp-update.php
Inoltre, sul sistema ho trovato anche un CRON che in automatico eseguiva i programmi malevoli presenti sul sistema.
Come risolvere?
Bella domanda in quanto ogni situazione è diversa. Di fatto, prima di iniziare a cercare la causa del problema, il sito non può restare online e va quindi sospeso.
Se si ha a disposizione un backup si può ripristinare il sito ad una situazione precedente al problema di sicurezza e aggiornare plugin e temi installati.
Se si è fortunati installando i nuovi aggiornamenti le falle che hanno permesso l’injection di codice malevolo sono state corrette dagli sviluppatori e forse la storia è finita qui.
Ad ogni modo il vero modo per risolvere il problema è analizzare il contenuto del sito e i relativi log di accesso delegando magari questa attività ad un professionista o una agenzia.