Sicherheitswoche 34: Man kann nicht einfach patchen…

Man kann viele Gründe finden, warum ein bestimmter Fehler nicht gepatcht werden kann – zumindest nicht sofort, oder im nächsten Vierteljahr, oder… jemals. Doch das Problem muss trotzdem gelöst werden.

Was für eine schlimme Woche war das für die Sicherheitsbranche. Nach gefundenen Fehlern, Zero-Day-Lücken und anderen von Forschern begehrten Kuriositäten, kommen die schmerzlichen Nachwehen, und all das mündet in angreifbare Software. Das ist wichtig, löst aber oft auch Langeweile aus. Immer wenn mir unser News-Blog Threatpost die drei wichtigsten Sicherheitsnachrichten vorstellt, bei denen es um das Patchen von Sicherheitslücken geht, ist das meist schwer verdaulich.

Nun, es ist deshalb nicht weniger wichtig! Es heißt, dass man nicht einfach so eine Sicherheitslücke finden kann, aber noch schwieriger ist es, diese zu schließen, ohne dabei alles andere zu demolieren. Man kann viele Gründe finden, warum ein bestimmter Fehler nicht gepatcht werden kann – zumindest nicht sofort, oder im nächsten Vierteljahr, oder… jemals. Doch das Problem muss trotzdem gelöst werden. Die heutige Hitparade bringt uns drei Geschichten zu Fehlern, die bedauerlicherweise noch nicht gepatcht wurden.

Kurz zur Erinnerung: Das Threatpost-Team wählt jede Woche drei wichtige Neuigkeiten aus, die ich hier rastlos kommentiere. Die vorhergehenden Kommentare finden Sie hier.

Noch ein Android-Fehler, diesmal in Google Admin

Der Threatpost-Artikel. Die Forschungsarbeit von MWR.

Was wurde gefunden?

Ist Ihnen schon einmal aufgefallen, dass die Liebesbriefe von solchen Fehlern immer haufenweise eintrudeln? Wow, ein Auto ist gehackt worden? Lasst uns ein Dutzend weiterer Sicherheitslücken in Autos finden! Das gleiche Muster kann man auch bei den aktuellen News rund um Android feststellen. Erst Stagefright, dann ein paar kleinere Fehler, und jetzt Google Admin.

Google Admin, eine von Androids System-Apps, kann URLs aus anderen Apps akzeptieren – und wie sich jetzt herausstellte wirklich jede, selbst solche, die mit „file://“ beginnen. Dadurch können ganz einfache Netzwerkaktionen, etwa das Öffnen von Webseiten, zu kompletten Dateimanager-Dingen werden. Sollten eigentlich nicht alle Android-Apps voneinander isoliert sein? Sind sie nicht, und Google Admin hat höhere Rechte als andere Apps. Wenn man ihr also eine schädliche URL unterjubelt, kann eine App der Sandbox entkommen und plötzlich auf private Daten zugreifen.

Wie wurde das gepatcht?

Lassen Sie mich zunächst kurz auf die unabhängige Forschungsarbeit eingehen, die die Sicherheitslücke aufgedeckt hat. Das war bereits im März. Gleichzeitig wurde auch Google darüber informiert. Fünf Monate später prüften die Forscher die Lücke erneut und mussten feststellen, dass sie nach wie vor nicht geschlossen war. Am 13. August wurde sie daher öffentlich gemacht, um Google dazu zu bringen, den Patch endlich zu veröffentlichen.

Übrigens hat Google ein eigenes Forschungsteam, das ebenfalls nach solchen Fehlern sucht, und das nicht nur in der hauseigenen Software. Das so genannte Project Zero gibt normalerweise 90 Tage Frist, bevor es Fehler veröffentlicht – wobei man sich fragen muss, ob Google es überhaupt schafft, Fehler innerhalb von 90 Tagen zu verbessern.

Aber bei Google Admin ging irgendetwas schief: Zum einen war etwas komplett falsch, zum anderen wissen wir alle, dass ein Patch das Problem nicht unbedingt auf allen Android-Geräten löst. Sie fragen nach monatlichen Sicherheits-Updadtes? Aber wie kann man dann ein halbes Jahr an einem einzigen Patch arbeiten? Hört, hört.

Offene Sicherheitslücke in SCADA von Schneider Electric

Der Threatpost-Artikel. Die Warnung von ICS-CERT.

