Ontwikkelaar M.E.Doc bevestigt backdoor in update
Het Oekraïense softwarebedrijf dat de belasting- en boekhoudsoftware M.E.Doc ontwikkelt heeft bevestigd dat aanvallers kwaadaardige code aan een update hebben toegevoegd waardoor de Petya-ransomware werd geïnstalleerd. In eerste instantie ontkende het bedrijf nog dat aanvallers de software van het bedrijf hadden gebruikt om de Petya-ransomware te installeren. Op Facebook bevestigt het bedrijf nu dat het slachtoffer van een hack is geweest.
Eerder ontdekten onderzoekers van anti-virusbedrijf ESET al dat aanvallers een backdoor aan een update voor M.E.Doc hadden toegevoegd die op 22 juni uitkwam. Het softwarebedrijf laat weten dat het een update heeft ontwikkeld die het probleem moet verhelpen. De servers van het softwarebedrijf zijn echter door de politie in beslag genomen, waardoor de update die de problemen verhelpt en nieuwe aanvallen moet voorkomen nog niet kan worden uitgerold. De Oekraïense politie adviseert op Facebook om M.E.Doc tijdelijk niet te gebruiken en computers waarop het is geïnstalleerd los te koppelen van het netwerk.
Zoiets moet toch opvallen... ikzelf werk veel met git en jira en toevoegingen aan je codebase zie je meteen.
Zoiets moet toch opvallen... ikzelf werk veel met git en jira en toevoegingen aan je codebase zie je meteen.
Als ze het hebben aangepast, en gecommit - kan je het over het hoofd zien. in theorie.
Zoiets moet toch opvallen... ikzelf werk veel met git en jira en toevoegingen aan je codebase zie je meteen.
Dan ga je ervan uit dat ze in de source code kunnen. Maar wat nu als ze gewoon de binary van de update server downloaden, decompilen, code toevoegen, en weer uploaden? Dan hack je de upload server.
Of ze moeten de logfiles van de update server nakijken. Of met checksum files werken.
Er zijn vele manieren om extra code toe te voegen....
TheYOSH
Zoiets moet toch opvallen... ikzelf werk veel met git en jira en toevoegingen aan je codebase zie je meteen.
Als er 1 van gehackt is gaat het zo mee.
Als de achterliggende data achter git open staat heb je een ander potentieel lek.
Je moet niet denken vanuit jouw normaal gebruik maar als inventieve Hacker die het net anders doet.
lees dan is dat zelfs onwaarschijnlijk (2 versies die besmet waren, daarna een versie die niet besmet was, daarna
weer een besmette versie).
Ik denk dat het waarschijnlijker is dat iemand die toegang had tot de build- of update server een patch op de code
aanbracht en dan compileerde, en vervolgens die patch weer weghaalde zodat het niet opviel.
Kennelijk is er niemand die controleerde of de exe files wel onveranderd bleven na door de normaal bevoegde persoon
neer gezet te zijn.
TheYOSH
Ook het meest waarschijnlijk. Via git zelf is zeer onwaarschijnlijk als je de eerdere berichten leest. Er zijn nml 3 besmette versies in omloop gebracht, maar tussendoor weer onbesmette versies. De code basis was dus niet besmet, anders was elke volgende versie besmet geweest.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Docenten en docentonderzoekers Cyber Security
Wil jij ICT-studenten wegwijs maken in de snel veranderende wereld van IT-beveiliging? Wil jij samen met onderzoekers en praktijkpartners onderzoek doen op het gebied van praktijkgerichte cyber security? De Hogeschool van Amsterdam is voor de opleiding HBO-ICT op zoek naar meerdere enthousiaste fulltime en parttime docenten en docentonderzoekers Cyber Security.
Teamcoördinator HBO ICT
Wil jij je samen met een gespecialiseerd team van Cyber Security docenten inzetten voor grensverleggend onderwijs op het gebied van een maatschappelijk zeer relevant onderwerp binnen ICT? Dan zoeken wij jou!
Ransomware voorkomen? Begrijpen waarom je niet overal hetzelfde wachtwoord moet gebruiken? Met eigen ogen zien waarom updaten zo belangrijk is? Ontwaak je Hacker Mindset met de Certified Secure Security Awareness Experience - LIVE Online!