Thema: Rootkits in der Hardware ...

[SiLæncer]

Ein Forscher hat ein Konzept veröffentlicht, wie ein Rootkit die komplette Neuinstallation des Betriebssystems überdauern kann, indem es sich in Flash-Speicher auf Erweiterungskarten kopiert.

Die Zeiten von Bootsektorviren, die auch das Formatieren einer Festplatte überleben, sind an sich vorbei. Der Sicherheitsforscher John Heasman von Next Generation Security Software will einen anderen Weg gefunden haben, wie Schädlinge auch eine komplette Neuinstallation, einschließlich Festplattenformatierung überleben können. Sie könnten sich im Konfigurationsspeicher von Grafik- oder Netzwerkkarten einnisten.

John Heasman hatte sein Konzept bereits Anfang dieses Jahres auf einer Sicherheitskonferenz präsentiert und hat nun eine ausführlichere Arbeit dazu unter dem Titel " Implementing and Detecting a PCI Rootkit " veröffentlicht. Darin beschreibt er, wie sich ein Rootkit mit Hilfe der ACPI-Funktionen (Advanced Configuration and Power Interface) von PC-Mainboards im Flash-Speicher von PCI-Karten verbergen kann.

Während das BIOS des Mainboards oft durch einen Jumper (Steckbrücke) vor Schreibzugriffen geschützt ist, sind derartige Vorkehrungen bei PCI-Karten nicht üblich. So könnte ein Rootkit im Konfigurationsspeicher abgelegte Befehlstabellen manipulieren. Beim Start des Rechners werden diese veränderten Befehle ausgeführt, prinzipiell unabhängig davon, welches Betriebssystem geladen wird.

Schutz vor derartigen Manipulationen bieten Trusted Platform Module, die bereits auf einigen neueren Mainboards vorhanden sind. Sie unterstützen eine Reihe von Sicherheitsmechanismen, die auf Grund ihrer Möglichkeiten zur Einführung Hardware-basierter DRM-Funktionen (Digital Rights Management) jedoch umstritten sind.

Nach Ansicht von John Heasman werden Rootkits, die sich im Flash-Speicher von PCI-Karten verbergen, nicht so bald alltäglich werden. Dafür gebe es noch zu viele Anwender, die nicht einmal Sicherheits-Updates für ihr Betriebssystem oder Antivirus-Software installierten. Solange sich dies nicht ändere, hätten Malware-Programmierer es nicht nötig, so tief in die Trickkiste zu greifen.

Quelle : www.pcwelt.de

[SiLæncer]

Zwei argentinischen IT-Sicherheitsforschern ist es offenbar gelungen, Malware so im BIOS eines Rechners zu platzieren, dass sie auch eine komplette Löschung der Festplatte übersteht.

Die beiden Forscher, Alfredo Ortega und Anibal Sacco von der Firma Core Security Technologies, präsentierten ihren Angriff auf der Konferenz CanSecWest. Dort zeigten sie verschiedene Methoden, das BIOS mit dauerhaftem Schadcode zu infizieren. Angeblich übersteht der Schädling dabei nicht nur einen Reboot des Computers, sondern sogar den Versuch, das BIOS zu flashen.

Das verwendete Betriebssystem des Rechners spielt dabei keine Rolle. Auf der Konferenz infizierten Ortega und Sacco erfolgreich sowohl einen Windows-PC als auch einen Rechner, der unter OpenBSD lief, und einen mit VMWare Player. Angeblich werden für den Angriff keine spezifischen Vulnerabilities genutzt, sodass er auf praktisch jedem System umsetzbar ist.

Für den Angriff werden allerdings entweder Superuser-Rechte oder physischer Zugriff auf den Zielcomputer benötigt, was die Möglichkeiten der Umsetzung erheblich einschränkt. Momentan arbeiten die Forscher an einem automatisiert arbeitenden BIOS-Rootkit, um ihren Angriff effektiver zu gestalten. Dieses wollen sie wahrscheinlich mit Hilfe eines modifizierten Gerätetreibers an Ort und Stelle befördern.

Quelle : www.gulli.com

[spoke1]

Das verwendete Betriebssystem des Rechners spielt dabei keine Rolle.