Willkommen in der faszinierenden Welt der kritischen Infrastrukturen! Setzen Sie sich, machen Sie es sich bequem, drücken Sie nicht auf den roten Knopf und berühren Sie niemals die Kabel, die aus diesem Ding dort herausstehen. Ja, die sollen dort herausstehen. Das ist ok. Richtig, das ist schon seit ewigen Zeiten so. Wenn Sie diese Kabel berühren, sind wir alle verloren.

SCADA-Systeme sind ein Teil kritischer Infrastrukturen, die dafür verantwortlich sind, wichtige Dinge zu steuern – von der Heizung in Ihrem Appartementgebäude bis zu Kernkraftwerken. Solche Systeme sollen nicht verändert, ausgeschaltet oder neu gestartet werden. Man spielt nicht an ihren Parametern herum und man berührt einfach nichts!

Und bevor Sie selbst etwas daran ändern, sollten Sie unseren Artikel dazu lesen. Denn auch wenn solche Systeme wahnsinnig kritisch sind, laufen sie dennoch recht häufig auf regulären PCs mit dem guten, alten Windows. Anders als Firmen, die ihre Hardware und Software zumindest alle fünf Jahre oder so erneuern, laufen einige Industrieroboter oder Zentrifugen, die ein paar tödliche Chemikalien verarbeiten, 24 Stunden am Tag, und das jahrzehntelang.

Was wurde gefunden?

Nun, in einem dieser Systeme wurde eine ganze Menge Fehler entdeckt, und zwar im Modicon M340 von Schneider Electric, in der PLC Station P34 CPU. Die Sicherheitslücken erlauben es einem Hacker, die Kontrolle über alles zu übernehmen, das von dem System gesteuert wird. Auch ein recht häufiger Fehler wurde gefunden (der übrigens regelmäßig auch in Routern und Geräten des Internet der Dinge entdeckt wird), den wir als Hard-Coder-Rechte bezeichnen.

Was auch immer fest in das industrielle SCADA-System codiert wurde, bleibt geheim (aus offensichtlichen Gründen), aber wir können davon ausgehen, dass es sich um Standard-Login-Daten handelt, die ein Hersteller bietet, um leichtere Wartung zu ermöglichen. Oder ein Hersteller vergisst einfach, ein Test-Passwort aus dem Code zu löschen. Oder jede andere Ausrede, die ihnen noch einfällt.

Wie wurde das gepatcht?

Es wurde nicht gepatcht. Zwei Wochen sind vergangen, seit der Forscher Aditya Sood die Sicherheitslücke auf der DEF CON aufgedeckt hat, aber noch ist kein Patch in Sicht. Das ist verständlich: Ein Hersteller steht hier vor einer schweren Aufgabe, denn die Herausforderung, einen Patch zu erstellen, wird hier noch herausfordernder, da die Systeme beim Kunden dafür oft Ausfallzeiten benötigen, und das ist bei vielen Kunden einfach nicht möglich.

Wie lange würde das Ausliefern des Patches also dauern? Wie lange müsste der Kunde den Stillstand hinnehmen? Funktioniert anschließend überhaupt alles? Wurden alle Besonderheiten der Endpoint-Geräte in Betracht gezogen? Alles in Allem eine Qual – wobei das dennoch eine schlechte Ausrede dafür ist, Fehler nicht auszubessern. Und es wurde schon oft genug bewiesen, dass das Trennen kritischer Infrastrukturen vom Internet oder der Schutz durch eine Firewall nicht ausreichen.

Entwickler bei der Enthüllung

Entwickler bei der Enthüllung 

Ein ungepatchter Fehler in Mac OS X

Der Threatpost-Artikel.

Und wieder kommen wir zu dem Thema der verantwortungsbewussten Veröffentlichung von Sicherheitslücken. Beim oben genannten Google-Fehler waren die Forscher fünf Monate lang still, bevor sie den Fehler öffentlich machten. Und das, obwohl sich Google selbst nur eine Frist von 90 Tagen gibt. Wie lange sollte man also warten? Wie viel Zeit gibt man einem Entwickler, eine Sicherheitslücke zu schließen?

Könnte eine zu lange Frist die Entwickler nur dazu bringen, den Patch immer wieder zu verschieben? Oder würde die sofortige Veröffentlichung der Sicherheitslücke den Entwickler dazu bringen, möglichst schnell einen Patch zu entwickeln? Wie auch immer, es gibt keinen Standard – und dennoch sind sich alle Forscher einig, dass es nicht richtig ist, eine Sicherheitslücke zu veröffentlichen, ohne vorher den entsprechenden Entwickler zu informieren.

