Captain's blog

Nachdem Peter Gutmann und ich vor einiger Zeit TrueCrypt und Co. auf Nutzbarkeit und Sicherheit der Verschlüsselung getestet haben, haben sich mittlerweile ein paar Dinge an dieser Front getan:
Die Entwickler haben in Zwischenzeit eine neue Version (4.3) herausgegeben, die ein paar Verbesserungen (leider fast ausschließlich für Windows-User) mit sich bringt. Daraufhin haben sich findige Leute einmal auf andere Angriffsvektoren auf die Software konzentriert, und sind prompt (bei der Linux-Version) fündig geworden...

Wer ein öffentlich erreichbares (Unix-) System betreibt, kennt die Problematik der diversen gescheiterten Anmeldeversuche per SSH. Hervorgerufen durch Bots, die triviale Kombinationen und Passworten durchprobieren, müllen sie Logfiles zu, und finden schlimmstenfalls sogar wirklich einen Luser, der ein leicht zu erratendes Passwort nutzt.
Lösungen für dieses Problem sind (nicht nur hier) bereits mehrfach angesprochen worden; angefangen bei einfachen Maßnahmen wie der Verlegung des Port von 22 auf einen anderen, nicht standardgemäßen. Nutzung von SSH-Public Keys. Weiter über Paketfilter und eigens hierfür entwickelte Tools wie z.B. denyhosts oder fail2ban.

Eine gänzlich andere Möglichkeit, die darüber hinaus noch weitere Vorteile bietet ist die Authentisierung über Einmalpassworte. In Verbindung mit einer Zwei-Faktorauthentisierung (wie sie z.B. RSA mit den SecureID-Tokens) vormacht kommt zusätzlich zum Passwort noch eine Besitzkomponente hinzu. Ohne Token, das das OTP anzeigt, ist kein Zugang möglich.

Leider lohnen sich der Kauf dieser Token für den "Privatgebrauch" nicht wirklich, immerhin existieren mittlerweile (freie) Projekte, die diese Technik sehr kostengünstig ermöglicht. Das wohl vielversprechendste ist hier wohl FreeAuth.
Statt eines Hardwaretokens kommt hier das (in den allermeisten Fällen eh vorhandene) Handy zum Einsatz, das mit Hilfe eines kleinen Stückchen Java-Software die Funktion schnell und einfach nachbildet.

Nachdem es so gut zum letzten Posting hier passt, geht es heute wieder um eine "Security-Linux Live-CD": nach einigen Monaten Wartezeit wurde gestern die stabile Version der "Pentesting-Distribution" BackTrack in Version 2 freigegeben.

Wer sich einmal eingehender mit Penetration Testing befasst hat, wird um den Download bisher wohl kaum herumgekommen sein. Natürlich gibt es auch andere Projekte, die sich die Ansammlung möglichst vieler sinniger Tools auf die Fahnen geschrieben haben, das Team um Max Moser hingegen begnügt sich nicht nur mit aktuellen Sicherheitswerkzeugen (von denen trotzdem über 300 mitgeliefert werden).
Viel mehr wird dem Tester alleine durch die Vorbereitung der Wireless-Module für Packet Injections, als auch besonders im Bereich der (oft so ungeliebten) Methologie und "Nacharbeit" (Dokumentation etc.)) unter die Arme gegriffen. Nicht umsonst orientiert sich die Distribution mehr und mehr an "Standards" wie ISSAF und OSSTMM. Die Ausformulierung von Vorgehensweise, Erkenntnissen und potentiellen Lösungen bleibt dem Pentester jedoch trotz allem selbst überlassen.

Den weiteren Abend werde ich jedenfalls damit verbringen, mir die neue Version einmal ganz genau anzusehen. Jedem, der sich für Security interesissert kann selbiges definitiv auch ans Herz gelegt werden. In diesem Sinne: Slainte Mhath!

Dass Linux nicht nur Spaß machen,sondern auch mal (bewusst) unsicher sein kann, zeigt das Damn Vulnerable Linux-Projekt (kurz DVL). Es besteht aus einem Damn Small Linux, das aber eigens zu "Trainingszwecken" für Einsteiger und Fortgeschrittene der IT-Security modifiziert wurde.

Am besten jedoch beschreibt es ein Zitat der Macher selbst:

