Random notes
Veröffentlicht von onny
Pycrypto 2.3 für Python 3.1
cd ~
wget http://ftp.dlitz.net/pub/dlitz/crypto/pycrypto/pycrypto-2.3.tar.gz
tar xvf pycrypto-2.3.tar.gz
wget http://onny.project-insanity.org/files/pycrypto-2.3-python3-1.patch
patch -p0 < pycrypto-2.3-python3-1.patch
cd pycrypto-2.3
find . -type f -print0 | xargs -0 sed -i 's/PyString_FromStringAndSize/PyBytes_FromStringAndSize/g'
find . -type f -print0 | xargs -0 sed -i 's/PyString_AsString/PyBytes_AsString/g'
find . -type f -print0 | xargs -0 sed -i 's/PyString_Check/PyBytes_Check/g'
find . -type f -print0 | xargs -0 sed -i 's/PyString_Size/PyBytes_Size/g'
find . -type f -print0 | xargs -0 sed -i 's/PyInt_FromLong/PyLong_FromLong/g'
sudo python setup.py install
cd .. && rm -r pycrypto-2.3 pycrypto-2.3-python3-1.patch pycrypto-2.3.tar.gz
leider ist die pycrypto-AES-lib damit noch nicht ganz bugfree:
ldd -r /usr/lib/python3.1/site-packages/Crypto/Cipher/AES.so
linux-gate.so.1 => (0xb775a000)
libpython3.1.so.1.0 => /usr/lib/libpython3.1.so.1.0 (0xb75c2000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb75a8000)
libc.so.6 => /lib/libc.so.6 (0xb745d000)
libdl.so.2 => /lib/libdl.so.2 (0xb7459000)
libutil.so.1 => /lib/libutil.so.1 (0xb7454000)
libm.so.6 => /lib/libm.so.6 (0xb742f000)
/lib/ld-linux.so.2 (0xb775b000)
undefined symbol: Py_FindMethod (/usr/lib/python3.1/site-packages/Crypto/Cipher/AES.so)
undefined symbol: Py_InitModule (/usr/lib/python3.1/site-packages/Crypto/Cipher/AES.so)
Rapidshare-Download mit wget nach RS.COM-relaunch
Folgendes BASH-Script lädt nacheinander Dateien einer Linkliste bei RS.COM runter:
#!/bin/bash
a=0
while read line
do a=$(($a+1));
wget –header ‘Cookie: enc=*******’ $line;
done < "links"
“links” ist die Datei mit den Rapidshare-Links, enc= ist die HTTP-Header Variable für den Rapidshare-Cookie, der für den Premium-Download benötigt wird.
DNS-Cache deaktivieren in Firefox 4
Wenn man viel zwischen VPN- und PPTP-Netzwerken hin und herwechselt, bei denen auch ein neuer DNS-Eintrag gepushed wird, kann es immer eine Ewigkeit dauern, bis Firefox Adressen wieder nach dem aktuellen DNS auflößt. Um diesen Cache zu deaktivieren, legt man auf der Firefox-Konfigurationsseite “about:config” einen neuen Integer-Wert an (Rechtsklick -> New -> Integer); nennt die Regel “network.dnsCacheEntries” und setzt den Wert im darauf folgenden Fenster auf “0″ – fertig!
// dieser post wird, je nach bedarf mit weiteren kleinen notizen erweitert 
WPA2 hacking mit pyrit
Veröffentlicht von Hanny
Neulich hatte ich, dank Robert, mal die Gelegenheit ein relativ Leistungsstarkes System (QuadCore, GeForce 8800GTX) für WPA2-hacking zu missbrauchen. Wir haben das ganze schon einmal mit der guten alten aircrack-ng Suite ausprobiert, sind dort aber trotz der Leistung nur auf 2k Keys/s gekommen.
Für die, denen der Process nicht so geläufig ist: Im Gegensatz zu WEP ist bei WPA/WPA2 keine so grundlegende Implementierungslücke bekannt, was den cracking-Aufwand ungleich größer macht. Mit genügend Packets (IVs) lässt sich ein WEP AccessPoint verdammt einfach “öffnen”, bei WPA2 existiert etwas in der Art aber nicht, deshalb gibt es hier eine andere Vorgehensweise:
Man snifft einen sog. Handshake eines WPA-Clients zum AccessPoint mit, und generiert anschließend Hashes aus Passwort und ESSID. Diese Hashes hängen nur von Passwort und ESSID ab, einmal generierte Hashes können also für alle APs mit gleicher ESSID genutzt werden. Das Generieren der Hashes ist der mit Abstand “teuerste” Teil des Prozesses. Mit den generierten Hashes kann man nun einen Abgleich über einen vorliegenden Handshake laufen lassen.
Die Aircrack-ng Suite vereinfacht diesen Prozess, das Programm generiert und checkt alles automatisch, benötigt wird eine Wordlist und ein cap-File mit Handshake. Leider gibt es im Internet Programme, welche die Hashes wesentlich schneller generieren, als Aircrack: pyrit
Das Programm nutzt die (relativ neue) CUDA(Nvidia)/Stream(ATi)/OpenCL(offener Standard) Technik der neueren Grafikkarten um eine massive Beschleunigung zu erreichen. Auf unserem Testsystem lief die CPU mit rund 4×500 Keys/s, die Grafikkarte aber mit etwa 7k Keys/s! Somit lag unsere Gesamtleistung bei etwa 9k Keys/s, Peaks lagen teilweise bei 9.7.
Durch pyrit wird der Vorgang also stark beschleunigt, da WPA Keys aber mindestens 8-stellig sein müssen ist hier an Bruteforcing noch nicht zu denken, somit bleibt einem nur eine Dictionary/Wordlist-attack. Hiermit sind wir auch schon an der Schwachstelle des Systems angelangt: ohne gute Wordlist sind die Chancen tatsächlich einen Hit zu bekommen gleich Null. Nachdem unser erster Test vollkommen ins Wasser ging (englische Wordlist, etwa 1.5GB), hab ich mich mal nach sinnvollen Wordlists umgeschaut und kaum was gutes gefunden. Also sind wir zu dem Schluss gelangt, dass man sich selbst eine zusammenstellen sollte, hier gibt es ganz gute Anfänge. Mit Hilfe von “sort” und “uniq” kann man damit ganz gute Listen erstellen. Die Schwachstelle einer solchen Liste ist allerdings, dass fast niemand ein Wort wie “Baggerfahrer” als Key benutzt ( ich bin mir nicht sicher warum, aber selbst WEP Netzwerke haben dann meistens eine Mutation des Wortes als Passwort, wie zB “Baggerfahrer123″), also sollte die so generierte Wordlist noch mutiert werden. (Lässt sich mithilfe einfachster Python-scripte sehr leicht machen, da pyrit auch stdin als Eingabe akzeptiert)
Um hier nochmal ein etwas “handfesteres” Tutorial abzuliefern, schildere ich mal die grundsätzliche Vorgehensweise (hier am Beispiel von CUDA):
Hier genutzt: pyrit SVN rev 199
Man braucht:
- einen WPA-Handshake im cap-Format (sehr einfach zu erstellen mit Aircrack-ng, Tutorials gibts bei der Suchmaschine deiner Wahl)
- pyrit, am besten die neuste dev-Version
- cowpatty
- eine GPU mit CUDA/Stream/OpenCL-Support (nicht zwingend, aber strengstens empfohlen)
- Im Falle von CUDA am besten die 3.0 Beta verwenden, war bei uns kompatibler und ebenso stabil (dürfte mittlerweile neuere Versionen geben, einfach bisschen rumprobieren )
Nachdem der CUDA-Driver und das Toolkit richtig installiert sind, baut man pyrit nach den Instructions, bei cowpatty genügt ein make.
Falls man keine MySQL oder sonstige Datenbank als Backend nutzen möchte, braucht pyrit keine weitere Konfiguration.
Mit “pyrit -i wordlist.txt import_passwords” lässt sich die Wordlist einlesen, wer die Wordlist gerne durch einen Manipulator jagen will, kann das in etwa so machen “./mymanipulator.py wordlist.txt | pyrit -i – import_passwords”.
Anschließend erstellt man eine ESSID mit “pyrit -e MyESSID create_essid”, welche man dann mit “pyrit -e MyESSID batch” angreifen kann. Nach dem generieren der Hashes checkt man diese mit Cowpatty “pyrit -e MyESSID -o – export_cowpatty | /path/to/cowpatty -d – -s MyESSID -r mycap.cap”.
Das ganze lässt sich auch perfekt mit einem Rutsch erledigen, dazu bedienen wir uns mal wieder einer einfachen Pipe:
“pyrit -e MyESSID -o – batch | /path/to/cowpatty -d – -s MyESSID -r mycap.cap”
Am besten man hofft nun auf einen Treffer, genügend Zeit hat man ja
Disclaimer:
Dieser Artikel dient zur reinen Information und Fortbildung. Das Umgehen von Sicherheitsbeschränkungen Dritter ist nicht vorgesehen.
feedcher
Veröffentlicht von Hanny
Nachdem ich mich bisher eher im Hintergrund betätigt hab’, meld’ ich mich nun auch mal zu Wort.
Ich versuche mal das Programm vorzustellen an dem ich momentan am ehesten arbeite : den feedcher.
Der Post hier wird vermutlich ab und an mal editiert werden, der jetzige Status ist mehr ‘ne Preview.
Warum der Name?
feedcher ist eine Zusammensetzung von “feed” im Sinne von RSS Feed und dem englischen Wort “fetch” was im Grunde schon den kompletten Sinn des Programms erklärt.
Sinn des Programms
Das Programm soll, bzw. ist schon auf eingeschränkte Art und Weise, fähig sein, RSS Feeds von externen Seiten zu fetchen. Mit fetchen meine ich hier aber nicht einfach die XML-ähnliche Datei des RSS Feeds auszulesen und zu speichern, sondern den kompletten Content der verlinkten Seiten zu analysieren und die wichtigen Sachen zu speichern.
Der Hintergrund hierfür ist, dass viele (auch sehr große Seiten) die ursprüngliche Idee des RSS-Feeds (zumindest meiner Interpretation nach) etwas vernachlässigen, denn der <item> Block einer RSS-XML sollte meiner Meinung nach den kompletten Text des Artikels beinhalten, dies tut er aber in den seltensten Fällen. Wäre der <item>-Block korrekt, wäre es möglich den Feed zu laden und anschließend, unabhängig vom Zugang zum Internet, zu lesen.
Der feecher soll diese Lücke stopfen und den tatsächlichen Inhalt des <item> in einer MySQL Datenbank ablegen, diese stellt die ideale Möglichkeit dar, den Inhalt danach weiter zu verarbeiten (php, download als tgz, Erstellung eines neuen, vollständigen RSS etc)
Implementierung
Das Programm soll nach einer bereits bekannten Methode funktionieren (siehe munin oder logwatch):
Ein sogenannter Node lädt, verwaltet und ruft Plugins für jeden einzelnen RSS Feed auf, die dem Node dann die Daten zuführen und anschließend in die Datenbank geschoben werden. Der Node ist in dem Fall in C++ geschrieben, verwendete Libraries sind bis jetzt openssl (md5), curl (http) und mysqlpp (MySQL, obviously).
Die Plugins können in jeder beliebigen Sprache geschrieben sein, sie müssen nur auf stdout ihre Config und später in Dateien ihre Results ausgeben können (Ruby, Perl, Python…).
Bearbeitung eines Beispielfeeds
Der Node erkennt ein Plugin, holt sich dessen Config (Argument ist hier “autoconfig”) über den stdout (nach dem Schema “feedUrl=www.foobar.foo”) und holt sich den Feed. Nun wird jeder <item>-Block md5-gehashed und überprüft ob dieser Hash schon in der Datenbank existiert, wenn nicht wird der <item>-Block in eine Datei geschrieben und das Plugin mit dem Filename als Parameter aufgerufen. Das Plugin verarbeitet nur den <item>-Block und schreibt die Ergebnisse in seine neue Datei, welche der Node anschließend einliest und die ermittelten Daten in die Datenbank schreibt.
Status
Die Grundzüge des feechers funktionieren schon, eine bestimmte, hier nicht genauer genannte, Seite wird bereits korrekt eingelesen und verarbeitet. Im Moment hängt es noch an dem Vorhandensein eines korrekten Plugins, das von mir (in Python) geschriebene Plugin schafft es bisher nicht, die HTML-Tags korrekt zu entfernen, das sollte aber das kleinste Problem werden.
Die Entwicklung liegt zwar momentan auf einer kurzen Eisstrecke, wird aber bestimmt wieder anlaufen, auf Anfrage kann man die Quellen aber jetzt schon erhalten
mfg Hanny
PS: Feedback & comments are highly appreciated