Was wurde gefunden?

Hier ein Beispiel dafür, wenn ein Entwickler nicht oder mit zu kurzer Frist informiert wird und nicht genug Zeit für eine entsprechende Reaktion hat… Der 18 Jahre alte Sicherheitsforscher Luca Todesco veröffentlichte Details zu einer ernsten Sicherheitslücke in Mac OS X Yosemite und Mavericks (10.9.5 – 10.10.5), die es einem Angreifer erlaubt, Root-Rechte auf dem angegriffenen Gerät zu erlangen.

Der Fehler ist allerdings nicht aus der Ferne ausnutzbar: Der Angreifer muss den Nutzer dazu bringen, einen Exploit herunterzuladen und zu starten – aber das ist leider gar nicht so schwer. Es gibt auch bereits einen Proof-of-Concept. Hacker müssen den nur noch nehmen und einsetzen.

Wie wurde das gepatcht?

Tja, es wurde noch nicht gepatcht. Laut dem Forscher hat sich Apple dazu nicht geäußert, obwohl er das Unternehmen mehrmals kontaktierte. Dass er die Sicherheitslücke bereits öffentlich gemacht hat, macht ihm keine Sorgen: Er habe nur eine neue Möglichkeit für das Jailbreaking erkundet, nicht mehr. Das sei keine große Sache, sagt er.

Nun, das ist ein schlechter Vergleich: Einen Jailbreak machen Nutzer, die genau wissen, was sie tun, absolut freiwillig. Man kann einen iPhone-Nutzer nicht einfach so dazu bringen, sein Handy zu jailbreaken, außer der Nutzer will das. Und bei Todescos Fehler ist das nicht immer der Fall. Kein Wunder, dass er sich harte Kritik von seinen Kollegen anhören musste:

Unklar ist nach wie vor, ob dieser Fehler das neue Mac OS X El Capitan beeinträchtigen wird. Warten wir also auf den Patch.

Was gab es sonst noch?

Microsoft hat einen Fehler im Internet Explorer ausgebessert (naja, wenigstens hat irgendjemand irgendetwas ausgebessert), indem ein dringender Patch außer der Reihe veröffentlicht wurde – der zweite in diesem Monat.

Die privaten Daten, die Hacker von der Seitensprung-Webseite Ashley Madison gestohlen hatten, sind nun online, wie es die Hacker angekündigt hatten.

https://twitter.com/kaspersky/status/634349398198218752

Kaspersky Lab hat Blue Termite entdeckt, eine große Cyber-Spionagekampagne, der in Japan bereits einige zum Opfer gefallen sind. Es bleibt einfach nicht unentdeckt, wenn Cyber-Spione, die schon seit über zwei Jahren aktiv sind, plötzlich ihre Aktivitäten verstärken, nachdem sie einen Flash-Exploit in die Hände bekommen haben, der als Teil eines Data-Dumps veröffentlicht wurde, der wiederum vom  Hacking Team gestohlen worden war.

Oldies

„Justice“

Sehr gefährlich; befällt .COM-Dateien, wenn diese von den DOS-Funktionen 43h, 4Bh, 3Dh, 56h aufgerufen werden. Das Schadprogramm wird an das Ende der Dateien geschrieben und verändert  fünf Byte an deren Anfang (NOP; NOP; JMP Loc_Virus). Der Prozess zur Kompromittierung von COMMAND.COM nutzt die gleiche Methode wie der Lehigh-Virus. Stiehlt regelmäßig Daten, wenn diese auf das Laufwerk geschrieben werden, und schreibt sie in einen anderen Sektor. Enthält den Text „AND JUSTICE FOR ALL“. Übernimmt int 13h und int 21h.

Zitat aus „MS-DOS-Computerviren“ von Eugene Kaspersky, 1992, Seite 72.

Hinweis: Diese Kolumne spiegelt die persönliche Meinung des Autors wider. Diese kann, muss aber nicht mit der Position von Kaspersky Lab übereinstimmen. Das ist Glücksache.

Tipps
Abonnieren Sie uns und bleiben Sie auf dem neuesten Stand mit unseren Beiträgen
  • Für alle anderen Länder