Suchen

Archiv der 'Security' Kategorie

Anti Rootkit Programme im Test english

m.schmidt 18. January, 2007

Es liegt in der Natur von Rootkits, das diese schwer zu entdecken sind, auch wenn ein großteil der Security Suites auf dem Markt sich diese Fähigkeiten auf die Fahnen schreibt. Die Information Week hat nun diverse Spezialprogramme evaluiert, welche sich auf die Endeckung und Beseitigung von Rootkis spezialisiert haben.
Anzumerken bleibt, das jedoch keine Software der Welt garantieren kann, das Schadprogramme Rückstands entfernt wurden, so dass eine Neuinstallation des Systems oftmals anzuraten ist.

Hin und wieder wundern sich Administratoren, warum aus ihren Netzen heraus p2p Programme wie Skype oder eMule funktionieren, wo doch die Firewall eingehenden Datenverkehr rigoros blockiert.
Ich möchte nun versuchen etwas Licht in dieses eigenartig scheinende Verhalten zu bringen.
Bei den genannten Programmen handelt es sich nicht um reine p2p Protokolle, es spielt immer ein Server eine entscheidende Rolle.
Nehmen wir an, Alice (IP 10.0.0.1) möchte mit Bob (11.0.0.1) kommunizieren. Dafür schickt sie eine entsprechende Anfrage an den Server, welcher diese an Bob weiterleitet, und ihm zusätzlich die Information gibt, das Alice Port 2020 verwendet. Bobs Firewall lässt die Pakete des Servers durch, da zu diesem eine permanente TCP Verbindung besteht. Nun schickt Bob ein UDP (Port 2020) an Alice. Wie erwartet blockt die Firewall von Alice dieses Paket, die Firewall von Bob jedoch erlaubt nun Antworten von Alice. Sobald Alice nun ihrerseits ein Paket an Bob schickt, erlaubt auch ihre Firewall die Kommunikation, welche jetzt p2p zwischen den Partnern stattfindet.
Genutzt wird dabei die Eigenschaft vieler Firewalls, UDP auch „verbindungsorientiert“ zu betrachten. Stimmen die Adressen und Portnummern, so werden die übertragenen Daten schon zu einer Verbindung gehören, eine Schlussfolgerung die nicht immer zutreffend ist. Im Gegensatz dazu werden bei TCP echte Verbindungen ausgehandelt.
Man sollte also sehr genau darüber nachdenken, ob wirklich sämtlicher ausgehender Verkehr erwünscht ist.

Das sechste Türchen – RedHat absichern english

m.schmidt 6. December, 2006

Heute mal wieder ein sehr nützlicher Beitrag zum Thema Server Hardening. Da ich mich hin und wieder mit RedHat auseinander zusetzen habe (muss), bin ich auf diesen Artikel von Werner Puschitz aufmerksam geworden. Eine sehr nützliche Liste, mit einigen geschickten Tricks, die ich so bisher noch nicht kannte. Zum Beispiel scp ermöglichen, ohne Logins zu gewähren.

Update zu md5 english

m.schmidt 5. December, 2006

Update zum gestrigen Artikel

Nach einer Rechenzeit von 11 Stunden (naja, nur 900 Mhz) sind auch meine eigenen Binarys erzeugt. Gleiche Größe, gleiche md5 Summe, unterschiedliches verhalten. Während die good einen Vers in Englisch ausgibt, spricht evil in der dunklen Sprache von Mordor.

Viertes Türchen - die Sicherheit von md5 english

m.schmidt 4. December, 2006

Am Wochenende habe ich endlich mal Zeit gefunden, mich näher mit md5 zu beschäftigen, genauer gesagt mit den Angriffen auf diesen Algorithmus. Einer dieser Angriffe von Xiaoyun Wang beschäftigt sich mit der Berechenbarkeit von Kollisionen. Demnach benötigt man zwei Initiale Vektoren mit gleichem md5 Hash, an welche dann beliebige Daten angehängt werden können, die Hashwerte jedoch gleich bleiben. (dies ist ein inhärentes Problem Blockbasierender (Hash)verfahren: hat man einmal zwei Blöcke mit gleichem Hash, ensteht durch Konkatenation beliebiger Daten an diese Blöcke wieder ein gleicher Hash) Mathematisch ausgedrückt:

if md5(x)==md5(y) then md5(x+z)=md5(y+z)

