Mitternachtshacking

Manchmal finde ich die Briten ja putzig. Ok, die Inselaffen haben einen an der Waffel und drehen völlig am Rad. Eigene Staatsbürger an die USA ausliefern geht schon mal gar nicht. Leute einsperren weil die Verschlüsselungspasswörter nicht rausrücken wollen geht auch nicht. Und sämtliche Städte mit Kameras zupflastern auch nicht. Aber dafür haben sie die BBC. Und ein Informationsfreiheitsgesetz, das diesen Namen verdient, im Gegensatz zu Deutschland.

Interessant wird es, wenn man sich ansieht was dann so alles veröffentlicht wird. Beispielsweise im National Risk Register. Das beschäftigt sich eigentlich mit der Katastrophenvorsorge in Großbritannien aber dazu gehören inzwischen neben Flut, Sturm und Unfällen auch Cyber Attacks. Die Risikobewertung unterscheidet dabei zwei Kategorien: Cyber Attacks: Infrastructure und Cyber Attacks: Data Confidentiality. Die Unterscheidung macht Sinn. Angriffe auf kritische Infrastruktur finden relativ selten statt, vertrauliche Daten gehen aber ständig verloren. Vor allem in Großbritannien. Entsprehend fällt die Bewertung aus.

Cyber Attacks: Infrastructure – geringe Eintrittswahrscheinlichkeit, mittlerer Schaden. Höheren Schaden verursachen beispielsweise Major Transport Incidents, Major Industrial Incidents, Costal Flooding und Pandemic Human Diseases.

Cyber Attacks: Data Confidentiality – Hohe Eintrittswahrscheinlichkeit, geringer Schaden. Eine niedrigeren Schaden hat gar nichts, also richtig wichtig kann der Datenschutz nicht sein. Eine höhere Eintrittswahrscheinlichkeit hat nur noch Attacks on Transport. Wobei ich mich nicht erinnern kann, dass soooo viele Terroranschläge auf öffentliche Transportmittel passieren. Ich glaube da ist mehr die Angst und Panik der Vater des Gedanken. Sitzt deren Innenminister eigentlich auch im Rollstuhl?

Man kann sich den Risk Assessment Process jedenfalls anschauen, der erläutert wie die Briten da vorgehen. Und das kann man garantiert auch mal irgendwo wieder verwenden.

Nmap startet mal wieder eine Umfrage nach coolen Webseiten und Produkten:

http://nmap.org/survey/

Ihr könnt Eure Meinung zu ein paar coolen neuen Features abgeben:

Beispielsweise einen 1. April Mode: „Occasionally give bogus results to keep users on their toes“ oder eine animierte Online-Hilfe: „Animated paper clip helper to provide suggestions and advice in formulating your scan“. Zumindest das zweite kennen wir ja schon von Microsoft 🙂

Klar, ein riesiges Werksgelände lässt sich kaum zuverlässig sichern aber gerade Kraftwerke sollten eigentlich gut gesichert sein. Nicht so in Großbritannien, offensichtlich. Da ist ein bisher unbekannter Mann in das Eon Kohlekraftwerk Kingsnorth eingedrungen und hat erfolgreich eine 500 MW Hauptturbine abgeschaltet. Das Kraftwerk selbst wurde bis auf den Ausfall nicht weiter beschädigt und konnte nach einigen Stunden wieder an’s Netz gehen.

Das interessante an diesem Vorfall ist, dass ein einzelner das geschafft hat. Kein großes Ops-Team, keine Unterstützung oder Ablenkung, kein Social Engineering … einfach über den Zaun (Alarmanlage?) in die Maschinenhalle hinein (Türschlösser?) und das System runtergefahren (Passwörter?).

Aus eigener Erfahrung mit großen Anlagen kann sich sagen, dass Türen meistens nicht abgeschlossen sind da im Notfall schnell jemand hinein muss. Auch Computersysteme sind oft nicht mit Passwörtern versehen, aus dem gleichen Grund, im Notfall muss sofort jemand ran können. Das ist ein bekanntes Problem in der Produktion und deshalb wird besonderen Wert auf die Außensicherung gelegt. Warum die hier nicht griff … keine Ahnung. Da werden sich die Betreiber ein paar kritische Fragen stellen lassen müssen.

Oder Eon hat halt mal an der falschen Stelle gespart.

Ich habe neulich bei der Durchsicht des neuen Telepolis-Hefts schon Prof. Beyerer vom Fraunhofer IITB kritisiert, der glaubt alles wäre gut, sicher und toll und bemängelt, es gäbe generell von Fraunhofer praktisch keine relevanten und brauchbaren Veröffentlichungen zur IT-Sicherheit in kritischen Infrastrukturen.

