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.
Beleidsmedewerker Informatiebeveiliging en Privacy
Scholenkoepel RVKO is voor haar bestuursbureau op zoek naar een beleidsmedewerker Informatiebeveiliging en Privacy (IBP), die het voldoen aan de wet- en regelgeving ten aanzien van informatiebeveiliging en privacy, zoals de AVG, organiseert en borgt.
Security Trainer
Ben jij een trainer die het leuk vindt om je hacker mindset en security-skills over te dragen aan anderen? Zie jij het als een uitdaging om hands-on securitytrainingen te verzorgen voor een divers publiek en zijn kritische vragen en eigenwijze techneuten voor jou geen probleem? Dan zoeken wij jou!
Are you ready for a challenge?