Damit ist der Punkt erreicht der wirklich Angst machen sollte/macht.

[McCom]

Aber es ist pur BIOS abhängig oder? Also wenn ich EFI oder UFI (oder so) nutze wäre ich theoretisch save?

[SiLæncer]

Aber es ist pur BIOS abhängig oder?

Würde ich mal mit JA beantworten ...

Also wenn ich EFI oder UFI (oder so) nutze wäre ich theoretisch save?

Theoretisch ...obwohl ich mir hier gar nicht so sicher bin ...

[spoke1]

wäre ich theoretisch save?

Meine Erbtante würde ich da auch nicht mehr für verwetten wollen

[Jürgen]

Es gibt schon seit Ewigkeiten freie Bereiche in den BIOS-Bausteinen. Dass dort Malware Unterschlupf fände, ist zweifellos möglich, weil es (zumindest auf normalen Boards) meist keine logischen Schutzmechanismen gegen Veränderungen gibt, wie dies z.B. eine gute Checksummenabfrage bei'm Boot bieten könnte. Hinzu kommt, dass - nicht erst seit Aufkommen der Recovery-BIOSes - ganze Bereiche mit normalen Routinen vom Nutzer überhaupt nicht mehr überschreibbar sind, sicherlich aber von fähiger Malware.

Auch ein im BIOS aktivierter Virenschutz hilft nicht, weil der zwar Bootsektoren prüfen könnte, aber nicht das BIOS selbst.

Hardware-Schreibschutz tut not, z.B. durch Abschalten einer notwendigen Schreibspannung durch einen Jumper, wie jahrelang üblich. Leider werden heutzutage Flash-Bausteine eingesetzt, deren Schreibspannung nicht mehr höher als die zum Auslesen ist.

Selbst die CMOS-Speicher werden immer grösser, um die inzwischen teils recht komplexen Einstellungen, P&P Konfigurationsdaten und Meldungen halten zu können.

Allerdings benötigte man nicht unerhebliche Sicherheitslücken im BIOS selbst und dem gestarteten Betriebssystem, um anstelle von Laufwerks- und Plug&Play-Informationen ausführbaren Code einzubringen.

Dennoch frage ich mich schon seit Mitte der 90er Jahre, warum überhaupt ein Betriebssystem Schreibrechte im CMOS erhalten sollte. Es macht m.e. keinen Sinn, nur zum komfortablen Stellen der Rechner-Uhr so etwas zuzulassen. Statt dessen wäre es ja ohne weiteres möglich gewesen, für Sommerzeitumstellung oder DCF-Korrekturen einfach dem Betriebssystem ein kontrolliertes Offset zu verpassen, ohne die BIOS-Uhr selbst anzurühren. Und so hätte man niemals Eingriffe von Windoof & Co. zulassen müssen.
Erst recht nicht Veränderungen am Flash. Eine Flash-Routine gehört eigentlich in's BIOS selbst, die sollte zudem auf einen bestimmten POST-Zustand beschränkt bleiben.

Was soll's, das Kind liegt längst im Brunnen...

[berti]

Aber es ist pur BIOS abhängig oder? Also wenn ich EFI oder UFI (oder so) nutze wäre ich theoretisch save?

die genannte atacke ist fürs bios geschrieben und wird vermutlich auch nur dort funktionieren.
aber efi bzw uefi bietet sogar noch mehr möglichkeiten, schadcode zu verwenden.
beispiel: es braucht nur jemand auf die idee zu kommen und die schellscript routinen im nvram zu verändern bzw neue scripte einzupflegen und schon ist vorbei mit lustig.

abhilfe wäre schnell geschaffen, wenn die boardhersteller wie auch die betriebssystemschneider mal für einen cent nachdenken würden und die sachen sicherer machen würden.
Bei den boardhersteller würde sicherlich ein "read-only" jumper helfen, denn die derzeit gängiggen "bios"-chips haben diese möglichkeit (egal of bios oder efi). Nur gibt es dann das problem, das Win, Linux und freebsd ins bios schreiben wollen und da zum teil  merkwürdige fehlermeldungen rausgeben, wenns mit dem schreiben nicht klappt  Und das grösste problem sitzt natürlich auch wieder zwischen schirm und stuhl, denn was bringt die beste sicherheitslösung, wenn der anwender das alles zunichte macht.