Actually, it is a perverted Linux distribution made to be as insecure as possible. It is collection of IT-Security and IT-Anti-Security tools. Additional it includes a fullscaled lesson based environment for Attack & Defense on/for IT systems for self-study or teaching activities during university lectures. It's a Live Linux Distro, which means it runs from a bootable CD in memory without changing the native operating system of the host computer. As well it can be run within virtual machine environments, such as qemu or vmware. [...] Its sole purpose in life is to put as many security tools at your disposal with as much training options as it can. It contains a huge ammount of lessons including lesson description - and solutions if the level has been solved by a community member at crackmes.de.

Ich hab's ja schon länger gesagt, und langsam aber sicher dringt es immer lauter an die Öffentlichkeit: PHP stinkt!

Nachdem ich bereits eine ganze Zeit lang Tor nutze, um nicht unbedingt jedem meine Daten etc. mitzuteilen, interessiert mich die Untersuchung über potentielle Schwachstellen der Anonymisierung natürlich ganz besonders.
Dass die Betreiber von Exit-Nodes (den Hosts, die den endgültigen Connect zum Zielhost herstellen) im Zweifelsfall sämtlichen Traffic mitlesen können ist ja nichts wirklich Neues. Da die Anfragen aber durch die unterschiedlichsten Tor-Nodes geleitet werden, ist aber wenigstens der Ursprung der Anfragen unbekannt (FAQ).

Nachdem Mattias Schlenker im Rootforum alleine durch die Umschreibung der Vorteile von Jails einen kleinen FreeBSD-Hype ausgelöst hat, interessierte mich eine solche (im "Standardumfang" nicht enthaltene) Lösung natürlich auch gerade unter OpenBSD. Immerhin bedeutet eine "virtuelle" OS-Instanz vor allem eine weitere erhöhte Sicherheit.

Fündig in diesem Fall wurde ich bei sysjail, das Jail-Konstrukte mit Hilfe des systrace-Frameorks umsetzt, das seinerseits eine sehr mächtige (aber dennoch einfache) RBAC-Imlementierung für System Calls darstellt. Somit lässt sich der "Komfort" eines Jails noch durch zusätzliche Sicherheit kombinieren, da sich so sehr feingranular einschränken lässt, was in der VM erklaubt ist.

Ich weiß, das Thema ist steinalt und ausgenudelt wie sonst nur was. Da ich aber irgendwann garantiert wieder danach suchen werde, poste ich die Sachen jetzt einfach mal hier rein. Daher gibt's anbei noch mal zwei verschiedene Möglichkeiten, SSH-Bruteforcing mit Hilfe von Paketfiltern (in diesem Fall IPTables und OpenBSDs PF) in die Schranken zu weisen:

Die Jungs und Mädels bei FON scheinen es mit ihrer Absicht, die weltweit größte WiFi-Community aufbauen zu wollen echt Ernst zu meinen. Seitdem vor ein paar Wochen die Meldung durch die Presse ging, dass kostenlose, auf OpenWRT aufbauende Access Points an neu hinzukommende "Foneros" verschickt werden, verfolge ich die Sache mit recht großem Interesse.

Das Konzept hierbei besteht darin, dass derjenige, der einen solchen Access Point betreibt den anderen Teilnehmern seinen breitbandigen Internetanschluss zur Verfügung stellt.
Im Gegensatz zu OpenWRT ist das FON-Gerät allerdings eine Blackbox, die keinerlei wirklichen Zugang (z.B. per SSH) erlaubt. Die Software ist dabei allerdings so raffiniert, dass sie ein vollständig privates WLAN ermöglicht, das unabhängig vom öffentlich erreichbaren arbeitet, so dass die meisten eh kein großes Bedürfnis nach vollständiger Konfigurierbarkeit verspüren werden.

Heute morgen habe ich das Update auf die gestern frisch herausgekommene Zimbra-Version 3.1.2 auch auf meiner produktiven Umgebung durchgeführt.

An sich nichts großartiges, immerhin lief das Update (wie erwartet) problemlos durch), bei der Durchsicht einiger Dinge stieß ich dann allerdings auf eine potentielle Sicherheitslücke der Kategorie "information leakage". Nichts, was sich remote ausnutzen ließe, trotz allem bin ich froh, keine anderen User mit Shellzugriff auf der Maschine zu haben.

