badBIOS - Malware für Fortgeschrittene
- Thread starter Joe User
- Start date
A
Alderon
Guest
Interessantes Thema, danke dafür!
Spontan würde ich sagen: wir brauchen wieder Jumper, um das UEFI/BIOS schützen zu können, was zumindest etwas Sicherheit bringt. Das ersetzt natürlich keine Bemühungen von Herstellern, um hier mehr Sicherheit zu schaffen.
Mir graut auch schon davor, was man alles an Malware unterbringen kann, denn viele Boards haben 32/64 mbit ROMs, da bekommt man eine Menge unter.
Spontan würde ich sagen: wir brauchen wieder Jumper, um das UEFI/BIOS schützen zu können, was zumindest etwas Sicherheit bringt. Das ersetzt natürlich keine Bemühungen von Herstellern, um hier mehr Sicherheit zu schaffen.
Mir graut auch schon davor, was man alles an Malware unterbringen kann, denn viele Boards haben 32/64 mbit ROMs, da bekommt man eine Menge unter.
Joe User
Zentrum der Macht
Das liegt daran, dass immer weniger Fachidioten Assembler können und BIOS/Firmware deshalb mitlerweile in ineffizienten Hochsprachen umgesetzt werden.
Ein BIOS für aktuelle Mainboards ist in Assembler <1MByte gross, in C/C++ hingegen mehrere MByte. Bei UEFI ist das Verhältnis noch extremer.
In ein paar Jahren sind Programmierer dann soweit verdummt, dass BIOS in Java oder Schlimmeren umgesetzt werden und hundert oder mehr MByte verschlingen...
Hallo!
Na warten wir mal ab, ob wir da nicht einem Hoax auf den Leim gegangen sind (http://www.rootwyrm.com/2013/11/the-badbios-analysis-is-wrong/).
mfG
Thorsten
Na warten wir mal ab, ob wir da nicht einem Hoax auf den Leim gegangen sind (http://www.rootwyrm.com/2013/11/the-badbios-analysis-is-wrong/).
mfG
Thorsten
Joe User
Zentrum der Macht
Etwas sehr Wichtiges verschweigt der "BIOS-Spezialist" komischerweise nahezu konsequent, selbst als er in einem Kommentar direkt darauf angesprochen wird:
In BIOS/UEFI existieren seit Jahren Hooks/APIs zum modularen Erweitern von Funktionen und auch zum Flashen des ROMs. Desweiteren läuft das Checksum nur über die Bereiche, welche in einer Tabelle zum Checksum vorgegeben sind. Legt man die Malware ausserhalb dieser Bereiche ab (und dafür gibt es genug Platz), dann meckert das Checksum auch nicht. Ja, manche BIOS/UEFI lassen den Checksum auch über die freien Bereiche laufen, allerdings läuft Checksum nur einmalig beim Boot.
Hier liegt dann auch das Problem, denn die Checksum-Tabelle ist und muss beschreibbar sein, andernfalls wären keine BIOS/UEFI-Updates/Module möglich. Die Malware braucht also nur die Checksum-Tabelle manipulieren und schon bootet die Kiste sauber ohne Checksum-Mismatch durch. Alles nichts Neues.
Das Problem mit der Portabilität ist (wie in dem einen Kommentar bereits angedeutet) auch nicht so gross wie gerne behauptet und seit dem Umstellen auf C recht weit gesunken (Hint: libc und Compiler). Spätestens seit UEFI mit seiner recht strikten Spezifikation aber nochmals weiter zurückgegangen.
Das I-Tüpfelchen sind dann noch die immer weiter verdummenden Programmierer, die gar nicht mehr verstehen wie Hardware überhaupt funktioniert und nur noch froh sind, wenn ihr Code vom Compiler gefressen und vom System ausgeführt wird. Auf Sicherheit wird dort auch nicht übermässig geachtet (Buffer-Overflow im Checksum des BIOS, siehe Kommentar zum vorigen Blogpost, WTF?), sind ja nur ein paar Sekunden bis das OS diesen Job übernehmen muss.
Das Einzige, was mich an dieser Geschichte etwas stört ist, dass das ursprüngliche Einfallstor nicht gefunden ist und auch die "Airgap"-Theorie halte ich für unwahrscheinlich (zumindest über billige Mikrofone+Lautsprecher).
In BIOS/UEFI existieren seit Jahren Hooks/APIs zum modularen Erweitern von Funktionen und auch zum Flashen des ROMs. Desweiteren läuft das Checksum nur über die Bereiche, welche in einer Tabelle zum Checksum vorgegeben sind. Legt man die Malware ausserhalb dieser Bereiche ab (und dafür gibt es genug Platz), dann meckert das Checksum auch nicht. Ja, manche BIOS/UEFI lassen den Checksum auch über die freien Bereiche laufen, allerdings läuft Checksum nur einmalig beim Boot.
Hier liegt dann auch das Problem, denn die Checksum-Tabelle ist und muss beschreibbar sein, andernfalls wären keine BIOS/UEFI-Updates/Module möglich. Die Malware braucht also nur die Checksum-Tabelle manipulieren und schon bootet die Kiste sauber ohne Checksum-Mismatch durch. Alles nichts Neues.
Das Problem mit der Portabilität ist (wie in dem einen Kommentar bereits angedeutet) auch nicht so gross wie gerne behauptet und seit dem Umstellen auf C recht weit gesunken (Hint: libc und Compiler). Spätestens seit UEFI mit seiner recht strikten Spezifikation aber nochmals weiter zurückgegangen.
Das I-Tüpfelchen sind dann noch die immer weiter verdummenden Programmierer, die gar nicht mehr verstehen wie Hardware überhaupt funktioniert und nur noch froh sind, wenn ihr Code vom Compiler gefressen und vom System ausgeführt wird. Auf Sicherheit wird dort auch nicht übermässig geachtet (Buffer-Overflow im Checksum des BIOS, siehe Kommentar zum vorigen Blogpost, WTF?), sind ja nur ein paar Sekunden bis das OS diesen Job übernehmen muss.
Das Einzige, was mich an dieser Geschichte etwas stört ist, dass das ursprüngliche Einfallstor nicht gefunden ist und auch die "Airgap"-Theorie halte ich für unwahrscheinlich (zumindest über billige Mikrofone+Lautsprecher).
A
Alderon
Guest
Mir kommt der verlinkte Artikel auch eher so vor "es ist so, punkt, keine Diskussion". Er hat dazu auch nur einen kritischen Kommentar freigeschaltet und die Erwiderung auf seine Erwiderung nicht mehr.
Natürlich, das ist sein gutes Recht aber für mich hat das den Beigeschmack, dass er selbst keinerlei Widerspruch duldet und nicht wirklich diskutieren möchte.
Das alleine heißt natürlich nicht, dass er nicht trotzdem Recht haben kann aber Joe hat ja auch schon ein paar Punkte angesprochen, die im Artikel nicht richtig, bzw. verkürzt dargestellt wurden.
Ansonsten erinnert mich das etwas an die Sache mit den manipulierten Kartenlesern in diversen Geschäften, als ein "Programmierer" im Heiseforum auftauchte und meinte, dass das gar nicht sein könne, weil das Gerät ja schließlich mit der Bank kommuniziere und deshalb die PIN am Gerät selbst gar nicht abgegriffen werden können (Hintergrund: die Transaktionen wurden alle "abgelehnt", weil eben keine saubere Kommunikation mehr statt fand, die PIN hatten die Täter trotzdem).
Das manipulierte Firmware aber genau das nicht mehr macht, wollte er schlichtweg nicht verstehen.
Ich sehe jedenfalls nicht wie eine systemimmanente Schutzfunktion ein System vor Zugriffen von außen schützen soll, wenn es vollständig überschrieben werden kann (und damit eben auch die Schutzfunktion). Das hat Joe ja auch schon angemerkt.
Wenn ich die Firmware selbst kontrolliere und damit die Prüfung der Checksums kann ich die Prüfung auch vollständig abschalten.
Die Prüfung müsste also von außen erfolgen, was immer noch ein gewisses Restrisiko birgt, wenn die Werte an sich über die Firmware ausgelesen werden und man nicht an dieser "vorbei" kommt.
Auf Heise habe ich heute gelesen, dass die Malware "badBIOS" bald Sophos zur Verfügung gestellt wird, dann wissen wir mehr. Der Existenzbeweis ist jedenfalls deutlich einfacher als der Beweis der Nichtexistenz.
Ps: was Joe sagt stimmt im Prinzip, bei uns (Studium allgemeine Informatik) erhalten nur die Technischen Informatiker einen wirklichen Einblick in Assembler aber sogar dort wird C präferiert. Wir haben zwar auch Compilerbau (wo Assembler noch eine gewisse Rolle spielt) aber keiner von uns könnte aufgrund des Studiums wirklich in Assembler programmieren. Das Interesse dazu muss also von einer Person selbst kommen. Ich wäre da - ganz ehrlich - auch aufgeschmissen.
Natürlich, das ist sein gutes Recht aber für mich hat das den Beigeschmack, dass er selbst keinerlei Widerspruch duldet und nicht wirklich diskutieren möchte.
Das alleine heißt natürlich nicht, dass er nicht trotzdem Recht haben kann aber Joe hat ja auch schon ein paar Punkte angesprochen, die im Artikel nicht richtig, bzw. verkürzt dargestellt wurden.
Ansonsten erinnert mich das etwas an die Sache mit den manipulierten Kartenlesern in diversen Geschäften, als ein "Programmierer" im Heiseforum auftauchte und meinte, dass das gar nicht sein könne, weil das Gerät ja schließlich mit der Bank kommuniziere und deshalb die PIN am Gerät selbst gar nicht abgegriffen werden können (Hintergrund: die Transaktionen wurden alle "abgelehnt", weil eben keine saubere Kommunikation mehr statt fand, die PIN hatten die Täter trotzdem).
Das manipulierte Firmware aber genau das nicht mehr macht, wollte er schlichtweg nicht verstehen.
Ich sehe jedenfalls nicht wie eine systemimmanente Schutzfunktion ein System vor Zugriffen von außen schützen soll, wenn es vollständig überschrieben werden kann (und damit eben auch die Schutzfunktion). Das hat Joe ja auch schon angemerkt.
Wenn ich die Firmware selbst kontrolliere und damit die Prüfung der Checksums kann ich die Prüfung auch vollständig abschalten.
Die Prüfung müsste also von außen erfolgen, was immer noch ein gewisses Restrisiko birgt, wenn die Werte an sich über die Firmware ausgelesen werden und man nicht an dieser "vorbei" kommt.
Auf Heise habe ich heute gelesen, dass die Malware "badBIOS" bald Sophos zur Verfügung gestellt wird, dann wissen wir mehr. Der Existenzbeweis ist jedenfalls deutlich einfacher als der Beweis der Nichtexistenz.
Ps: was Joe sagt stimmt im Prinzip, bei uns (Studium allgemeine Informatik) erhalten nur die Technischen Informatiker einen wirklichen Einblick in Assembler aber sogar dort wird C präferiert. Wir haben zwar auch Compilerbau (wo Assembler noch eine gewisse Rolle spielt) aber keiner von uns könnte aufgrund des Studiums wirklich in Assembler programmieren. Das Interesse dazu muss also von einer Person selbst kommen. Ich wäre da - ganz ehrlich - auch aufgeschmissen.
Last edited by a moderator:
Last edited by a moderator:
A
Alderon
Guest
Er hat sich vermutlich vertan, hier der korrekte Link:
http://www.heise.de/newsticker/meldung/Super-Malware-BadBIOS-wirft-Fragen-auf-2038240.html
http://www.heise.de/newsticker/meldung/Super-Malware-BadBIOS-wirft-Fragen-auf-2038240.html
[netcup] Felix
New Member
Ein paar Ansätze mögen da richtig sein, im Großem und Ganzen halte ich das aber für Humbug. Das über das BIOS gezielt einzelne Dateien gelöscht oder noch schlimmer verändert werden können, sollte nicht möglich sein, da das BIOS die Dateien nur sektorbasiert ansprechen kann. Das Filesystem wird seitens des OS bereitgestellt und verarbeitet. Der Virus im BIOS müsste also über das OS auf die Dateien zugreifen und spätestens dann könnte aus dem Kontext des OS die angebliche Kompromittierung festgestellt werden.
Joe User
Zentrum der Macht
Es ist kein Problem simple Filesystem-Treiber im BIOS und erst recht im UEFI unterzubringen. Insbesondere die Filesysteme für die bei Ruiu betroffenen Systeme sind die notwendigen Filesystem-Treiber einfach und kompakt implementierbar. Alles Andere ist im BIOS/UEFI bereits vorhanden oder ebenso einfach implementiert.
Das ist doch Alles kein Hexenwerk und wer es nicht glaubt, der darf sich mal http://asm.sourceforge.net/asmutils.html als Inspiration ansehen.
Das ist doch Alles kein Hexenwerk und wer es nicht glaubt, der darf sich mal http://asm.sourceforge.net/asmutils.html als Inspiration ansehen.