achja: zu efi ist auch wikki dein freund, wer also mit den bezeichnungen nix anfangen lkann: gugst du hier:
hxxp://en.wikipedia.org/wiki/Extensible_Firmware_Interface  (english, konnte die deutsche entsprechung nicht finden)

[SiLæncer]

auch hier nochmal was zum aktuellen Thema ...

Wieder einmal: Rootkit im PC-BIOS

Mitarbeiter der argentinischen IT-Sicherheitsfirma Core Security Technologies haben auf der Konferenz CanSecWest ein Szenario vorgestellt, bei dem ein Rootkit seinen Code in den Flash-Speicherchip des PC- oder Notebook-Mainboards schreibt, der eigentlich für das BIOS vorgesehen ist. Auf diese Art tief im System verankert, übersteht ein Rootkit sogar das Neuformatieren oder den Austausch der Festplatte; zudem ist es für Virenscanner schwierig, den BIOS-Code zu prüfen.

Angriffe auf das PC-BIOS sind allerdings nicht neu. Besonders bekannt ist das 1998 erschienene CIH-Virus geworden, das jeweils am 26. April eines Jahres – dem Jahrestag der Tschernobyl-Reaktorkatastrophe – aktiv wurde: Der Autor hatte das unter Windows 95 lauffähige Programm mit einer simplen Lösch-Routine für die auf damaligen Mainboards üblichen Flash-EEPROM-Speicherchips ausgestattet. Auch das Auslesen der seinerzeit umstrittenen Pentium-III-Seriennummer ließ sich durch nachträgliche Änderungen am BIOS leicht bewerkstelligen.

Bei aktuellen Mainboards ist der Flash-Speicher für den BIOS-Code typischerweise via SPI (Serial Peripheral Interface) an die Chipsatz-Southbridge angebunden und nicht mehr – wie früher – via Low-Pincount-Interface (LPC) oder zuvor via ISA- beziehungsweise X-Bus. Die Zeiten, in denen man ein BIOS-Update mühsam mit einem Kommandozeilenbefehl von einem von Diskette gestarteten DOS einspielen musste, sind glücklicherweise vorbei: Flash-Tools laufen mittlerweile unter Windows, teilweise sogar als ActiveX-Control. Viele BIOS-Versionen haben ein eingebautes Flash-Tool, das Updates auch etwa von einem USB-Stick laden kann. Außer herstellerspezifischen Flash-Tools gibt es auch universellere, die mit Flash-Speicherchips mehrerer Hersteller umgehen können, etwa Flashrom von den Coreboot-Entwicklern.

BIOS-Code wird unmittelbar nach dem Systemstart ausgeführt, also noch vor dem Betriebssystem, und damit bevor Virenscanner oder andere Software vor Schadroutinen schützen könnte. Der BIOS-Code besteht aus zahlreichen einzelnen Modulen, die nacheinander abgearbeitet werden, sowie einer Ablaufsteuerung. Der Code der einzelnen Module, von denen einige beispielsweise den Power-On Self Test (POST) durchführen, kann LZH-komprimiert sein, wie die Autoren Anibal L. Sacco und Alfredo A. Ortega in ihrer CanSecWest-Präsentation (PDF-Datei) erklären. Außerdem untersucht das BIOS vor dem Ausführen einzelner Module deren Prüfsummen – die Prüfsummen injizierten Codes müssen also daran angepasst werden. Tipps dazu liefert beispielsweise der Buchautor Darmawan Salihun, der unter dem Nickname Pinczakko über BIOS-Hacks schreibt; die Core-Security-Autoren verweisen ausdrücklich darauf.

Die Core-Security-Mitarbeiter diskutieren mehrere potenzielle Angriffsziele im BIOS-Code, lohnend scheinen ihnen beispielsweise die LZH-Entpacker-Routinen, weil diese selbst nicht komprimiert sind. Die beiden Autoren weisen darauf hin, dass Virtualisierungssoftware wie VMware auch BIOS-Code emuliert, der sich ebenfalls modifizieren lässt.

