Mitternachtshacking

Symantec schließt einen großen Teil von SecurityFocus und führt einige Inhalte in Symantec Connect über. Zumindest die Bugtraq-Mailingliste und die Vulnerability Datenbank sollen aber (vermutlich erstmal) erhalten bleiben.

Eigentlich habe ich darauf ja schon seit der Übernahme gewartet. Kaum war @stake bei Symantec sind die ganzen Tools wie LC (das ehemalige LophtCrack) verschwunden. So schnell konnte man gar nicht sichern wie Symantec da bereinigt hat. Nicht sehr freundlich, wenn man mich fragt. Andere Firmen (namentlich wären hier McAfee und Foundstone zu nennen) sind da etwas cooler.

Ich persönlich glaube ja, Symantec hätte SecurityFocus am liebsten schon direkt nach der Übernahme zugemacht. Insbesondere die öffentliche Schwachstellendatenbank mit den Exploits dürfte einigen Leuten bei Symantec ein Dorn im Auge sein. Aber vermutlich hat Symantec den öffentlichen Aufschrei gefürchtet. Ich bin ja mal gespannt wie lange es die Schwachstellendatenbank noch öffentlich und kostenlos gibt.

(via Heise)

Auf Securityfocus gibt es von Mark Rasch (immerhin ehemaliger Computerstrafverfolger im US Justizministerium) einen schönen Rant über das deutsche Strafrecht und den StGB 202c.

“The [German] statute requires that the commission of the criminal offense be the express purpose of the computer program. The intent of the programmer does not, apparently, matter.”

Kein Wunder, daß das Gesetz nichts taugt. Wie soll ein Programm eine Absicht vermitteln? Egal wie man es betrachtet, man erkennt immer wieder, daß unsere Gesetze von Internetausdruckern und inkompetenten Idioten im Bundesjustizministerium von Frau Zypries gemacht werden. Nur leider nicht von Fachleuten.

“Two years out, the German law has been effectively used to scare legitimate security researchers, while no reported cases have been brought against computer hackers for a violation of the hacker tools provision.”

Eine schöne Zusammenfassung. Ein völlig nutzloses Gesetz, das lediglich Schaden in der deutschen Wirtschaft und der deutschen IT-Security angerichtet hat. Es wäre mal Zeit, anzuhalten und nachzudenken. Aber die Deppen machen ja direkt weiter mit der geplanten Internetzensur der Laienministerin.

Traurig, daß das inzwischen sogar den Amerikanern aufgefallen ist.

(via The Register)

Eben auf SecurityFocus gesehen:

Schon krass …

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, genaugenommen 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?

Matt, der Hauptentwickler von Wordpress, der hier in diesem Blog eingesetzten Blog-Software schreibt über die in Wordpress in letzter Zeit aufgetretenen Sicherheitsprobleme:

• das SQL-Injection Problem neulich in der Version 2.2, das jedoch nur angemeldete Benutzer betroffen hat
• die Hintertür in Version 2.1.1, die nach einem Einbruch in den Wordpress-Server eingefügt worden ist

Nun ja. Ich fürchte, jede Software die auf PHP basiert wird zwangsläufig irgendwann Probleme bekommen. Entweder durch ein Sicherheitsproblem in PHP selbst oder durch einen Programmierfehler in der Webanwendung. Wenn man bei Securityfocus in der Vulnerability Datenbank nach PHP sucht bekommt man (Stand heute) 4499 Resultate geliefert.

Im Grunde ist es doch so: wer freiwillig eine PHP-Software auf seinen Servern einsetzt muß sich auch selbst um die Sicherheit kümmern. Bei größeren Lücken erfährt man meistens auch schnell über die typischen Medien wie Heise, SecurityFocus oder TheRegister, was los ist. Und wer sich gar nicht drum kümmern will ist vermutlich bei Blogger.de oder -.com sowieso besser aufgehoben.

Was könnte Wordpress selbst besser machen? Mir fallen zwei Sachen ein:

1. die Veröffentlichungspolitik von Wordpress könnte ein wenig besser sein. Eine Mailingliste nur für Security Announcements wäre z.B. nett
2. das Upgrade könnte etwas einfach sein. Jedesmal manuell Dateien löschen, andere Dateien reinkopieren, das ist etwas fehleranfällig. Das könnte man auch skriptbasiert lösen

Aber wenigstens steckt noch Potential in der Software. Und hey, man bekommt fast immer, wofür man bezahlt … und manchmal auch weniger.

Nach einem Bericht auf SecurityFocus will die NATO sich zukünftig auch darum kümmern, kritische IT-Infrastruktur abzusichern.

Ich habe ja schon ein paar mal angemeckert, daß in Europa zu wenig passiert. Aber ob ausgerechnet die NATO dafür geeignet ist … ich habe meine Zweifel. Das erinnert mich ein wenig an das Ãœberfliegen von Demonstranten mit Kampffliegern.

