Sqall Blog

Ich hatte vor einiger Zeit versucht, Snort auf den aktuellsten Stand zu bringen. Damit bin ich damals aber gescheitert, weil noch gar keine Regeln fuer die aktuellste Version verfuegbar waren (zumindest nicht, wenn man kein Geld bezahlt).

Nun habe ich heute geschaut und Regeln fuer die Version 2.8.6 waren vorhanden. Nachdem ich nun 2.8.6 neu kompiliert hatte, habe ich mir die neuen Regeln herunterladen. Und ich muss sagen, es hat sich einiges geaendert. Erstens muesst ihr komplett alle Regeln ersetzen. Ich habe meine Regeln unter dem Ordner /etc/snort/rules. Dort habe ich alle Regeln ersetzt und gesehen, dass zwei neue Verzeichnisse unter /etc/snort hinzukommen. Das Verzeichnis so_rules und preproc_rules. Diese sind bei den Regeln von snort mit dabei. Als naechstes musste ich in /etc/snort alle Konfigurationsdateien ersetzen. Nun nachdem ich dies gemacht hatte, habe ich mir die snort.conf angeschaut. Hier hat sich auch einiges geaendert. Sie kam mir vor allem kuerzer vor.

Hier musste ich meine Ordner fuer die Regeln anpassen, so dass diese auf die richtigen Verzeichnisse zeigen:

var RULE_PATH rules
var SO_RULE_PATH so_rules
var PREPROC_RULE_PATH preproc_rules

Als ich alle Port Einstellungen vorgenommen hatte, konnte Snort allerdings immernoch nicht starten. Es endete immer wieder mit einem Segmentation Fault. Ich habe mir dann die dynamic preprocessors angeschaut, die im Ordner /usr/local/lib/snort_dynamicpreprocessor/ liegen. Dort habe ich einen alten von der vorherigen Version gefunden und geloescht. Das waren die Dateien:

lib_sfdynamic_preprocessor_example.a
lib_sfdynamic_preprocessor_example.la
lib_sfdynamic_preprocessor_example.so
lib_sfdynamic_preprocessor_example.so.0
lib_sfdynamic_preprocessor_example.so.0.0.0

Nun endete aber ein Snort start immernoch mit einem Segmentation Fault. Dies lag an den dynamic rules in dem Ordner /usr/local/lib/snort_dynamicrules. Nachdem ich diese geloescht hatte, hab ich Snort noch einmal gestartet und siehe da, es startet.

Nun habe ich aber festgestellt, dass die Regeln noch sehr stark von mir angepasst werden muessen. Ich hatte Ossec so konfiguriert, dass es aufkommende Snort Alarme sofort in einem Bann umsetzt und was passiert natuerlich direkt? Meine SSH Verbindung hat einen Alarm ausgeloest und ich wurde gebannt. Und jetzt klingelt gerade mein Handy und mir wird mitgeteilt, dass das Internet zu Hause nicht mehr funktioniert (anscheinend wurden alle Benutzer direkt gebannt^^). Da muss ich wohl noch einiges anpassen

Mich erreichten heute diese eMails, die ich ohne viele Worte weitergeben moechte (Links zum unterstuetzen oben, Infos unten):

Hallo,

falls der Link https://zensus11.foebud.org nicht funktioniert, bitte
diesen Link nutzen: https://petition.foebud.org/zensus11

Freundliche Grüße
FoeBuD e.V.
//padeluun

--

Wir klagen gegen die Volkszählung 2011

Unterstützen Sie unsere Verfassungsbeschwerde gegen die Vollerfassung!

Mit der Volkszählung (Zensus) 2011 sollen Daten aller in Deutschland
lebenden Menschen in einer gewaltigen Datenbank zusammengeführt und
ausgewertet werden. Dagegen werden die Bürgerrechtler vom Arbeitskreis
Vorratsdatenspeicherung mit dem FoeBuD e.V. Verfassungsbeschwerde
einreichen und haben damit die Rechtsanwältin Eva Dworschak
beauftragt.

Sie können mitmachen: Unterstützen Sie unsere Verfassungsbeschwerde unter
https://zensus11.foebud.org

Achtung - eilt:
Die Sammlung von Online-Unterschriften läuft bis 12. Juli 2010


Hintergrund:

Mit der Volkszählung 2011 sollen Informationen aus zahlreichen Quellen
zusammengeführt werden. Unter anderem werden bei den Meldebehörden,
den Liegenschaftskatastern, der Bundesagentur für Arbeit sowie aus
"allgemein zugänglichen Quellen" Daten abgefragt. Außerdem soll bis zu
einem Drittel der deutschen Bevölkerung zur Beantwortung zahlreicher
Fragen aus dem persönlichen Lebensbereich verpflichtet werden.

