OM onderzoekt CLoP-ransomwareaanval op datadeeltool MOVEit Transfer

Het Nederlandse Openbaar Ministerie onderzoekt 'een grootschalige datadiefstal' na de hack op MOVEit Transfer. Deze zakelijke software laat bedrijven data delen. Onder meer TomTom, Shell, elektriciteitsnetbeheerder TenneT en vakantieparkbeheerder Landal zijn slachtoffer van de aanval.

"De hack lijkt wereldwijd slachtoffers te hebben gemaakt bij vele bedrijven en (overheids)organisaties, schrijft het OM. Meerdere Nederlandse bedrijven en organisaties zijn slachtoffer. Het is niet duidelijk wat voor data de hackers hebben gestolen, maar het zou mogelijk om privégegevens gaan van klanten. Volgens TenneT werd de hack op 31 mei ontdekt. Hackersgroep CLoP claimt achter de aanval te zitten en zegt 'een grote hoeveelheid data' in handen te hebben.

Het Team High Tech Crime van de Nederlandse politie onderzoekt de aanval, samen met nationale en internationale partners. De politie doet verder geen uitspraken over specifieke gebruikers. Slachtoffers worden aangeraden zich te melden bij de cybercrimeteams van de politie in hun regio. Klanten van MOVEit Transfer krijgen het advies om de adviezen van maker Progress te volgen.

Het Nationaal Cyber Security Centrum waarschuwde begin juni over een lek binnen MOVEit, een SQL-injectiekwetsbaarheid waardoor aanvallers ongeautoriseerd toegang konden krijgen tot de database van een MOVEit-server. Toen waren er al vermoedens dat hackers data hadden gestolen. In Nederland zouden er 134 MOVEit-servers in gebruik zijn.

Reacties (9)

[SuperGuest]

SQL-Injection dat is wel heel ouderwets! Ik denk dan, hoe is dat in deze tijd nog mogelijk?

[MischaBoender]

Het was niet zo simple als "'OR 1=1; --" in een HTML form gooien, er zitten wel degelijk diverse levels van sanatization in het product.

Wat leesvoer voor de geïnteresseerden:
MOVEit Transfer CVE-2023-34362 Deep Dive and Indicators of Compromise
CVE-2023-36934 Analysis: MOVEit Transfer SQL Injection

[Guru Evi]

Het was inderdaad zo simpel als Email='<EmailAddress>' - het grootste probleem was dat ze via session cookies variabelen in het systeem zoals de huidige gebruiker kunnen veranderen, zelf zonder een ingelogde sessie kun je een cookie zenden met user = admin en het systeem aanvaart dit. Eenmaal je controle hebt over de database via e-mailadres kun je dan andere dingen toevoegen zoals authenticatie sessie die klaarblijkelijk in dezelfde database met dezelfde account en toegang als het publieke onderdeel draait en kan dus veranderen waar je systeem verwijst zonder verdere consultatie van vaste configuratievariabelen over welke systemen al dan niet mogen authenticeren. En dan mag diezelfde database user ook dingen in de database schrijven over welke jobs die het systeem (als admin) mag uitvoeren.

En dan deze: C:\MOVEitDMZ_Install.INI you will find cleartext credentials for the provisioned sysadmin account, database credentials, and the service credential.

Het zijn dus tenminste 5 grote ‘beginners’ fouten die op elkaar gestapeld worden om toegang te verschaffen. En onderzoekers hebben nu al, na slechts enkele weken onderzoek, meer zulke grote gaten gevonden in de gatenkaas. Je zou toch moeten aannemen dat een groot bedrijf met zulke klanten als de belastingdienst en Shell, genoeg geld heeft om 1 degelijke onderzoeker aan te nemen en het systeem jaarlijks of zelfs maandelijks te doorlichten.

[Reactie gewijzigd door Guru Evi op 23 juli 2024 21:01]

[Sluuut]

Dat hebben ze ook vast wel, periodieke externe & interne scans, maar daarmee vang je natuurlijk niet 100% af.