Die initialen Vektoren unterscheiden sich in Wangs Beispiel nur um 6 Bit, hängt man jedoch mehrere solcher Blöcke aneinander, lassen sich mehrere Bytes an frei belegbaren Nutzdaten gewinnen. Eine genauere, mathematische Beschreibung würde den Rahmen dieses Artikels sprengen, deshalb sei neben dem eingangs genannten Paper noch auf die Quelle von Peter Selinger verwiesen, in welcher die Funktionsweise der Kollisionsermittlung näher erläutert wird. Hier soll ein kleines Beispiel verdeutlichen, was sich mit zwei initialen Vektoren anstellen lässt. Die beiden Dateien vec1 und vec2 besitzen den gleichen md5 Hash, sind jedoch verschieden, wie der sha1 Hash zeigt.

ftp:/md5coll# md5sum vec*; sha1sum vec*
da5c61e1edc0f18337e46418e48c1290 vec1
da5c61e1edc0f18337e46418e48c1290 vec2
8f42c29f6ac45423d2a7dd614d666a26e39f29ee vec1
dfce366c23c88044ad57a5eaa7d5420024a7fd14 vec2

Selbst das Anhängen eines zufälligen 32K Blocks ändert nichts an diesem Zustand.

ftp:/md5coll# dd if=/dev/urandom of=foo bs=32460 count=1
1+0 Datensätze ein
1+0 Datensätze aus
32460 Bytes (32 kB) kopiert, 0,044771 Sekunden, 725 kB/s
ftp:/md5coll# cat foo >> vec1
ftp:/md5coll# cat foo >> vec2
ftp:/md5coll# md5sum vec*; sha1sum vec*
64dbc8e1f2cc1855f09f37528181484b vec1
64dbc8e1f2cc1855f09f37528181484b vec2
b73dde6a98b46c53fd32fb709330dad835a9d116 vec1
e60795346ab6041ff1a315e8ca745c854ffe6ae2 vec2

Obwohl der Angriff noch nicht vollständig veröffentlicht ist (es gibt nur initiale Vektoren, theoretisch wäre es aber denkbar, Doppelgängerblöcke auch in der Mitte von zu hashenden Daten zu haben) lassen sich damit schon eine nette Anzahl Spielereien betreiben.

Zum Beispiel ein Binary, welches auf seinem Weg durch Filesharingbörsen Informationen sammelt. Kazaa hasht Dateien nicht komplett, sondern tut dies jeweils mit 32K großen Blöcken. Es ist also möglich, alle 32K ein Bit für die eigenen Zwecke zu nutzen. Bei einem 60MB großen Binary sind das demnach 1920 Bit Payload, ohne das sich der Hash ändert (würde er dies tun, so würde das Binary x-mal in den Filesharingbörsen auftauchen, was ziemlich auffällig ist). Nun braucht das Binary nicht mehr „nach Hause telefonieren“, man kann es sich von Zeit zu Zeit aus den Filesharingbörsen ziehen und den Payload auswerten. (zu sammelnde Daten wären etwa MAC Adressen, Rechnernamen, email Daten u.s.w.)

Auch Security Audit Tools, welche die md5 Summen von Dateien auf der Platte überwachen, bekommen davon nichts mit. Peter Selinger hält auf seiner Seite ein nettes Tool bereit, mit dem sich Paare von ausführbaren Dateien erzeugen lassen, welche den gleichen md5 Hash besitzen, sich aber unterschiedlich verhalten.

Da mein PC noch an einem eigenen Beispiel rechnet verwende ich die vorbereiteten Dateien.

mschmidt@ftp:~$ md5sum erase; md5sum hello; sha1sum erase; sha1sum hello
da5c61e1edc0f18337e46418e48c1290 erase
da5c61e1edc0f18337e46418e48c1290 hello
dfce366c23c88044ad57a5eaa7d5420024a7fd14 erase
8f42c29f6ac45423d2a7dd614d666a26e39f29ee hello
mschmidt@ftp:~$ ./erase This program is evil!!!
Erasing hard drive…1Gb…2Gb… just kidding! Nothing was erased.
(press enter to quit)
mschmidt@ftp:~$ ./hello
Hello, world! (press enter to quit)

Irgendwie beängstigend, das

if md5(binA)==md5(binB)thenbehaviour(binA)==behaviour(binB)

nicht mehr wirklich gillt.

Nun, ist md5 damit am Ende? Sicher nicht, denn die Einsatzszenarien der (bisher veröffentlichten) Angriffe sind doch noch sehr begrenzt. (Der genaue Algorithus zur Kollisionsfindung, und dessen Möglichkeiten, sind noch nicht vollständig bekannt) Es sollte jedoch klar sein, das zumindest der Anfang des Endes von md5 begonnen hat, und ein Umstieg auf Alternativen (sha1) nicht früh genug erfolgen kann.

