.NET-omgevingen kwetsbaar voor rootkits

root

Gepubliceerd: Vrijdag 17 april 2009

Het is mogelijk om het .NET-framework met een rootkit te infecteren. Alle gebruikte applicaties zijn dan in één klap gehacked.

Toon volledig artikel

Anonymous Coward op Vrijdag 17 April 2009 16:47

image

Voor hem is het pijnlijk dat bij forensisch onderzoek, het testen van applicaties of het beveiligen van de omgeving dit soort basale onderdelen van het systeem niet worden meegenomen. Het is voor hem natuurlijk niet pijnlijk maar voor de onderzoekers die forensich onderzoek doen. Al zal dat laatste natuurlijk ook sterk van de onderzoeker afhangen. Het controleren van basisgegevens is vaak de eerste stap in een diepgaand onderzoek.

De wijze waarop dit nu gebracht wordt is vrij tendentieus ( en dat zal tevens wel zijn doel zijn geweest) maar het kan natuurlijk met vele omgevingen gedaan worden. Het ook in het artikel slechts terloops genoemde java is daar een voorbeeld van. Ook denkt hij dat het nuttig is van dit soort zwakheden bewust te zijn en ook te realiseren dat in een virtuele machine van Java ook dit soort kwetsbaarheden zijn toe te voegen.
Dat dit type bestanden een diepgaande validiteitstest ondergaan is een prima idee en eigenlijk al een gemis. De meeste antivirus programmatuur heeft reeds ingebouwde checks om tampering te voorkomen. Dat zou met .net en dergelijk ook moeten gebeuren, naast controle door het systeem.

Anonymous Coward op Vrijdag 17 April 2009 23:06

image

( en dat zal tevens wel zijn doel zijn geweest)

Is ook tendentieus

anonymous_118315 op Zaterdag 18 April 2009 20:58

image

Goh, dat doet ie anders nooit. ;)

Jozik op Vrijdag 17 April 2009 17:09

image

Een beetje jammer dat pas in de laatste alinea gemeld wordt dat dit ceteris paribus opgaat voor Java.

Maar is het hele probleem niet op te lossen door bij de installatie (van .NET of Java) met een MD5 checksum te werken? Dan kan je controleren of je met "schone" installatiesoftware werkt.

anonymous_118315 op Zaterdag 18 April 2009 21:08

image

Dat gaat ervan uit dat de MD5 checksum 100% betrouwbaar is. Als je een aangepaste .Net versie installeert, dan kan de aanbieder daar natuurlijk moeiteloos een aangepaste MD5 bij leveren.

Ik denk dat je beter kan zorgen dat mensen zo min mogelijk software hoeven te downloaden via een onbetrouwbare bron. Ik denk dat dat toch één van de belangrijkste risico's is.

Jozik op Zaterdag 18 April 2009 23:31

image

Maar dat zou toch weer op te lossen zijn door de checksum op de officiele site te zetten? Dan kan ik .Net overal vandaan halen en checken met de checksum die ik van de MS-site haal.

anonymous_118315 op Zondag 19 April 2009 18:04

image

Maar in dat geval kan je toch net zo goed de download zelf van de officiële site halen? Volgens mij is het vaak zo dat mensen bij de eerste site die ze vinden in Google (of Live) gaan downloaden. Volgens mij gaan die niet vervolgens op de officiële site zoeken naar de MD5.

Lennart op Vrijdag 17 April 2009 17:15

image zomerhack badge 3

Wat een kul artikel. Dit gaat op voor het overgrote deel van de webapplicatieframeworks of scripttalen. Of eigenlijk alle talen. Perl, PHP, C++, Python, noem maar op, die zullen geen kik geven als je de binaries vervangt door een gepatchte versie. Dit geldt natuurlijk ook voor dingen als webservers of ssh daemons. Tenzij je een intrusion detection systeem hebt die crc checks doet van bestanden merk je dat niet.

Kern van het verhaal is natuurlijk dat 1: je hebt roottoegang nodig om .NET bestanden te vervangen, en als je roottoegang hebt dan zijn er makkelijkere manieren om een rootkit in te bouwen; en 2: er kunnen alleen dingen gedaan worden met de rechten van de user die het .NET (of PHP of Perl of watdanook) proces runt. Die runnen (neem ik aan, al weet je het nooit met windows) niet met root/admin rechten.


Jachim Boaz op Vrijdag 17 April 2009 19:08

image

C++ is normalerwijze geen geïnterpreteerde taal en door een C++ compiler op deze manier te hacken worden niet automatisch alle in C++ geschreven applicaties op een systeem kwetsbaar; ze zullen eerst opnieuw gecompileerd moeten worden met de gehackte compiler. Een virtuele machine hacken is daarmee veel effectiever dan een compiler of individuele applicaties hacken.

Overigens is het idee van de gehackte compiler al decennia oud en afkomstig van Ken Thompson, zie back door in de jargon file.

kwark op Vrijdag 17 April 2009 19:30

image

Voor de C hoef je slecht libc te vervangen, voor C++ slechts libstdc++. Sterker nog, je hoeft ze niet eens te vervangen, een LD_PRELOAD in de context van de gebruiker is al voldoende om alle nieuw opgestarte binaries te "infecteren".

Je enige bescherming hiertegen is door alleen statische binaries te gebruiken die voorzien in alle functionaliteit.

tikdat op Vrijdag 17 April 2009 21:02

image

geldt dit ook voor mono?

Brenno de Winter (brenno@dewinter.com) op Zaterdag 18 April 2009 00:12

image

Waarschijnlijk wel, want geen besturingssysteem controleert dat volgens mij. Je zou iets van een soort tripwire moeten hebben. Ik ben het met die C/C++ conclusie ook wel eens. De les dat we hierover moeten leren nadenken is wel een goede.

anonymous_118315 op Zaterdag 18 April 2009 20:56

image

Ik ben het met Brenno eens. Al heb je daar natuurlijk nog de extra barrière dat je de gebruiker zo ver moet zien te krijgen het via een alternatieve repo te gaan installeren.

CyberData op Zaterdag 18 April 2009 15:24

image

Niet een Microsoft-probleem

De onderzoeker erkent dat het probleem niet louter Microsoft is. "Ik heb ze wel op de hoogte gebracht, maar ze vertellen me dat dit geen bug is",


Bij microsoft is elke bug een nieuwe feature !!! LoL

Om te kunnen reageren, dient u ingelogd te zijn.

Nieuwsbrief

Ontvang dagelijks een overzicht van het laatste ICT-Nieuws in uw mailbox

Peiling

Loading Poll

Video: World Tech Update: Darpa's robot oorl...

World Tech Update: Darpa's robot oorlogspaard (video)

Verleden nieuws