Botmasters hebben de lessen geleerd van het ontwikkelen van Internet of Things (IoT) malware en hebben hun focus verlegd naar het targeten van standaard Linux-servers. Zoals veel IoT-apparaten, blijven niet-gepatchte Linux-servers zitten op het netwerk en deze worden op grote schaal misbruikt door aanvallers om exploits naar elke kwetsbare server die ze kunnen vinden te verzenden. ASERT, het Security Engineering & Response Team van Arbor Networks, heeft exploitpogingen voor de Hadoop YARN-kwetsbaarheid in ons honeypot-netwerk gevolgd en een bekende, maar verrassende payload gevonden: Mirai. Deze versies van Mirai gedragen zich ongeveer zoals het origineel, maar zijn op maat gemaakt om op Linux-servers te draaien en niet zozeer op IoT-apparaten die zeer weinig stroom verbruiken. Alhowel ASERT eerder over observaties van Windows Mirai publiceerde, is dit de eerste keer dat we non-IoT Mirai in 'het wild' gezien hebben.
Belangrijkste bevindingen over Mirai
- Mirai-botmasters die gericht zijn op Linux-servers, hoeven de malware niet langer aan te passen voor onbekende architecturen, maar nemen simpelweg aan dat hun aanvalsdoelen x86 gebruiken.
- In plaats van te vertrouwen op de bots die verspreid moeten worden, hebben de aanvallers de tactiek veranderd naar het zelf uitgeven van exploits. Een relatief klein aantal aanvallers gebruikt aangepaste hulpmiddelen om de Hadoop YARN-kwetsbaarheid te misbruiken en Linux-malware te leveren.
- Zelfs als de Hadoop YARN-server van het slachtoffer niet de telnet-service gebruikt, probeert de Mirai-bot standaard fabrieksreferenties via telnet te forceren.
- Linux-servers in datacenters hebben toegang tot meer bandbreedte dan IoT-apparaten op residentiële netwerken, waardoor de DDoS-bots veel efficiënter zijn. Een handvol goed uitgeruste Linux-servers kan aanvallen genereren die concurreren met een veel groter IoT-botnet.
De kwetsbaarheid van de Hadoop YARN is relatief eenvoudig: een fout in de command injection waardoor de aanvaller willekeurige shell-commands kan uitvoeren. Vorige maand ontdekte Radware dat dit beveiligingslek werd gebruikt om de DemonBot DDoS-bot te installeren. In veel opzichten is deze fout vergelijkbaar met die van anderen waarvan we zagen dat deze misbruikt worden in IoT-apparaten. CVE-2014-8361 bijvoorbeeld, een fout in de UPnP SOAP-interface van Realtek, kan bijvoorbeeld ook misbruikt worden door een HTTP-verzoek naar een speciale poort te sturen met specifieke parameters om de uitvoering van shell-commands te bewerkstelligen. Deze Realtek-kwetsbaarheid werd gebruikt om een Mirai-variant af te leveren.
Het is verrassend dat zoveel exploitpogingen worden geleverd door slechts een handvol unieke bronnen. De grafiek hieronder toont het aantal unieke source IP-adressen die de Hadoop YARN-exploit over dezelfde tijdsperiode leveren.
Als we naar de top 5 user-agents kijken die deze exploits leveren, zien we dat de aanvallers de Python-requests library gebruiken om de HTTP-payload te leveren.
Het enorme aantal exploitpogingen afkomstig van een beperkt aantal bronnen, in combinatie met het feit dat geen van de malware-payloads die we hebben gezien op een worm-achtige manier tracht te verspreiden met behulp van de Hadoop YARN-exploit, en geen van de payloads is geschreven in Python, brengt ons ertoe te speculeren dat een klein aantal aanvallers handmatig het internet scannen om dit beveiligingslek te misbruiken.
De exploit payloads die we gezien hebben zoals hieronder weergegeven, zijn allemaal identiek qua functionaliteit: haal een malware binair getal uit een URL en voer het uit.
Wat wel verschilt is welke malware wordt afgeleverd in de exploit. Voor de maand november hebben we 225 unieke binaire bestanden afgeleverd. Meer dan de helft (152) van de binaries worden afgeleverd door slechts één source address. Minstens tientallen van de samples die we onderzochten zijn overduidelijk varianten van Mirai.
Laten we ons concentreren op een Mirai-variant die zichzelf "VPNFilter" noemt (2bcca8ac8d4d80f6740ef14d521284c0, zoals hierboven weergegeven), ookal heeft dit niets te maken met de meer geavanceerde IoT-bot. Op ons honeypot-netwerk zagen we deze exploit geleverd worden door twee source adressen op 16 november - 185.244.25.241 en 104.248.170.199. De command-and-control-site voor deze bot is hetzelfde IP-adres dat het binaire bestand host.
Deze specifieke variant verschilt op een belangrijke manier van een IoT Mirai - het levert alleen de x86-versie van de bot. IoT Mirai-varianten zullen een potentieel slachtoffer blijven rondtikken om een uitvoerbaar bestand te leveren dat geschikt is voor de CPU-architectuur - x86, x64, ARM, MIPS, ARC, etc. Deze versie gaat ervan uit dat de Hadoop YARN-service wordt uitgevoerd op een x86-Linux-server.
Toen we de "VPNFilter" -variant in een sandbox draaiden, merkten we meteen dat het nog steeds probeert om default usernames en wachtwoorden te brute-forcen via telnet. Als het met succes een kwetsbaar apparaat vindt, in plaats van rechtstreeks de malware op het slachtoffer te installeren, wordt het IP-adres, de gebruikersnaam en het wachtwoord gerapporteerd aan een reporting server, waar de aanvaller de installatie van de bot kan automatiseren.
Conclusie: Volledig aangedreven Linux-servers tussen de kleine, luttele apparaten
Mirai richt zich niet langer uitsluitend op IoT-apparaten. Hoewel de technieken die worden gebruikt om Mirai aan zowel IoT- als Linux-servers te leveren vergelijkbaar kunnen zijn, is het voor aanvallers veel gemakkelijker om de x86-monocultuur van Linux-servers aan te vallen dan de brede reeks van CPU's die op IoT-apparaten worden gebruikt. Het beperkte aantal bronnen dat we continu hebben zien scannen naar de Hadoop YARN kwetsbaarheid kan erop duiden dat deze activiteit het werk is van een kleine groep aanvallers. Hun doel is duidelijk - om de malware op zoveel mogelijk apparaten te installeren. Zodra het voet aan de grond krijgt, gedraagt Mirai zich op een Linux-server net als een IoT-bot en begint het met brute dwingende telnet-gebruikersnamen en -wachtwoorden. Het verschil is nu dat van de kleine, luttele apparaten in het botnet volledig gevoede Linux-servers op de loer liggen.