Soso, da beschwert sich auf SecurityFocus der Herr Miller, daß er beim Verkauf seiner Zero-Day Vulnerabilites über den Tisch gezogen wurde. Da hat ihm eine Regierungsbehörde 10.000 USD angeboten, an eine andere Behörde wäre er die Lücke für 80.000 USD losgeworden, wenn sie für eine bestimmte Linux-Variante funktioniert hätte und bekommen hat er am Ende 50.000 USD. Und glaubt jetzt, er hätte doch mehr verlangen können und ist beschissen worden. Eigentlich will ich das gar nicht kommentieren.

Interessant scheint mir eher, wie sich der Markt entwickelt. Die öffentlichen Angebote von Firmen wie das iDefense Vulnerability Contributor Program, das jetzt zu Verisign gehört oder die 3Com Zero-Day Initiative, ursprünglich von TippingPoint ins Leben gerufen, sind ja allgemein bekannt. Allerdings ist die Bezahlung nicht so üppig. Mehr Geld haben ganz offensichtlich die Behörden und dort wohl die Geheimdienste zur Verfügung.

Und da stellt sich vor allem die Frage, wie findet man den passenden Käufer? eBay fällt ja leider aus, die Versteigern keine Sicherheitslücken. Ich muß da wohl mal drüber nachdenken.

IPv6 hat ein lustiges Sicherheitsproblem mit einem Routing Header.

Dazu muß man erstmal wissen, wie IPv6 funktioniert. Bei IPv6 sind die Adressen nicht mehr nur 32 Bit lang, wie aktuell im Internet Protokoll sondern 128 Bit, also gerade vier mal so lang. Das Problem dabei ist, damit steigt natürlich für jedes Datenpaket der Overhead an. Ein normaler IPv4 Header hat üblicherweise 20 Byte (ohne IP-Optionen, aber die läßt eh kaum eine Firewall durch), mit den neuen Adressen hätte der Header plötzlich 44 Byte, also mehr als doppelt so groß. Mögliche Header-Optionen sind dabei noch nicht eingerechnet.

Man hat sich nun entschieden, den IPv6-Header etwas anders zu strukturieren. Der Standardheader ist immer gleich groß, nämlich 40 Byte. Durch die konstante Größe wird u.a. das Offloading, d.h. die Verarbeitung in einem extra Chip vereinfacht, der Durchsatz der Netzwerkkarten steigt. Optionen werden in IPv6 durch sogenannte “Extension Header” an den Standardheader angehängt.

Einer dieser Extension Header ist nun der Routing Header 0, kurz RH0 und der hat ein kleines Problem. Man kann da nämlich Adressen angeben, via die ein Paket geschickt werden soll. Bei IPv4 gibt es das auch, entweder als Strict oder Loose Source Routing und jeder weiß, daß das ein Problem sein kann.

Der Witz bei IPv6 ist nun, mittels RH0 kann man bis zu 88 Adressen angeben, via die ein Paket geschickt werden soll. Das ist richtig cool wenn man clevere Denial-of-Service Angriffe fahren will. Dann gibt man einfach 88 Adressen an und kann die im günstigsten Fall alle gleichzeitig DoSen. In der Praxis wird das nicht so einfach sein.

Interessant ist jedenfalls die Lösung der IETF, die für den Standard zuständig ist: Abschalten der Option. Fertig. Das hätte ich vorher auch schon sagen können.

PS:

Wenn ich mich so umkucke, scheinen die klassischen TFN, Stacheldraht und Trinoo immer noch die bekanntesten DDoS-Programme zu sein. Es scheint an der Zeit, mal was geeignetes für IPv6 zu basteln

Auf The Register: Ein New-Yorker Sicherheitsforscher hat weniger als 12 Stunden gebraucht um eine neue Sicherheitslücke in Apples Safari zu finden und damit einen Preis von 10.000 USD zu gewinnen. Den Preis hat übrigens Tipping Point gesponsort.

Wieso wundert mich das jetzt alles nicht?

Aber werden die Systeme dadurch sicherer?

Die Entwicklungszeit von Patches und Updates für Sicherheitslücken in Microsoft-Produkten läßt mich manchmal ein wenig staunen:

Aus dem eEye Research Portal (alle mit Remote Code Execution):

• Windows Workstation Service NetpManageIPCConnect Buffer Overflow: 112 Tage
• Windows Media Player BMP Heap Overflow: 120 Tage
• Windows Metafile Multiple Heap Overflows: 224 Tage
• Windows Local Security Authority Service Remote Buffer Overflow: 188 Tage

Aus der Bugtraq Mailingliste:

• Xbox 360 Hypervisor Privilege Escalation Vulnerability: 6 Tage

Mit der Hypervisor Privilege Escalation lassen sich z.B. kopierte Spiele auf der Xbox spielen oder Linux installieren. Also nichts, was Remote durchführbar wäre.

Ich denke man erkennt die Prioritäten …