XZ-backdoor verbergt public key via x86-gebaseerde steganografie
De backdoor in datacompressietool XZ die eerder dit jaar werd ontdekt maakt gebruik van x86-gebaseerde steganografie voor het verbergen van de public key en past een anti-replay feature toe om te voorkomen dat de communicatie naar de backdoor wordt onderschept en opnieuw gebruikt. Dat meldt antivirusbedrijf Kaspersky in een analyse.
XZ is een tool voor het inpakken en uitpakken van bestanden en is in allerlei Linux-distributies aanwezig. Een aanvaller probeerde over een lange tijd het vertrouwen te winnen van de maintainer van het XZ-project, om vervolgens een backdoor aan de code toe te voegen. Na de ontdekking van de backdoor werd al gauw duidelijk dat die zeer geavanceerd was.
Om de payload data te ontsleutelen en verifiëren gebruikt de backdoor een public key die het uit de binary haalt. De onderzoekers van Kaspersky wisten in eerste instantie niet hoe de public key werd gegenereerd. "Het leek alsof de backdoormakers code hadden ontwikkeld die voor de private key een correcte public key genereerde, wat onmogelijk zou moeten zijn." Verder onderzoek naar de backdoorcode wees uit dat keys via een reguliere procedure werden gegenereerd.
De aanvallers gebruikten zelfgemaakte steganografie in de x86-code om een willekeurig bericht te verbergen, wat in dit geval de public key was. "De public key-informatie was verspreid binnen de binary code binnen specifieke geldig instructies. De methode om de key te recoveren leek op de gadetscanningtechniek in een return-oriented programming (ROP) binary exploitation scenario", aldus de onderzoekers van Kaspersky, die in de analyse laten zien hoe dit in zijn werk gaat.
Verder blijkt dat de backdoor, door de loggingfunctie te manipuleren, ook de logs verbergt waarin ongeautoriseerde verbindingen naar de ssh-server staan en zijn er maatregelen genomen om replay-aanvallen te voorkomen. Daarbij weten onderzoekers of aanvallers de backdoorcommunicatie op te vangen en bij een andere server opnieuw af te spelen. "we kunnen concluderen dat deze backdoor inderdaad een zeer geraffineerde dreiging is", aldus de onderzoekers. Ze stellen dat verschillende eigenschappen de backdoor uniek maken, zoals de manier waarop die public key-informatie in de binary code is ingebed.
Vertrouw ook niemand totdat het tegendeel is bewezen.Alleen online contact is niet genoeg.
Je hebt duidelijk niet nagedacht over je OS /Linux/applicatielandschap .
Keek eens naar je desktop (letterlijk) - de meegeleverde achtergrond landschappen (KDE, Gnome, Android, Windows) - zitten natuurlijk ergens in het desktop/windowmanager git repo.
Uberhaupt alle window framing/buttons - binaries.
De klok - (alarm geluidjes) - binaries - in de repo. De graphics van de analoge klok - binaries.
Alle tweeps en boings notifications van je platform - binaries, ergens in de repo .
Docs in PDF .
test vectors in crypto code - dat is echt een must have.
Het is ZO makkelijk om in dat soort image/audio/pdf data brokken object code te stoppen en die er met een ietwat obfuscated script weer uit te halen.
Dat maakt jouw type 'advies' zo ontzettend nutteloos .
Vertrouw ook niemand totdat het tegendeel is bewezen.Alleen online contact is niet genoeg.
Ook advies kaliber 'neem alleen betrouwbare mensen aan' . Hoe precies stel je je voor dat je als project maintainer iemand moet leren vertrouwen ?
Wat HEB je eraan als je dan (als Fin) inderdaad een Jason Wang, student aan Tshinghua, Beijing weet te ontmoeten die veel code voor je project schrijft ? En dat al een jaar of twee doet ? Dat de naam in z'n paspoort ongeveer hetzelfde is als een gmail naam ? En dan ? Waarom precies vertrouw je 'm wel - of niet ?
En waarom zou je dan een Mees van der Vliet wel vertrouwen - en ook als je Mees ontmoet , hoe zou je precies weten of die niet voor geld of andere redenen als doorgeefluik van de AIVD, KGB (of de Chinezen) fungeert en zelf alleen z'n naam en blauwe ogen bijdraagt ? Sterker - als ie voor zo'n dienst werkt dan is een perfect paspoort echt een peuleschil om te geven en weet je niet eens of je fysieke ontmoeting met een echte Mees van der Vliet was , ook al liet iemand een paspoort met die naam zien.
Simpele en haastige infiltranten kun je enigszins proberen uit te sluiten, maar 'deep cover' mollen is haast onmogelijk.
Niet voor niks dat ook de profs nog wel eens nat gaan met infiltranten/dubbelagenten . (onderminister defensie Syrie was Mossad agent. 'cambridge five' MI-t6 agenten waren van de KGB )
Het gebruik van een sleutelpaar (public key - private key) lijkt mij hier niet waarschijnlijk. Bij RSA zijn die sleutels veel te groot.
Het gebruik van een sleutelpaar (public key - private key) lijkt mij hier niet waarschijnlijk. Bij RSA zijn die sleutels veel te groot.
Je kunt de analyse lezen, in plaats van speculeren wat jou handig LIJKT.
Ze zijn niet _zo_ groot - 2000 bits (ca 250 bytes) is weer niet het eind van de wereld.
Maar de betreffende public key is inderdaad een elliptic curve key (nog kleiner). Het is een ED448 key , die zijn ca 57 bytes groot.
Je hebt duidelijk niet nagedacht over je OS /Linux/applicatielandschap .
Keek eens naar je desktop (letterlijk) - de meegeleverde achtergrond landschappen (KDE, Gnome, Android, Windows) - zitten natuurlijk ergens in het desktop/windowmanager git repo.
Uberhaupt alle window framing/buttons - binaries.
De klok - (alarm geluidjes) - binaries - in de repo. De graphics van de analoge klok - binaries.
Alle tweeps en boings notifications van je platform - binaries, ergens in de repo .
Docs in PDF .
test vectors in crypto code - dat is echt een must have.
Het is ZO makkelijk om in dat soort image/audio/pdf data brokken object code te stoppen en die er met een ietwat obfuscated script weer uit te halen.
Dat maakt jouw type 'advies' zo ontzettend nutteloos .
Vertrouw ook niemand totdat het tegendeel is bewezen.Alleen online contact is niet genoeg.
Ook advies kaliber 'neem alleen betrouwbare mensen aan' . Hoe precies stel je je voor dat je als project maintainer iemand moet leren vertrouwen ?
Wat HEB je eraan als je dan (als Fin) inderdaad een Jason Wang, student aan Tshinghua, Beijing weet te ontmoeten die veel code voor je project schrijft ? En dat al een jaar of twee doet ? Dat de naam in z'n paspoort ongeveer hetzelfde is als een gmail naam ? En dan ? Waarom precies vertrouw je 'm wel - of niet ?
En waarom zou je dan een Mees van der Vliet wel vertrouwen - en ook als je Mees ontmoet , hoe zou je precies weten of die niet voor geld of andere redenen als doorgeefluik van de AIVD, KGB (of de Chinezen) fungeert en zelf alleen z'n naam en blauwe ogen bijdraagt ? Sterker - als ie voor zo'n dienst werkt dan is een perfect paspoort echt een peuleschil om te geven en weet je niet eens of je fysieke ontmoeting met een echte Mees van der Vliet was , ook al liet iemand een paspoort met die naam zien.
Simpele en haastige infiltranten kun je enigszins proberen uit te sluiten, maar 'deep cover' mollen is haast onmogelijk.
Niet voor niks dat ook de profs nog wel eens nat gaan met infiltranten/dubbelagenten . (onderminister defensie Syrie was Mossad agent. 'cambridge five' MI-t6 agenten waren van de KGB )
Plaatjes zitten bij mij ook niet in git, maar wel in signed images en ISO's
Alles waarmee een git diff zinloos is komt bij mij ook niet in GIT. Ik gebruik GIT namelijk niet als een simpel backup systeem.
Als bij een ED448 key (of X25519) de ene key van de andere key afgeleid kan worden, dan zou ik mij wel ernstig zorgen maken.
Nu zou je nog kunnen stellen dat als iemand binaries zegt dat hij dan compiler output bedoeld.
Dat maakt toch bijna NIKS uit ?
Zoals ik schreef (en iedereen in deze tak van sport ook wel kan bedenken) , je kunt zo makkelijk object code verstoppen/obfuscaten in andere binary data die 'logisch' bij een project hoort .
Mag je 'steganografie' noemen . Je hoeft maar een heel klein beetje rekening te houden met file structuur (png/gif/wav header) en alle tools 'herkennen' het netjes als image .
Met wat meer extractie werk is het - net als andere stego - ook onherkenbaar voor menselijke ogen , als de payload in low-order ruis bits zit, of in niet gerenderde delen van pdf (project of user documentatie).
Je kunt alle kunstjes leren van de ijverige stego security researchers .
heel simpele PoC dd -if test-background.png skip=1 bs=256 count=4 of=nasty.obj geeft wat je wilt.
Look ma, no object file in the repo !
Het extractie script zal dan (net als in het xz was) ge-obfuscate in het build proces moeten zitten. Niet heel moeilijk gezien de voodoo van autoconf .
Maar xz was eigenlijk nog mooier, omdat de nasty data ook niet in git zaten, maar in de 'authoritive' pre-build tarball.
'reproducible builds' is nog lang geen standaard, en niet zo makkelijk als het lijkt.
Plaatjes zitten bij mij ook niet in git, maar wel in signed images en ISO's
Whatever. Ook dan komen er momenten waarop een project 'compleet bij elkaar' gebouwd of gebruikt moet worden, en zo'n nasty payload ge-extract kan worden door een stukje slapende code dat erin gekomen is.
Voor een malicious insider - iemand die code kan committen - kun je niet echt rekenen dat signed images ontoegankelijk zijn.
Ergens zal ook je outside-repo artwork gemaakt ,gebuild en gesigned worden.
Alles waarmee een git diff zinloos is komt bij mij ook niet in GIT. Ik gebruik GIT namelijk niet als een simpel backup systeem.
Mooi hoor. Je moet dan een andere manier nemen om dat soort data in juiste versies bij je project te houden.
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.
Information Security Officer (Operationele Techniek)
bij HHNK
Heb jij een passie voor informatiebeveiliging en wil je jouw expertise inzetten in een organisatie met impact? Solliciteer nu! Bij HHNK hechten we veel waarde aan de veiligheid van onze informatie en systemen. Met een breed scala aan operationele techniek (OT) voor onze taken, is het essentieel om deze veilig te houden.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.