Aus verschiedenen Datenbanken, angereichert mit den Informationen
einer Zwangsbefragung, entsteht so über jeden von uns ein
Persönlichkeitsprofil an zentraler Stelle. Besonders heikel: Über eine
eindeutige Personenkennziffer ist die Zuordnung der unterschiedlichen
Daten aus der Volkszählung möglich.


Fünf Gründe gegen die Volkszählung 2011

(1) Die Erhebung ist nicht anonym, Name und Anschrift werden genau wie
die gesammelten Daten vier Jahre gespeichert. Es entstünde ein zentral
verfügbares Personenprofil aller in Deutschland ansässigen Personen.

(2) Die Zuordnung der Daten aus der Volkszählung ist über eine
eindeutige Personenkennziffer möglich. Eine solche eindeutige
gemeinsame Ordnungsnummer hatte das Bundesverfassungsgericht in seinem
Volkszählungsurteil 1983 ausdrücklich verboten.

(3) Sensible persönliche Daten werden aus zahlreichen Quellen ohne
Einwilligung der Betroffenen zusammengeführt. Die Daten von
Meldeämtern und Behörden werden zweckentfremdet; das Grundrecht auf
informationelle Selbstbestimmung wird verletzt.

(4) Die zentrale Verfügbarkeit der Personenprofile fordert Mißbrauch
geradezu heraus. Die Datenschutz-Skandale der vergangenen Jahre haben
dies gezeigt.

(5) Die Abfrage der Daten laut deutschem Volkszählungsgesetz geht
über den von der EU geforderten Umfang hinaus. So wird nach der
Religionszugehörigkeit gefragt, obwohl die EU-Vorlage dies nicht
vorschreibt. Die bei der Volkszählung entstehende Sammlung sensibler
Informationen, etwa Migrationshintergrund und Religionszugehörigkeit
ohne eine echte Anonymisierung, ist höchst bedenklich. Damit ließe
sich zum Beispiel eine Liste aller bekennenden Muslime in Deutschland
erstellen.

Fazit: Das Volkszählungsgesetz bewerten wir in seiner jetzigen Form als
klaren Verstoß gegen das Grundrecht auf informationelle
Selbstbestimmung.

Schon 1969 hat das BVerfG in seiner Mikrozensusentscheidung eine
Personenkennzahl für unzulässig erklärt, denn „es widerspricht der
menschlichen Würde, den Menschen zum bloßen Objekt im Staat zu machen
[...]. Mit der Menschenwürde wäre es nicht zu vereinbaren, wenn der
Staat das Recht für sich in Anspruch nehmen könnte, den Menschen
zwangsweise in seiner ganzen Persönlichkeit zu registrieren und zu
katalogisieren, sei es auch in der Anonymität einer statistischen
Erhebung, und ihn damit wie eine Sache zu behandeln, die einer
Bestandsaufnahme in jeder Beziehung zugänglich ist.“ [BVerfGE 1969]

Ich musste gerade etwas lachen. Ich hatte mich vor kurzem darueber aufgeregt, dass PowerShell Version 2 ein v1.0 im Pfad hat. Nun konnte ich heute mein Exchange 2010 System testen, da ich Outlook 2010 zur Verfügung habe. Damit ich auch sehe, in welchem Format die Termine verschickt werden, habe ich die Datei an eine eMail-Adresse ausserhalb des Systems geschickt und mir die eMail mal etwas genauer angeschaut.

Der Termin wird im standardisierten ics-Format abgeschickt nach RFC2445 (zumindest geht dies aus der Benennung des Termines hervor). Schonmal sehr gut, haette ich um ehrlich zu sein nicht erwartet. Zwar ist dies der alte RFC, aber immerhin sollte dies jede Kalendersoftware unterstuetzen. Nun schaute ich in die ics Datei hinein und was sehe ich?

"PRODID: Microsoft Exchange Server 2007"

Bitte was? Die Product ID ist Exchange 2007? Hab ich mich beim Installationsmedium vergriffen und Exchange 2007 installiert? Wohl kaum Ach ist das herrlich. Als ich es lachend meinem Arbeitskollegen mitteilte, sagte er mir auch "Ja ist normal, in SCCM-2007 stehen bei total vielen Objekten noch SMS als Produkt eingetragen." Ich frage mich immernoch, warum dieses bei M$ so ist? Haben die keine Lust ihre Produkte, bevor sie sie veroeffentlichen, noch einmal zu checken ob diese auch die richtige Versionsnummer ausgeben?

