12. Januar 2008
Viele Blogs, insbesondere die mit vielen Kommentierenden und viel Spam benötigen gute Verfahren wie Captchas, um die Spammer außen vor zu halten. Reine Spamfilter wie Akismet, die bei mir und meinem geringen Aufkommen gut funktionieren sind für große Seiten kaum zu gebrauchen, weil das Reporting jedes Spams die Datenbank voll belastet. Robert Basic kann da ein Lied von singen.
Die einfachen und billigen Verfahren funktionieren jedoch auch nicht ganz sauber. So gibt es ein Math-Plugin für WordPress, das bei der Eingabe eine simple Frage wie „sum of 9+9“ stellt. Die Jungs von Webmaster-Verzeichnis haben sich dazu ein paar Gedanken gemacht. Hier das Ergebnis, 60% der Blogs lassen sich so überlisten.
Grafischen Captchas geht es übrigens nur selten besser.
Ich bleibe erstmal bei Akismet 🙂
10. Januar 2008
Securityfocus hat eine Artikel von Symantec Research (äh … Symantec und Research ohne Negation in einem Satz?) veröffentlicht, in dem sie beschreiben, dass ein böser Hacker:
- eine böse und eine harmlose Applikation programmiert
- beide Applikationen so verändert, dass sie den gleichen MD5-Hash produzieren
- die harmlose Applikation auf einen Webserver legt
- wartet, bis der Hash dieser Applikation es in die Whitelist-Tabellen der Virenscanner geschafft hat
- die böse Applikation auf den Webserver legt
- den Schadcode ausführen kann, weil er per Whitelist erlaubt wird
Schön, dass Symantec das schon 2008 aufgefallen ist. Nur, das ist ja so etwas von … da muss ich lange nachdenken … 2004! Dan Kaminsky hat ein vergleichbares Problem bereits 2004 auf Doxpara als PDF veröffentlicht und in Folge in seinen BlackOps TCP/IP Präsentationen (PPT) live vorgeführt. Das Tool confoo.pl hat er damals bereits auf seiner Webseite bereitgestellt.
Aber gut, wir wissen ja, dass Symantecs Norton Antivirus manchmal auch nicht gerade der schnellste ist. 🙂
7. Januar 2008
6. Januar 2008
Auf meinem Server hier ist Logging ja weitgehend abgeschaltet (zumindest das Access-Log, nicht jedoch das Error-Log). Das hat den Vorteil, Daten die nicht vorhanden sind, muss (und kann) man im Zweifel nicht rausrücken. Der Apache schreibt die Logfiles standardmäßig sowieso nur in eine Datei und die kann man auch gut auf /dev/null verlinken. Dann ist das Log so zuverlässig weg wie die Daten auf einem Windows Home Server.
Manche machen das ja ein wenig anders. Der TÜV Rheinland zum Beispiel. Für den sind die Logfiles offensichtlich so wichtig, dass er sie direkt in eine SQL-Datenbank schreibt. Nicht ganz sauber programmiert zwar, aber das fällt meistens eh nicht nicht auf. Dieser Link (aus dem 24C3 Hacks-Wiki) zeigt das Problem auf. Als PHPSESSIONID einfach „‚UNION‘„übergeben und schon kackt das Logging ab. Ein wundervolles Beispiel für SQL-Injection. Wenn man sich den Sourcecode der Webseite direkt anschaut sieht man ganz unten das Problem:
„You have an error in your SQL syntax near ‚UNION“)‘ at line 1<br>INSERT INTO accesslog (mandantid, mapid, sprachid, arbeitsbezeichnung, userip, userhost, useragent, referer, zeit, session)VALUES (1, 26, 1, ‚Impressum‘, ‚xx.xx.xx.xx‘, ‚dslb-xxx-xxx-xxx-xxx.pools.arcor-ip.net‘, ‚Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11‘, ‚http://events.ccc.de/congress/2007/Hacks‘, ‚2008-01-06 23:04:33‘, “UNION“)<br>“
Das muss nicht nur die PHPSESSIONID sein, das kann jeder andere Parameter auch sein. SQL-Injection durch einen modifizierten User-Agent beispielsweise 🙂
Der TÜV Rheinland offeriert seinen Kunden übrigens auch Penetrationstests und Software Entwicklung an. Ich würde mich ja schämen, meine eigenen Seiten nicht im Griff zu haben. Und noch peinlicher, das Problem ist mindestens seit einer Woche auf dem Wiki veröffentlicht. Kuckt denn beim TÜV Rheinland niemand in irgendwelche Logfiles?
Aber keine Sorge: wir bieten gerne jedem einen Sonderpreis auf unsere eigenen Penetrationstests an, der vorher den TÜV Rheinland beauftragt hatte und sich nun nicht mehr ganz sicher fühlt. Einfach eine Mail an mich mit dem Hinweis „TÜV Rheinland“ und es gibt 10% auf alle Leistungen 😉
2. Januar 2008
Ein paar Links auf Artikel in diversen Online-Medien …
am umfangreichsten berichtete natürlich Heise:
dann natürlich Golem
Spiegel Online als wichtigstes Nachrichtenportal will da nicht zurückstehen, nur schafft es der Spiegel leider nicht, die Artikel mit 24C3 oder so zu kennzeichnen damit man sie leichter findet. Dabei ist das doch gar nicht so schwer, oder liebe Redaktion?
Für Focus Online sind übrigens so Themen wie Jackass wichtiger als der Chaos Communication Congress … aber Focus Online war noch nie mein bevorzugtes Portal und das Heft hat meiner Meinung nach auch stark nachgelassen.
Dafür hat der britische The Register ein paar Themen aufgegriffen
Indymedia ist auch dabei, hier nur der Link auf den Hauptartikel
und zu guter Letzt darf die TAZ nicht fehlen, in deren Räumen der CCC ja gegründet wurde
Weitere Hinweise und Links nehme ich gerne mit auf.
Nachtrag:
Die Welt (ja genau, die reaktionäre Springer-Presse) hat sich auch zu einem übrigens erstaunlich positiven Artikel durchgerungen:
Ich persönlich finde den Beitrag von Thomas Lindemann jedenfalls recht gelungen.
31. Dezember 2007
Die aufgelegten Folien will ich kommentarlos als Fotobeweis dokumentieren 🙂
Tim Pritlove hat dann zum Ende noch ein paar Statistiken geliefert:
- 4013 – Besucher
- 17 – Alter des jüngsten Referenten
- 16105 – Zurückgelegte Kilometer des entferntesten Sprechers (gleichzeitig der jüngste)
- 25 – Workshops
- 100 – Präsentationen
- 3 – davon die ausgefallen sind
- 580 – MB Sputnik Tracking Data
- 25,2 – Millionen Sputnik-RFID-Tag Sichtungen
- 37 – Sputnik-Leser im Gebäude
- 210 – Sputnik-Träger die getrackt wurden
- 76 – nicht-anonyme Sputnik-Träger
Das war’s, nächstes Jahr, gleiche Zeit, gleicher Ort.
Alexander Kornbrust ist neben David Litchfield vermutlich der wichtigste Oracle Sicherheitsexperte den wir haben. Wenn von ihm ein Vortrag zu Oracle Security kommt, dann kann man eigentlich immer etwas wichtiges erwarten.
Zu Beginn gab es einen kurzen Abriss zu alten Lücken, insbesondere PL/SQL-Injecion-Fehler. Hier hat Oracle in den letzten Jahren über 1000 Fehler behoben und verwendet inzwischen einen Fortify-Sourcecode-Scanner um weitere Lücken zu erkennen. Das Spiel heißt jetzt nicht mehr „Hacker gegen Oracle“ sondern „Hacker gegen Fortify“. Dummerweise ist der PL/SQL-Code der nicht von Oracle ist weiterhin dramatisch schlecht da die Entwickler in den Unternehmen nur auf ihre Business-Logik achten und teilweise noch nie von SQL-Injection gehört haben. Eine einzige Lücke reicht einem Angreifer jedoch aus um die komplette Datenbank zu übernehmen.
Eie weitere Fehlerklasse hat David Litchfield auf der Black Hat DC 2007 vorgestellt, dort nutzte er eine Lücke im Cursor aus die jedoch inzwischen behoben ist. Der Hack zeigt jedoch, dass weiterhin mit Lücken zu rechnen ist und immer mehr Angriffe automatisiert werden.
Ein Thema mit dem sich Alexander als erster intensiv beschäftigt hat sind „Database Rootkits“. Dabei werden einzelne Einträge wie Benutzer und Passwörter oder Jobs in der Datenbank versteckt. Diese Rootkits haben darüber hinaus den Vorteil, plattformunabhängig und nur datenbankspezifisch zu sein. Eine Variante ist die Modifikation der Database-Views. Die meisten Tools verwenden Views um auf die Inhalte von Tabellen zu kucken. Ein Eintrag kann so in einem View verborgen werden während er in der Tabelle selbst weiter enthalten ist. Es gibt inzwischen sogar kommerzielle DB-Rootkits, z.B. von Argeniss, inzwischen von Gleg aufgekauft. Von Paul Wright (PDF) gibt es ebenfalls ein Rootkit-Whitepaper, außerdem eine neue Methode von David Litchfield, der im Memory (PPT) einzelne Funktionen patcht.
Die wichtigsten Probleme aktuell sind:
- Unvollständiges Auditing, z.B. kann die User-Table nicht überwacht werden
- Default Passwörter / Login und Passwort identisch
- Nicht eingespielte Patches
- Ungeschützte Listener
Die Listener sind ab 10g automatisch geschützt, die Hauptprobleme werden weiterhin Patches sein, da viele Anwender nicht kurzfristig oder regelmäßig Patches einspielen können.
Eine weitere neue Funktion mit Missbrauchspotential ist die Transparent Data Encryption (TDE) die auf jeder neuen Oracle-Installation vorhanden ist und nicht deinstalliert werden kann (jedoch zur Nutzung eine eigene 10.000 USD/CPU Lizenz verlangt). Wenn die TDE eingesetzt wird, hilft sie dem Angreifer, relevante Daten zu finden da nur wichtige Sachen verschlüsselt sind (und die Entschlüsselung beim Query ja transparent erfolgt). Wenn sie nicht eingesetzt wird, gibt es ganz neue Erpressungsmethoden. Einfach die TDE aktivieren und kritische Daten verschlüsseln. Das passiert (da transparent) unsichtbar für den Nutzer. Nach einem Reboot bzw. Neustart der Datenbank ist dann der Schlüssel weg und das Unternehmen zahlt sicher gerne für das fehlende Passwort.
Weitere Themen waren Skripten in Clients für SQL*Plus, die z.B. beim Starten des Oracle-Clients automatisch nach der Anmeldung ausgeführt werden (quasi wie ein Trojaner) sowie Shellcode in Tablenamen, z.B. wenn ein Table „!rm -rF /“ heißt 🙂 Cooles Zeug.
30. Dezember 2007
In der Präsentation „Unusual Web Bugs“ von kuza55 ging es Schlag auf Schlag mit den unterschiedlichen Sicherheitslücken in Browsern und Servern, in PHP und anderen Sprachen. Das ging so schnell, viele Punkte konnte ich gar nicht mitschreiben, ich hoffe die FeM-Leute kriegen das Video bald (und brauchbar) kodiert. Die folgenden Stichpunkte sind daher lediglich meine eigene Gedächtnisstütze, schaut Euch das Video selbst an.
- XSS bei angemeldeten Benutzern
- Missbrauch des Passwort-Managers
- Automatisches Einfügen von Passwörtern in Formulare
- Session Fixation
- Abhängig von Cookies und Regeneration der Cookies
- Cache auslesen (nur IE)
- Sonstige Cookie-Spiele
- Logout durch blockieren des Cookie (CSRF/Flash, Firefox-Tool)
- Login als der Angreifer (Cookie via Flash in Header einschleusen)
- Hilfreich ist, dass die Cookie Policy schwächer als die Same Origin Policy ist
- IE FindMimeFromData
- Encoding-Angriffe gegen SQL-Server (Multibyte-Char)
- und vieles mehr
Ferruh Mavituna hat einiges in diesem Bereich gemacht und bietet u.a. ein SQL Injection Sheet auf seiner Homepage an. Eine andere Quelle ist Ha.ckers.org.
Für meinen Geschmack richten sich die meisten Probleme jedoch gegen den Browser und nicht gegen den Server und die Webapplikation. Angriffe gegen Browser sind mehr für Leute, die Schadprogramme auf die Clients bekommen wollen und ich bin sicher, einige der Angriffe sind bereits im berüchtigten MPack implementiert. Für meine Pentest-Arbeit sind jedoch Lücken in Serverapplikationen nützlicher, da lässt sich auch legal (§ 202c StGB) noch der eine oder andere Exploit anwenden.
Post-Exploitation, d.h. die effiziente Datensammlung von gehackten Systemen wird immer wichtiger, da in den nächsten Jahren insbesondere bei Windows weniger Lücken und Exploits zu erwarten sind. Luke Jennings hat sich in seinem Vortrag (bereits auf der Defcon 15 gehalten (PDF)) daher mit Windows Access Token beschäftigt. Diese Token werden von Windows für praktisch alles verwendet, angefangen von Zugriffsrechten auf Dateien bis hin zu den Rechten mit denen Prozesse gestartet werden und ob sich ein Benutzer anmelden darf.
Mit einem fremden Token sind daher interessante Angriffe möglich, vom Datendiebstahl über Impersonation bis zur lokalen und domainweiten Rechteeskalationen. In älteren (nicht gepatchten) Windows Systemen gibt es darüber hinaus einen Fehler, dass solche Token nicht komplett gelöscht werden wenn sich ein Benutzer abmeldet. Dieses Token kann mit speziellen Tools wiedergefunden und genutzt werden.
Die Programme find_user und incognito sind von Luke veröffentlicht worden und kann entweder von der Milwaukee Area Defcon Group oder von SourceForge heruntergeladen werden.
Bei den Vorträgen von Ilja hab ich regelmäßig das Problem, dass ich höchstens die Hälfte davon verstehe. Das geht immer so weit in C- und Kernel-Interna, das brauche ich normalerweise nicht und ich programmiere auch nicht besonders gern. Diesmal habe ich zwar ganz gut verstanden, worum es ging aber die potentiellen Lücken zu einem Exploit zu entwickeln ist nochmal ein eigener Schritt.
Der erste Teil beschäftigte sich mit /dev/kmem und möglichen Race Conditions beim Auslesen des Kernel-Speichers. Die Lücken sind auf NetBSD bezogen, können aber ähnlich in allen anderen Systemen auftreten, die noch /dev/kmem verwenden (neuere Systeme greifen auf sysctl bzw. /proc zu und benötigen /dev/kmem nicht mehr).
Das Auslesen der Prozesstabelle via /dev/kmem funktioniert im Detail wie folgt:
- Finde die Prozesstabelle im Kernel-Speicher
- Finde die passende Prozessstruktur in der Prozesstabelle
- Finde den Zeiger in der Prozessstruktur, der z.B. auf den Prozessnamen zeigt
- Lese die Informationen auf die der Zeiger der Prozessstruktur zeigt
- Gib die Daten aus
Zwischen den Schritten zwei und drei kann eine interessante Race Condition auftreten. Das kommt vor, wenn während dieses Ablaufs der Prozess beendet wird und aus der Prozesstabelle verschwindet. Der Angriff sieht dann wie folgt aus:
- die Prozessstruktur wird wieder freigegeben
- der Speicher kann reallokiert werden
- wenn der Angreifer die Kontrolle über diesen Speicherbereich bekommt, kann er dort beliebigen Inhalt hineinschreiben
- der Inhalt sollte aussehen wie eine Prozessstruktur
- die Stelle an die der Pointer zeigt kann ausgelesen werden
Ein wunderbarer Data Leak direkt aus dem Kernel mit allen damit verbundenen Sicherheitsimplikationen. Noch schöner ist es, dass zwei SGID-kmem NetBSD-Programme (trsp/trpt) ihre Privilegien beim Starten nicht verwerfen und sogar core-Files einlesen (womit sie anfällig für manipulierte core-Files werden). Damit dürfte unter geeigneten Umständen eine Rechteeskalation zur Gruppe kmem und damit der komplett lesende Zugriff auf /dev/kmem möglich sein.
Eine zweite Fehlerklasse verursacht der Systemaufruf snprintf() in C, der zwei Eigenschaften hat. Zum einen ist der Rückgabewert der Funktion beim Schreiben in einen Puffer nicht die Zahl der tatsächlich geschriebenen Zeichen sondern die Zahl der geschriebenen Zeichen wenn alles in den Puffer gepasst hätte. Zum zweiten gibt snprintf() bei einem Fehler -1 als Rückgabewert zurück. Einige Funktionen prüfen jedoch den Rückgabewert nicht sondern verwenden ihn direkt zur Zeigermanipulation. Bei geeigneten mehrfachen Aufrufen mit Fehler (-1) kann dieser Zeiger dann auf eine beliebige Adresse gesetzt werden.
Der letzte Teil des Vortrags beschäftigt sich mit Out of Band Daten bei TCP. Dafür wird das Urgent-Flag und der Urgent-Pointer im TCP-Header genutzt. Allerdings gibt es kaum noch Anwendungen die Out of Band Daten nutzen.
Das Senden von OOB-Daten ist recht einfach: send(fd, data, len, MSG_OOB);
Das Lesen ist etwas kniffliger, da beim Empfänger Out of Band Daten normalerweise einfach ignoriert werden. Mittels der Funktion: fcntl(fd, F_SETOWN, getpid()); kann der Filehandle so gesetzt werden, dass OOB-Daten empfangen werden. Der Aufruf recv(fd, buf, len, MSG_OOB); kann dann zum Lesen genutzt werden. (Alternative Unix-Versionen haben andere Konstantennamen, MSG_OOB ist dann entsprechend anzupassen).
Eine Alternative ist OOB_INLINE, mit der Daten beim Empfänger auch in den normalen Empfangsdatenstrom eingebunden werden können. Und hier bekommen spätestens Intrusion Detection Systeme Probleme denn wie soll das IDS erkennen, dass die Daten zwar OOB gesendet aber Inline empfangen werden. Und pauschal Inline-Empfang anzunehmen ist auch nicht möglich eben weil das Standardverhalten des Empfängers einfach das Ignorieren der Daten ist.
Ich sag ja … ist immer krasses Zeug mit dem sich Ilja da beschäftigt.