Als Hostingpartner habe ich glücklicherweise einen relativ kurzen Draht zum Hersteller, den ich direkt informiert habe. Der Fairness halber warte ich mit genaueren Angaben daher auch, bis man sich dieses Problems annimmt. Ein Fix ist immerhin sehr simpel, und wurde bei der Gelegenheit mitgeliefert. Ich bin gespannt, wie die Jungs und Mädels reagieren werden.

Im Zuge des (hoffentlich) bald fertigen Artikels über Crypto-Filesysteme unter Linux habe ich kürzlich endlich einmal ein Projekt in Angriff genommen, das ich schon längst einmal angegangen sein wollte: die Verschlüsselung des gesamten Systems auf der Festplatte.
Im Gegensatz zu einem meiner älteren Artikel, der die Verschlüsselung von /home und Swap mit Hilfe des (mittlerweile obsoleten) Cryptoloop-Systems beschreibt, kommt in diesem Fall DM-Crypt inklusive der LUKS-Erweiterung(en) zum Einsatz. Glücklicherweise sind die meisten Werkzeuge für das Vorhaben bereits unter Dapper bereit, ein paar Hürden galt es jedoch zu überwinden.

Inspiriert ist dieses kurze Howto durch einen Blogeintrag von Sternensucher, sowie einem (eigentlich veralteten) Thread im Ubuntu-Forum.
Obwohl das Vorhaben sicherlich auch aus einem laufenden System heraus machbar wäre, wird das System im folgenden komplett neu installiert.

Bevor es losgeht, noch der obligatorische Disclaimer:
1. Dieses Howto richtet sich an Personen, die (wenigstens ungefähr) wissen, was sie damit anstellen. Die hier vorgestellte Vorgehensweise hat sich für mich als stabil und gangbar erwiesen. Sollte das bei dir nicht der Fall sein, kann ich dich (zur Zeit) nur schlecht bis gar nicht supporten.
2. Eine Datensicherung bereits im Vorfeld ist unabdingbar.
3. Solltest du deine Daten (durch dieses Howto, eine vergessene Passphrase, whatever) verlieren, übernehme ich keine Verantwortung dafür.

Da auch das geklärt ist, kann's ja nun losgehen:

Amir Alsbih did it again: der Autor des Override-Rootkits, das den "Schutz" des 2.6er Kernels durch nicht bekannte Systemcall-Tabellen umgeht, hat sich diesmal anscheinend mit Honeypots auseinandergesetzt. In diesem speziellen Fall hat er dabei wohl eine Methode gefunden, wie ein solches System bereits im Vorfeld als solches erkannt werden kann.

Seit dem gestrigen Update meiner Dapper-Installation auf dem T30 war es mir nicht mehr möglich, eine automatisierte WPA-Verbindung zum Access-Point aufzubauen.

Bei der Analyse des Problems fiel mir dann auch sehr schnell ins Auge, dass drei wichtige, zum Paket gehörende Dateien (/etc/default/wpasupplicant, /etc/init.d/wpasupplicant und /etc/wpa_supplicant.conf) umbenannt waren, und nunmehr die Endung ".dpkg-bak" trugen.
Da ich es zu dem Zeitpunkt gestern relativ eilig hatte, brachte ein beherzter manueller Aufruf (wpa_supplicant -B -D wext -c /etc/wpa_supplicant) erst einmal das gewünschte Ergebnis: die Verbindung war wiederhergestellt.

Passend zur Cebit werden gerade auf Messen zum Schutz des IT-Inventars gern "Schutzmaßnahmen" in Form von Ketten und passenden Schlössern getroffen. Wer nach "How to pick a Kensington lock in 60 seconds" immer noch daran glaubt, dass sein Notebook in Sicherheit ist, dem ist wohl einfach nicht mehr zu helfen.
Somit hat es übrigens nun mittlerweile auch den Marktführer in dem Bereich (Kensington halt) getroffen.

...die Pix zuhause als DSL-Router fungieren würde...

In diesem Fall würde ich wohl endlich mal Nägel mit Köpfen machen, und mir eine kleine Soekris-Box dort hin stellen. Erst recht, wo das Flashboot-Projekt es ermöglicht, die aktuelle OpenBSD-beta vom Flash aus zu starten. Alternativ würde sich natürlich auch noch ein zweiter WRT54G mit OpenWRT anbieten, dann wäre wohl auch noch die letzte Ecke des Hauses (und vermutlich noch das der Nachbarn) komplett "ausgeleuchtet".