Jetzt durfte sich Prof. Beyerer bei Spiegel Online (der Link fliegt wieder raus, sobald der Artikel Geld kostet!) auslassen:

„Der Informatiker Jürgen Beyerer plädiert dafür, so manche Ergebnisse geheim zu halten.“

Ich nehme an, er meint da insbesondere seine eigenen. Die sind so gut, so toll und so fortschrittlich, die müssen geheimgehalten werden weil wenn die Bösen(TM) seine Forschung in die Finger bekommen würden, dann würde natürlich die Welt untergehen.

Und dann seine Kernaussage:

„Sicherlich muss man für Sicherheitsforschung an besonders sensiblen Themen, deren Ergebnisse man einer breiten Öffentlichkeit nicht im Detail zugänglich machen möchte, Kontrollmechanismen festlegen, die wissenschaftliche Qualität und prinzipiell gesellschaftliche Akzeptanz sichern. Die Beteiligten bei der Sicherheitsforschung für kritische Infrastrukturen – Wissenschaftler, Betreiber kritischer Infrastrukturen, Bedarfsträger, Fördermittelgeber, öffentliche Auftraggeber und Politik – bilden auch selbst schon eine recht große Community, in der meines Erachtens sehr verantwortungsbewusst auch kritische Fragen, insbesondere Fragen der gesellschaftlichen Akzeptanz, diskutiert werden. Man sollte daher die Kontrollmechanismen innerhalb dieser Community nicht unterschätzen und auch darauf vertrauen.“

Den Absatz sagt eigentlich alles über das Verständnis von Prof. Beyerer aus. Der Staat soll seine Arbeit finanzieren (das sind die öffentlichen Auftraggeber, also der Steuerzahler) und ein möglichst kleines Konsortium kontrolliert die Geldvergabe (an sich selbst) und die Veröffentlichung der Ergebnisse. Unternehmen aus der freien Wirtschaft kommen in seinem staatlich gelenkten Weltbild schon gar nicht mehr vor. So wird jedem Dritten die Möglichkeit genommen, die Verwendung der Gelder zu kontrollieren aber dafür ist die Welt von Hr. Beyerer ein wenig sicherer.

Ich hoffe die Haltung von Prof. Beyerer ist nicht repräsentativ für die gesamte Fraunhofer Gesellschaft.

Es gibt viele Sicherheitslücken für die keine öffentlichen Exploits verfügbar sind und scheinbar auch nicht mehr entwickelt werden. Ein Beispiel ist eine der aktuellen Sicherheitslücken in Apple Quicktime. Hier gibt es auf SecurityFocus eine Meldung „Apple QuickTime Panorama Sample Atoms Remote Heap Buffer Overflow Vulnerability“ mit der Bugtraq-ID 26342 und wenn man nach dem Exploit schauen möchte erhält man die Meldung:

„Currently we are not aware of any exploits for this issue. If you feel we are in error or if you are aware of more recent information, please mail us at: vuldb@securityfocus.com.“

Klingt gut. Die Risikobewertung sieht dann vielleicht so aus:

Das Problem mit dieser Risikobewertung ist der zeitliche Verlauf. Aufgrund der Einstufung einer Schwachstelle als „normal“ unterbleibt gerade bei Systemen in einer Produktionsanlage oft das Testen und Installieren eines Patches. Gerne auch mal für einige Jahre. Wenn dann sehr viel später ein Exploit programmiert wird, springt das Risiko von „normal“ auf „hoch“, es gibt jedoch niemanden mehr, der diese Schwachstelle und das zugehörige Exploitpotential beobachtet.

Ein sehr schönes Beispiel ist gerade auf SecurityFocus zu finden. Die Schwachstelle „Sun Solaris RWall Daemon Syslog Format String Vulnerability“ mit der BID 4639 ist schon etwas älter, genau genommen 2002 von Gobbles (kann sich eigentlich noch jemand an den Gobbles-Krieg gegen Theo de Raad und den Apache-scalp.c chunked encoding Bug Exploit erinnern?) entdeckt worden und hat lange keine größere Rolle gespielt.

Jetzt steht diese uralte Lücke plötzlich ganz weit oben mit dem Vermerk „Updated: Nov 08 2007 12:05 AM“ und auf der Exploit-Seite findet man den Hinweis:

„UPDATE: Core Security Technologies has developed a working commercial exploit for its CORE IMPACT product. This exploit is not otherwise publicly available or known to be circulating in the wild.“