Wer tiefer gehendes Interesse an der Materie hat, dem sei darüber hinaus dieses Buch ans Herz gelegt, besonders die Kapitel 3 und 11 zeigen die Möglichkeiten und Gefahren der md5 Kollision

Update 

Das zweite Türchen – Apache absichern english

m.schmidt 2. December, 2006

Heute geht es um den beliebtesten Webserver. Wie Server abgesichert werden sollte prinzipiell klar sein. Zugriffsberechtigungen beachten, nicht benötigte Module/Dienste deaktivieren, aktuelle Versionen verwenden u.s.w.

Pete Freitag hat all dies, auf den Apache konkretisiert, in einer übersichtlichen Liste zusammengetragen, welche für mich eine liebgewordene Checkliste darstellt, besonders wenn mal “schnell” ein Server gestrickt werden soll, oder eine fremde Installation zu prüfen ist.
Wer sich näher mit dem Thema auseinander zusetzen gedenkt, dem sei dieses Buch von O’Reilly wärmstes empfohlen.

Security 2.0 english

m.schmidt 28. November, 2006

Nach Web 2.0 nun also Security 2.0, zumindest nach dem Willen von Symantec. Gemeine Stimmen behaupten, Symantec versteht darunter die Veröffentlichung ihrer bisherigen Security Produkte als „Anti Pattern“ ;)
Freilich hat Symantic selbst höhere Ziele, verspricht allerlei Automatismmen, um die wachsenden Herausforderungen im Security Umfeld, auch im Hinblick auf kommende gesetzliche Regelungen, bewältigen zu können.
Doch obwohl Google schon über eine halbe Million Beiträge zu Security 2.0 findet, besteht der Großteil dieser Meldungen aus BulshitBingo 2.0 …der Rest aus Bashing 2.0
Erschreckend bleibt festzustellen, das geschicktes Marketing oftmals ertagreicher scheint als know-how. Schade eigentlich, ich wäre auf jeden Fall dafür Security 1.0 aus dem Betastadium zu heben, ehe wir wie im Rausch Versionsnummern inkrementieren :) Vielleicht sogar gleich auf 3.0?

Über den Sinn und Unsinn von Desktop Firewalls wurde vielerorts bereits hinlänglich gestritten. Größter Kritikpunkt: Der normale Nutzer weiß nicht, welchen Programmen und Diensten er welche Art von Verkehr erlauben soll. Mit dem Produkt ‘Integrity‘ bietet Checkpoint dazu ein beeindruckend mächtiges Werkzeug, dieses Problem zu lösen.
Nun, Integrity ist kein Produkt aus dem Hause Checkpoint, sondern gelangte durch den Kauf von ZoneLabs ins Portfolio, und so stellt sich die GUI des Clients auch dar wie die bekannte Desktop Firewall ZomeAlarm.
Doch Checkpoint hat zusätzlich zu diesem Client einen Server entwickelt, welcher das Policy Management (Verwaltung und Verteilung) übernimmt.
Dieser kann Restriktionen auf Zonen- Protokoll- und Applikationsebene einrichten und verwalten. Protokollebene ist klar, eine schnöde Layer 4 Firewall, die anhand von Portnummern und Adressen aus den verschiedenen Zonen (trusted, internet) Pakete zulässt – oder eben nicht. Mächtig sind die Regeln auf Programmebene. Der Client gestattet nur bekannten Programmen (basierend auf Filename, Checksumme u.ä.) den Zugriff aus bestimmte Netzwerkbereiche, oder hindert diese Programme gar ganz an der Ausführung. Ebenso kann er feststellen, welche AV Software installiert ist, ob diese aktuell ist, oder etwa welche Windows Hotfixes auf dem System installiert sind. Erfüllt der Client bestimmte Anforderungen nicht, wird ihm der Netzzugang eingeschränkt, oder ganz verboten.

Das Management solch einer Fülle von Programmen und Regeln kann schnell unübersichtlich werden, doch auch hier hilft der Integrity Server weiter. Zum einen meldet jeder Client die Programme, welche ins Internet wollen, an den Server (und behandelt die erstmal nach seinem default Schema). So bekommt der Administrator einen Überblick, welche Software auf welchen Versionsständen in seinem Netz aktiv ist. Danach kann er anhand dieser Liste Regeln für die Programme definieren. Ein zweites Hilfsmittel sind Referenzsysteme, nach dem Motto: “Die Software auf diesem System ist auch auf allen anderen erlaubt”. So genügt es, ein System aktuell zu halten, die Restlichen folgen von allein, denn wird ihnen aufgrund eines fehlenden Patches der Netzzugang verwehrt, kann der Integrity Server zusammen mit der Fehlermeldung auch gleich den entsprechenden Patch ausliefern.