Wie bei vielen ähnliche Demonstrationen von hardwarenahen Attacken – etwa auch beim kürzlich von Joanna Rutkowska und Loic Duflot gezeigten System-Management-Mode-Angriff – fehlt auch hier eine Einschätzung, welche Systeme überhaupt verwundbar sind. Zunächst einmal kann nicht jedes Flash-Tool jeden beliebigen Flash-Chip beschreiben. Außerdem bietet fast jedes BIOS im Setup-Programm eine Schreibschutz-Option – ist diese aktiviert, was manchmal erst nach Vergabe eines Passworts für den Zugriff auf das BIOS-Setup möglich ist, lässt sich der BIOS-Code nicht überschreiben. Auf manchen Boards lässt sich das Beschreiben des Flash-Chips auch per Jumper oder DIP-Schalter sperren.

Unklar ist auch, bei welchen BIOS-Versionen ein Angriff überhaupt nach demselben Schema funktioniert. Die Core-Security-Mitarbeiter haben mit einem Phoenix Award BIOS gearbeitet; Phoenix hatte die Firma Award Ende der 90er-Jahre übernommen. Unter der Marke Phoenix gibt es aber auch stärker gesicherte BIOS-Versionen wie SecureCore, die ihren Code mit Signaturen schützen. Schließlich gibt es noch weitere BIOS-Varianten anderer Hersteller wie AMI oder Insyde und in Zukunft auch UEFI-Firmware. Ein Angriff auf das Mainboard-BIOS muss also relativ systemspezifisch geschrieben sein. Dass trotz bekannter Schwächen, die das CIH-Virus bereits vor mehr als einer Dekade aufgezeigt hat, bisher erst sehr wenige Schadroutinen das BIOS attackieren, zeigt, dass solche Angriffe im Vergleich zu Attacken auf weit verbreitete Betriebssysteme oder Browser anscheinend als weniger erfolgversprechend oder zu kompliziert eingestuft werden.

Ein potenziell lohnender und einfacherer Weg zur Infizierung von BIOS-Code könnte sein, die von den Mainboard- und PC-Herstellern zum Download angebotenen BIOS-Updates zu manipulieren: Deren Server scheinen oft nicht sonderlich gut geschützt zu sein, immer wieder wurden Download-Webseiten manipuliert oder Geräte mit infiziertem Code ausgeliefert.

Quelle und Links : http://www.heise.de/newsticker/Wieder-einmal-Rootkit-im-PC-BIOS--/meldung/135171

[SiLæncer]

Der Sicherheitsexperte Guillaume Delugré von Sogeti ESEC hat demonstriert, dass sich ein Rootkit nicht zwangsläufig auf dem Rechner einnisten muss: Mit Hilfe frei zugänglicher Tools und Dokumentationen hat er eine eigene Firmware für Broadcoms NetXtreme-Netzwerkcontroller entwickelt, in der er ein Rootkit versteckt hat. Dadurch ist es seitens des PCs durch übliche Virenscanner nicht aufspürbar.

Delugrés Code wird direkt von der MIPS-CPU der Netzwerkkarte ausgeführt und kann durch den Speicherdirektzugriff (Direct Memory Access, DMA) der PCI-Schnittstelle ohne Umwege mit dem Arbeitsspeicher kommunizieren – normalerweise tauschen Netzwerkkarten auf diesem Weg die Netzwerkframes mit dem auf dem Rechner installierten Treiber aus.

Der Angreifer kann aus der Ferne auf den Rechner zugreifen oder den Netzwerkverkehr belauschen. Broadcoms NetExtreme-Controller kommen vor allem bei Firmenkunden zum Einsatz. Netzwerkcontroller für Privatkunden werden in der Regel, wenn überhaupt, mit wenig Speicher ausgeliefert und sind nicht so flexibel programmierbar, sodass sie für einen solchen Angriff eher ungeeignet sein dürften.

Ganz neu ist dieses Angriffsszenario nicht: Bereits im Jahr 2006 hatte John Heasman im Erweiterungsspeicher von Grafik- und Netzwerkkarten ein Rootkit platziert, das jedoch nach dem Windows-Start Code aus dem Netz nachladen musste. Auch der Flash-Speicherchip des Mainboards, der für das PC-BIOS vorgesehen ist, eignet sich prinzipiell als Rootkit-Versteck.

Quelle : www.heise.de