Den gleichen Vermerk findet man in mehreren Einträgen, vermutlich Folge eines neuen Releases von Core Impact. Betroffen sind mindestens die BID 3681, 4639 und 1480.

Beobachtet eigentlich noch irgendwer die alten ungepatchten Lücken über die man vor vier oder fünf Jahren mal lange diskutiert hatte?

Maskierte und bewaffnete Räuber haben das Rechenzentrum des US-Hosters C I Host gestürmt und diverse Server von C I sowie von Kunden mitgenommen. Laut Medienberichten ist das bereits der vierte Vorfall in nur zwei Jahren. Wenn man sich die Liste der Sicherheitsmaßnahmen anschaut, wundert man sich natürlich schon, wie solche Vorfälle passieren können. Andererseits wurde ein Mitarbeiter mit einer Waffe bedroht, gefesselt und niedergeschlagen, ich denke gegen bewaffnete Räuber würde sich in Deutschland auch kaum ein Hoster zur Wehr setzen können.

Interessant finde ich in diesem Zusammenhang die Reaktion des Hosters. Mehrere Kunden die Hardware und möglicherweise sensible Daten durch den Raub verloren haben, beschwerten sich, nicht informiert worden zu sein. Angeblich habe einem Kunden der Support erzählt, seine (geklauten) Server seien nicht erreichbar, weil ein Router defekt sei. Wenn das stimmt, wäre das ein Grund dieses Unternehmen auf die schwarze Liste der Firmen zu schreiben mit denen man nie wieder in Geschäftsbeziehungen treten möchte.

Andererseits bestätigt das mal wieder das Schichtenmodell aus dem BSI Grundschutz:

• Schicht 1: Übergreifende Aspekte
• Schicht 2: Infrastruktur
• Schicht 3: IT-Systeme
• Schicht 4: Netze
• Schicht 5: IT-Anwendungen

Es macht am Ende des Tages einfach wenig Sinn, Firewalls, Virenscanner und Intrusion Detection Systeme zum Schutz der Daten installiert zu haben, wenn die komplette Hardware mit allen Daten verschwindet. Das Absichern der Infrastruktur ist nun mal Voraussetzung für einen sicheren IT-Betrieb. Und, das betrifft nicht nur die Server selbst sondern natürlich auch Backup-Bänder die ebenfalls wichtige unternehmenskritische Daten enthalten.

Ein paar Beispiele:

• 2003 werden dem australischen Zoll wichtige Systeme zur Terror-Abwehr geklaut
• 2005 gehen Backup-Tapes der Citigroup, Bank of America und Time Warner verloren
• 2006 verliert Ernst & Young, der Spezialist für verlorene Laptops Daten von Hotels.com, Nokia, HP, BP, IBM, Sun Microsystems und Cisco

Ich denke wir werden weitere Schlagzeilen in den nächsten Wochen und Monaten erleben.

und natürlich ohne, dass der Benutzer das wollte und davon gewusst hat.

Das hatten wir neulich erst und natürlich hat Microsoft versprochen, das nie wieder zu tun. Aber mal ehrlich, wer glaubt Microsoft eigentlich noch irgendetwas? Nicht mal Google ist so evil wie Microsoft.

Diesmal war angeblich entweder Microsoft Office oder Microsoft OneCare schuld, aber so genau weiß Microsoft das selbst nicht. Sie untersuchen noch die eingeschickten Logfiles. Ich könnte wetten, da stellt sich dann raus, dass Microsoft angeblich wieder an nichts schuld ist.

Wenn allerdings die Microsoft Programmierer selbst nicht wissen, warum ihr eigenes Update ungewünscht Aktualisierungen installiert … dann wird es allerdings haarig. Vielleicht ist es eben doch recht trivial möglich, als Hacker Updates in das System einzuschleusen, die dann an Millionen von Rechner verteilt werden … warum noch Viren programmieren und Spam verschicken, wenn die Verteilung auch von Microsoft übernommen werden kann.

Tödlich wäre das in Produktionsanlagen! Soll ich mir langsam sorgen machen?

Cisco löst seine Forschungsgruppe zu Scada-Security auf. Außer ein paar BGP-Tools ist nicht so viel rausgekommen, das meiste ist eh Open Source. Aber es gibt ein paar nette Links zu den relevanten Tools:

• Safe Mapping and Reporting Tool (SMART)
• ScadaSafe
• Modbus/TCP Filtering Firewall
• SCADA HoneyNet Project

Ich werde mir das eine oder andere mal demnächst anschauen.

(via Heise)

… oder so ähnlich.