In Zeiten, in denen Laptops und PDA’s immer selbstverständlicher werden, und Mitarbeiter durchaus auch in wenig vertrauenswürdigen Netzen unterwegs sind, ist diese Lösung sicher eine gute Hilfe für jeden Administrator, um nicht nur die Schnittstelle seines Netzes mit der Außenwelt, sondern auch den Verkehr in seinem Netz zu überwachen. Denn die Lösung funktioniert auch mit VPN Verbindungen: Während eMule läuft, ist kein VPN möglich.

Integrity ist hier noch lange nicht am Ende, falls jemand Interesse hat möge er einen kurzen Kommentar hinterlassen, evtl. entsteht ein zweiter Teil zum Überblick, oder ein kurzes HowTo.

Mit Google auf Virensuche english

m.schmidt 14. November, 2006

H.D. Moore, Vater des Metasploit Frameworks, hat ein neues interessantes Projekt vorgestellt. Mit Hilfe von Google ermöglicht seine Malware Suchmaschine das finden von von ebensolcher Software.

Das Konzept dahinter ist recht simpel, man bedient sich einfach bekannter Fingeprints von bösartiger Software und befragt Google danach. Der Auslöser für diese Idee war nach Herrn Moore’s Aussagen der Versuch von Websense, gleiches mittels SOAP und der Google API zu erreichen. Jedoch ist diese Variante nicht frei zugänglich, und zudem auch lange nicht so mächtig wie einst propagiert.

Warum man nach Viren suchen soll kann viele Gründe haben. Forschung zum Beispiel, oder um die eigene Security Policy zu testen. Doch hier ist Vorsicht geboten. Ist ein Wurm ersteinmal von Google indiziert, kann er mit Sicherheit als alter Hut gelten. Eine darauf basierende Aussage über die Sicherheit der eigenen Anti Viren Lösung dürfte recht wertlos sein.

Zwei Regeln für jede Firewall english

m.schmidt 11. November, 2006

Eine Firewall sollte das dahinter liegende Netzwerk beschützen, und tut dies so gut es ihre Regelbasis zulässt. Demnach ist eine Firewall nur so gut wie ihr Administrator. In der Literatur wird immer wieder von zwei Regeln gesprochen, die quasi als obligatorisch angesehen werden. Unbestritten ist die „Cleanup Rule“ eine solche Regel. Sie stellt im Allgemeinen den Abschluss der Regelbasis dar, und blockt jedwede Kommunikation, die bis dahin nicht erlaubt wurde. Die zweite dieser Standardregeln ist oft eine der ersten, die so genannte „Stealth Rule“. Sie verbietet jede direkte Kommunikation mit der Firewall selbst, so das diese quasi unsichtbar wird. Natürlich muss der Administrator dafür Sorge tragen, das er sich damit nicht selbst aussperrt. Bei vielen Produkten geschieht dies über vordefinierte implizierte Regeln, die den Verbindungsaufbau zum Firewallmanagement von bestimmten Rechnern aus erlauben.

Nun, ich sehe diese Regel durchaus kritisch. Natürlich sollte man kein unnötiges Risiko eingehen, und zum Beispiel ssh „von außen“ verbieten, wenn man ohnehin nicht vorhat, es derart zu nutzen. Schließlich muss man einem Angreifer nicht die Chance geben, das Passwort dafür zu erraten. Das auf der Firewall keine weiteren Dienste laufen sollten, welche nicht unbedingt notwendig sind, bedarf eigentlich keiner weiteren Erwähnung. Bleibt noch ICMP. Ist dessen Sperrung notwendig? Mit, wie es bei Planetopia hieße, „einschlägigen Tools“ (ping, nmap) lässt sich eine Menge über das System in Erfahrung bringen. In der Vergangenheit wurde ICMP auch für Angriffe genutzt, wobei der „Ping of Death“ wohl die bekannteste Attacke ist. Wieso also solche Risiken auf sich nehmen, und dem Angreifer einige Ansatzpunkte für Angriffe liefern? Es gibt aber auch Stimmen, welche ICMP als derart essentiell ansehen, das dessen Einschränkung für sie einen nicht hinnehmbaren Verlust darstellt. In der Tat ist Netzwerkdiagnose ohne ICMP gelinde gesagt ein Ding der Unmöglichkeit. Ich möchte mit dieser Einleitung gern eine kleine Diskussion über das Für und wieder der „Stealth Rule“ beginnen. Wohlgemerkt geht es dabei um Verbindungen zur Firewall, ob, wie und wo ICMP im restlichen Netz behandelt wird soll hier zweitrangig sein.