Wat ik vaak hoor van de Pen-testers is dat ze gewoon een standaard set doorlopen van +-2 dagen, en dat het rapport dan opgeleverd word. Ze geven aan dat ze heel graag zelf ook nog 1 dag zouden krijgen om op hun eigen manier (social engineering, eigen onbekende exploits etc) binnen proberen te komen, maar dat zowel het consultancy bedrijf als b.v. Shell daar geen gehoor aan geven. Ik vind dat zonde, want juist met dat laatste (kennis die niet persé vastgelegd is in de theorie papieren) komt een hacker binnen.

[Keyb]

Omdat lang niet alle ontwikkelaars de kennis in huis hebben. Omdat er niet genoeg resources worden vrijgemaakt om daar de benodigde aandacht aan te besteden. Om er maar 2 te noemen. Er zijn zelfs tools, static code analyzers, die het redelijk goed kunnen detecteren. Maar dat soort tools in je ontwikkelstraat inrichten is nog lange na geen onderdeel van de werkzaamheden bij veel bedrijven.

[Guru Evi]

MoveIT is groot en duur genoeg om een beetje investeringen te verantwoorden. Het is een systeem dat SSH gebruikt om data te versturen maar een webserver die op Windows draait voor de configuratie en waarempel gebruiken dezelfde instantie om status te coördineren (ipv SSH te gebruiken of een aparte poort) zodat je volgens de documentatie zowel het admin-web+status-web als SSH portie bloot moet stellen aan het web.

Echter, sinds wij ook MoveIT klanten waren, toen we de web-poort dichtslaan bleef alles gewoon werken, dus in principe heb je de web-poort enkel nodig voor status API, eenmaal een systeem opgezet is is de web-poort voor de meeste mensen overbodig alhoewel de MoveIT documentatie zegt dat alle jobs gecoördineerd worden over de web-poort.

Daarnaast wisten ze al 3 dagen voor het publiek werd dat er een probleem was omdat klanten zoals ons zeiden dat het systeem opeens data begon te verzamelen, het heeft hun bijna een week geduurd om dit aan hun klanten toe te geven en nu weken later blijven ze maar zeggen dat ze het probleem opgelost hebben terwijl we nu al aan 5 15 CVEs zitten dit jaar.

Dit is een klassiek probleem van software die exclusief voor/door grote bedrijven, banken en overheid gebruikt wordt, ze woekeren met een ondermatig product waar vanwege de overheidscontracten geen kans voor concurrentie of alternatief zit en als er iets grootschalig verkeerd gaat doen ze alsof hun neus bloedt en wijzen ze de vinger naar de ‘boogieman’ van vandaag.

[Reactie gewijzigd door Guru Evi op 23 juli 2024 21:01]

[Keyb]

MoveIT is groot en duur genoeg om een beetje investeringen te verantwoorden.

Ben ik geheel en al met je eens. Hopelijk gaf ik niet het idee dat ik het een goed excuus vond voor dit soort bedrijven.

Als ik die code bekijk (die @MischaBoender hierboven linkt, lijkt het er een beetje op dat ze zelf wat aandacht hebben getracht te spenderen aan het sanitizen van input strings (die vanuit de boze buitenwereld komen). Leuk, maar geen alternatief voor bijv. het gebruik maken van parametrized queries. Correct me if I'm wrong, maar het geen gebruik maken van parametrized queries is wel een grote rode vlag.

[Reactie gewijzigd door Keyb op 23 juli 2024 21:01]

[nullbyte]

Ouderwets? NIet echt, SQL injection staat op plek 3 in de Mitre CWE (Common Weakness Enumeration) van 2023.

https://cwe.mitre.org/top...2023/2023_top25_list.html

[Jerie]

En hackergroep Clop is, 3x maal raden, tromgeroffel... Russisch.

Clop is a Russian ransomware gang known for demanding multimillion dollar payments from victims before publishing data it claims to have hacked.

Aldus CNN.

Hopelijk zitten de figuren zelf in landen waar wij of VS of andere landen met slachtoffers uitleveringsverdragen hebben. Maar je kunt er vergif op innemen een kopje thee op toasten dat ze in Rusland zitten, tussen alle andere foute criminele mannekes die Poetin de hand boven het hoofd houdt.