Das US Department of Homeland Security hat jedenfalls auf CNN.com ein Video veröffentlicht, das die Zerstörung eines Stromgenerators durch einen Hackerangriff zeigt. Angeblich sei es auch möglich, vergleichbare Angriffe gegen große Anlagen und Umspannwerke durchzuführen.

Über die Sicherheit von wichtigen Anlagen, sogenannter kritischer Infrastruktur gibt es seit längerem große Diskussionen. Auf der einen Seite zeigen Penetrationstests z.B. von ISS, dass Angriffe sehr wohl möglich sind und mit einfachsten Mitteln durchgeführt werden können. Gerade in den komplexen SCADA-Protokollen wie OPC werden immer wieder Sicherheitslücken gefunden. Andererseits halten Forscher wie Bruce Schneider die Gefahr für übertrieben.

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat bekanntlich einen Leitfaden für kritische Infrastrukturen veröffentlicht, das Bundesinnenministerium (BMI) hat sogar ein Sicherheitskonzept beigesteuert.

Ich fürchte jedoch, so richtig ins Bewusstsein der Bevölkerung und der Verantwortlichen treten die Risiken und notwendigen Maßnahmen erst, wenn die ersten richtig großen Schäden aufgetreten sind. Eon, RWE, Vattenfall und EnBW sind zur Zeit zu sehr damit beschäftigt, die Bevölkerung auszunehmen als sich konsequent mit den diversen Risiken, angefangen mit Thomasstahl (RWE) über die Kernkraftwerke (Vattenfall) bis hin zur Ausfallsicherheit im Transport (Eon) zu beschäftigen.

Über das Buch „Normal Accidents“ von Charles Perrow und die Zusammenfassung von Dick Piccard wollte ich schon länger was schreiben aber irgendwie hat immer die Zeit gefehlt. Perrow hängt seine Beispiele am Kernreaktorunfall in Three Mile Island 1979 auf, man kann jedoch leicht Analogien zu modernen IT-Infrastrukturen, insbesondere auch in der Produktion ziehen. Die Begriffe mit denen wir im IT-Risikomanagement arbeiten sind im Grunde jedoch die gleichen.

Es gibt Fehler und Ausfälle („Discrete Failures“), die an einer Stelle auftreten und an und für sich gut verstanden sind. Ein Ausfall einer Festplatte könnte so ein Fehler sein. Um den Schaden solcher Ausfälle zu minimieren werden fehlertolerante Systeme eingesetzt, d.h. wichtige Server enthalten redundante Platten, redundante Netzteile, etc. und wenn eine Komponenten ausfällt bleibt das Gesamtsystem erhalten. Damit versucht man einen „Single Point of Failure“ zu vermeiden.

Gleichzeitig ist die gesamte Infrastruktur immer stärker und enger vernetzt, man nennt das auch „tight coupling“. Solange daher nur ein diskreter Ausfall auftritt bleibt die Situation leicht beherrschbar. Wenn jedoch mehrere solcher diskreter Ausfälle gleichzeitig auftreten dann kann aufgrund der hohen Vernetzung leicht eine Situation eintreten, in der die verschiedenen Ausfälle nicht mehr zuverlässig identifiziert werden können und durch das Zusammenwirken der eigentlich harmlosen Einzelfehler ein hoher Schaden eintritt. Perrow spricht hier von „Interactive Complexity“.

Ein „Normal Accident“ ist ein Unfall oder Schaden, der aufgrund des Zusammenspiels mehrerer für sich genommen harmloser Einzelfehler auftritt, die in Summe kaum noch beherrschbar sind. Solche Unfälle sind auf Dauer kaum vermeidbar, da Fehler mit einer gewissen Wahrscheinlichkeit auftreten und zufällig auch Häufungen vorkommen können.

Um diese Unfälle zu minimieren sind mehrere Maßnahmen hilfreich:

•  Effizentes Risikoassessment mit einer realistischen Risikoanalyse zur Bewertung der Gefahren und Schäden
• Minimierung der möglichen Schäden, um Katastrophen zu vermeiden. Hier können oft bereits in der Planung einer Infrastruktur schlimme Fehler vermieden werden
• Vermeidung von Technologie, die nicht beherrschbar sind. Oft wäre es besser ein stabil betriebenes System mit geringerer Funktionalität zu nutzen als ein unsicheres das jedoch ein paar Gimmicks mehr hat
• Vermeidung zu starker Integration und Vernetzung, damit sich Schäden nicht ausbreiten können

Vieles davon lässt sich auch in der IT gut umsetzen. Es scheitert jedoch oft am Willen. Dazu vielleicht später mehr.