Wie ich schon oefter geschrieben habe, administriere ich im Moment ein M$ Netzwerk. Ich musste gestern Probleme auf der PowerShell beheben und benoetigte die Version. Ich hatte einen Windows XP Rechner der die PowerShell Version 2.0 hatte (das wusste ich, da ich diese selber installiert hatte) und einige Windows 2008 R2 Server. Mir wurde im Buero zwar die ganze Zeit gesagt, dass Windows 2008 R2 mit der PowerShell 2.0 ausgeliefert wird, doch wollte ich es ueberpruefen, da die Fehler nach Versionskonflikt aussahen. Leider wusste ich den Befehl nicht, wie ich die Version von PowerShell herausbekomme (als Info: mit get-host kriegt man die PowerShell Version angezeigt). Ich hatte aber in Erinnerung, dass PowerShell die Versionsnummer im Pfad hat. Also habe ich mir den Pfad angeschaut:

%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe

Mein erster Gedanke war "Von wegen Windows 2008 R2 wird mit Version 2.0 ausgeliefert.". Nachdem ich aber durch diese Annahme erst recht auf Versionsprobleme gestossen bin, hab ich den Befehl zum Version anzeigen herausgesucht. Ein Blick auf die Version des Windows 2008 R2 zeigte mir 2.0 an. Ein kurzes ueberpruefen des Pfades auf dem Windows XP Rechners zeigte mir den selben Pfad.

Jetzt stellt sich fuer mich nur eine einzige Frage: Warum? Was muessen sich die Entwickler von Microsoft sich dabei gedacht haben, eine falsche Versionsnummer in den Pfad zu schreiben. Noch mehr Verwirrung kann man dadurch wohl kaum stiften...

Nachdem ich nun die ersten Grundlagen Tests durch hatte [1] [2], habe ich nun ein paar Vorbereitungen fuer Praxistests getroffen.

Als erstes habe ich eine extra Wordlist erstellt, die fuer WPA-Angriffe geeignet ist. Dazu habe ich ein paar deutsche Wordlists genommen, ein paar mit gebraeuchlichen Namen und Kombinationen und diese zusammengefuegt. Hierbei habe ich dann ein Skript durchlaufen lassen, welches nur Woerter in diese Wordlist schreibt die laenger oder gleich 8 Zeichen sind, denn die mindestlaenge fuer WPA-Kennwoerter ist 8 Zeichen.

Nachdem ich nun so eine Wordlist mit einer groesse von 16MB zusammen hatte, habe ich Freunde und Bekannte um Erlaubnis gebeten, ihren WPA-Handshake zu sniffen. Nachdem ich diese bekommen habe, habe ich deren WPA-Handshake mit airodump mitgesnifft. Ich habe nun mit der Kombination aus John The Ripper, Pyrit und Cowpatty meine Wordlists durchlaufen lassen. Einmal die von mir selbst erstellte 16MB Wordlist und einmal die im Backtrack4 Repository enthaltene 400MB WPA Wordlist.

Meine selbsterstellte Wordlist hatte folgende Werte nach einem erfolglosen Durchlauf:
33418223 passphrases tested in 9157.03 seconds: 3649.46 passphrases/second

Die Backtrack4 WPA Wordlist hatte folgende Werte nach einem erfolglosen Durchlauf:
477291275 passphrases tested in 130801.63 seconds: 3648.97 passphrases/second

Die Tests laufen zwar noch, aber bisher hab ich noch keinen Erfolg gesehen. Kein Angriffsversuch ist bisher fruchtbar verlaufen und bei diesen WPA-Passwoertern handelt es sich wirklich um Passwoerter, die normale nicht technisch versierte Menschen eingegeben haben. Ein Bruteforce-Angriff scheidet bei der Fuelle an Passwortmoeglichkeiten und der laenge der Passwoerter aus (John The Ripper hat z.B. eine kompilierte maximal laenge von 8 Zeichen bei einem incremental Angriff).

Bisher kann ich also als Fazit sagen, dass ich WLAN auch via WPA-PSK nicht als unsicher ansehe, sollte das Passwort vernuenftig gewaehlt worden sein. Ich werde aber noch weiter fleissig ausprobieren und darueber berichten. Die Berechnungen dauern ja gluecklicherweise etwas laenger, so das ich auch noch Zeit habe, mich um andere Projekte zu kuemmern