Kurs2: Projekt IT-Security
3.x Sicherheit verschlüsselter Kommunikation
Browserseitige Schutzfunktionen für https Verbindungen
3.1
Trustcenterlisten
SSL/TLS-fähigen Clientprogrammen steht ein Satz vertrauenswürdiger Trustcenter zur Verfügung.
Diese Liste kann Bestandtteil des Betriebssystems oder der Clientapplikation selber sein. Diese Liste befindet sich beim Firefox in folgenden Dateien:
- Firefox < Vers. 57 (im alten Dateiformat) in den Dateien cert8.db, key3.db und secmod.db
- Ab Firefox-57.0 in SQLite Dateien cert9.db, key4.db und der pkcs11.txt
Der Befehl: "certutil -L -d ." (im Paket mozilla-nss-tools) listet/verwaltet die (im Profilordner) vorhandenen Trustcenter.
CRLs - Certificate Revocation Lists
Eine Zertifikatsperrliste enthält Informationen welche Zertifikate (Seriennummer), wann (Datum) gesperrt oder widerrufen wurden und warum (optional).
Z.B. wenn private Schlüssel entwendet oder öffentlicht werden, sollte das Zertifikat beim signierenden Herausgeber (Certification Authority), gesperrt werden.
Beim einem https-Verbindungsaufbau, kann der Browser über die Certificate Revocation Lists (CRLs) der Herausgeber, prüfen, ob ein Zertifikat gesperrt ist.
Die Nachteile von Sperrlisten:
- Diese trustcenterbezoge Listen sind lokal (wenn überhaupt vorhanden) niemals aktuell.
- Sie sind teilweise mehrere MByte groß und werden schnell größer.
- Für eine aktuelle Prüfung sind diese Listen nicht geeignet, weil sie regelmäßig vom Client
heruntergeladen werden müßten.
OCSP - Online Certificate Status Protocol
Aufgrund der Nachteile von Sperrlisten, können Browser mit dem Online Certificate Status Protocol (OCSP), den Status eines bestimmten Zertifikates in Echtzeit erfragen. Damit das gelingt, müssen die Zertifikate einen OCSP-Eintrag aufweisen und der Browser muß eine erfolgreiche OCSP-Anfrage durchführen können.
Standardmäßig ist in dem Mozilla-Firefox und dem Internet-Explorer OCSP aktiviert, aber im Google-Chrome deaktiviert.
Die Nachteile von OCSP
- Ein OCSP-Request verlangsamt den https-Verbindungsaufbau.
- Ein unbeantworteter OCSP-Request (oder nach Timeout) wird als "OK" akzeptiert.
- Die Privatsphäre wird durch Übermittlung von Daten an dritte eingeschränkt.
Diese Probleme sind aber durch die Verwendung von "OCSP Stapling" (serverseitig) lösbar.
HSTS - HTTP Strict Transport Security
Mit HSTS teilt ein Webserver dem Browser mit, dass HTTP-Requests auch zukünftig über eine verschlüsselte Verbindung erfolgen sollen. Browser wandeln dann alle http-Links automatisch in https um (optional auch für SubDomains). Zerfifikatsfehler können dann nicht mehr manuell akzeptiert werden. Der Firefox-Browser speichert die Einträge in einer „SiteSecurityServiceState.txt“ Datei.
Der Apache Webserver schaltet (mit geladenem headers Modul) im Header die "Strict-Transport-Security" Unterstützung mit folgender Direktive, für einen in Sekunden angegebenen Zeitraum ein.
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Test über:
curl –I https://mein.server.de/
Die Nachteile von HSTS
- HSTS setzt eine Unterstützung sowohl beim Webserver als auch beim Browser voraus.
- Ein Man-in-the-Middle Angreifer kann die Umleitung verhindern, indem er alle https-URLs durch
normale http-URLs austauscht (ssl-strip).
- Werden selbst signierte Zertifikate erneuert, ist ein maneller Browsereingriff erforderlich.
Im Firefox in der Datei SiteSecurityServiceState.txt oder über Strg+H und „Gesamte Website vergessen“.
Im Chrome über das Feld „Delete domain security policies“ in der URL chrome://net-internals/#hsts
- Es werden damit weitere personenbezogene Daten auf der Festplatte verwaltet.
Die Sicherheit von SSL/TLS (bei bekanntem private-key)
Teste mit einem älteren (virtuelles) System oder einen kompatibel eingestellten Browser.
- Rüste wireshark für das SSL-Protokoll mit dem private-Key deines Servers aus
- Unter Edit, Preferences, Protocols, SSL/TLS sollte dazu der Eintrag "RSA Keys List" verfügbar sein
Zeichne erneut Login-Vorgänge mit IExplorer, Firefox (security.ssl3. ohne DHE) oder ...
# openssl als Client-Ersatz mit einer CipherSuite ohne DHE-Schlüsselaustausch openssl s_client -cipher kRSA -connect localhost:443 -ign_eof -crlf
auf und analysiere die Sicherheit der Kommunikation (siehe: http://wiki.wireshark.org/SSL)
Eine autom. Aufzeichnung (scriptgesteuerter wireshark) ist mit tshark möglich.
tshark -o "ssl.desegment_ssl_records: TRUE" \
-o "ssl.desegment_ssl_application_data: TRUE" \
-o "ssl.keys_list: 127.0.0.1,443,http,/etc/apache2/ssl.key/server.key" \
-o "ssl.debug_file: /tmp/wireshark.log" -i any -Y "tcp.port == 443"
#----- optionale Ablage in einer Datei -w /tmp/wireshark.pcap -F pcapng#----- Nachträgliche Auswertung der Datei mit Wireshark (und Server-Private-Key)
wireshark /tmp/wireshark.pcap \
-o "ssl.keys_list: 127.0.0.1,443,http,/etc/apache2/ssl.key/server.key"
Unter welchen Bedingungen wurde die http-Kommunikation sichtbar?
Ein Lösungsansatz ist eine perfekte fortgesetzte Geheimhaltung (Perfect_Forward_Secrecy) mit Diffie-Hellman Schlüsselaustausch.
Teste mit sslscan, testssl oder https://www.ssllabs.com/
auf SSLCipherSuiten mit DH bzw.
erzwinge client/server-seitig eine Ciphersuite mit DH.
# openssl als Client-Ersatz (erzwingt ECHD oder DH)
openssl s_client -cipher 'ECDH:DH' -connect localhost:443 -ign_eof -crlf
Die Sicherheit von SSL/TLS (gegen Man in the Middle Angriffe)
3.3
Ordne den 3-Rechnern deiner Gruppe die Rollen Server, Client und MitM (siehe Muster) zu.
- Der Server besitzt einen Webauftritt, mit Loginmöglichkeiten und passwortgeschützte Ordner
- Der Webauftritt des MitM-Host wird nicht benötigt (siehe: durchgestrichene Variante) ,
sollte aber im Zweifelsfall vom Server unterscheidbar sein ;-)
Die Funktionen der dsniff-Programme
Passive Netzwerkspionage
-dsniff Mitschnitt von Authentifizierungsdaten über unsichere Protokolle
-filesnarf Mitschnitt von Dateiübertragungen über das NFS-Protokoll[19]
-mailsnarf Mitschnitt von Email-Verkehr über SMTP [23] und POP [25]
-msgsnarf Mitschnitt von Chat-Verbindungen über AIM, IRC und ICQ
-urlsnarf Mitschnitt von HTTP-Anfragen[80]
-webspy Mitschnitt und Darstellung in einem Browser
Aktive Netzwerkspionage durch Man in the Middle Attacken
-webmitm Web Monkey in the Middle
-sshmitm SSH Monkey in the Middle
Netzwerksabotage
-tcpkill verhindern/unterbrechen von TCP-Verbindungen (neu Anmeldung)
-tcpnice Verringerung der Geschwindigkeit von TCP-Verbindungen
-dnsspoof Erzeugt zusätzliche DNS-Antworten (zum vorh. DNS-Server)
Abhörangriffe auf ISO OSI Schicht 2
-arpspoof leitet den Netzwerkverkehr gezielt zum Angreifer
-macof flutet lokales Netz mit zufällig erzeugten Ethernetadressen
- Leite die http-Zugriffe (auf den MitM-Host) mittels webmitm/stunnel zum Server weiter
webmitm [-d...] SERVERIP
- Hinweis: webmitm erzeugt beim 1. Aufruf ein Server-Zertifikat in ./webmitm.crt
- Der MitM-Host sollte nun über die Portadressen 80 den Server-Webauftritt liefern
Greife vom Client über den MitM-Host auf (Basic/Digest) geschützte Ordner des Servers zu
- Beurteile die Risiken im Intranet/Internet (wie kann man sie verhindern)
Sicherheit bei Man-In-The-Middle-Angriffen auf https-Verbindungen
- Teste nun https-Zugriffe vom Client (über den MitM) zum Server
- Überwache den Zugriff vom Client mit webmitm, dsniff und urlsnarf
- Welche Daten werden angezeigt und welche Gefahren gehen "in der Praxis" davon aus?
PS: Starte keine Programme die im Schulungsraum zu generellen Netzwerkproblemen führen
und störe NIEMALS den Zugriffe auf unbeteiligten (GW, DNS) Systeme!
Leite zunächst (durch ARP-Spoofing) alle direkten http://SERVER-IP-V4/-Zugriffe vom Client-Browser über den MitM-Host
arpspoof -t Client-IP Server-IP
ODER siehe folgende ettercap Beipiele:
ettercap -TM arp[:oneway] //IPv4-Client/ //IPv4-Server/ #Server im MitM Netz
ettercap -TM arp:remote //IPv4-Client/ //IPv4-GW/ #Server nicht im MitM Netz
ettercap -TM ndp[:oneway] //IPv6-Client/ //IPv6-Server/
ettercap -TM ndp:remote //IPv6-Client/ //IPv6-GW/
- Welche Daten werden auf dem MitM-Host sichtbar (welche nicht)?
- Welche Programme werden nun parallel benötigt?
- Welche Programme stellen dabei "lediglich" in lokalen Netzwerken eine Gefahr dar?
- Welche Programme stellen auch im öffentliche Internet eine Gefahr dar?
Demonstriere MITM-Angriffe auf https mit ettercap
Soll ettercap (on the fly) Zertifikate generieren, so muss die Konfiguration angepasst werden.
In der /etc/ettercap/etter.conf dazu 2 IDs ändern und "if you use iptables"-folgend 2 Zeilen aktivieren
ec_uid = 0 # nobody is the default
ec_gid = 0 # nobody is the default
# if you use iptables:
redir_command_....
redir_command_....
Ettercap mit grafischem Interface verwenden
ettercap -G # ettercap mit grafischem Interface starten
Sniff, unified sniffing, eth0=ok # Netzwerkschnittstelle für’s Sniffing wählen
Hosts, Hosts List # Tab mit erkannten Hosts öffnen
[Host, Enable IPv6 scan] # IPv6-Unterstützung muss eincompiliert sein
Hosts, Scan for Hosts # aktive Hosts (im lokalem Netz) finden
View, Resolve IP addresses # FQDNs der Hosts anzeigen
CLIENT-IP-V4 selektieren und Add to Target1
Kommunikationspartner IPv4 selektieren z.B. GW/Server und Add to Target2
[CLIENT-IP-V6 selektieren und Add to Target1]
Kommunikationspartner IPv6 selektieren z.B. GW/Server und Add to Target2
Mitm, ARP poinoning, sniff (remote=GW) # für IP-V4 Mitschnitte
Mitm, NDP poinoning, sniff (remote=GW) # (UND/ODER) für IP-V6 Mitschnitte
View, Connections, UDP-Protocol-filter abwählen # ist ohne UDP übersichtlicher
Werden die Zugriffe vom Client-Browser über den MitM-Host geleitet,
so werden Loginvorgänge im unteren Ettercap-Fenster autom. angezeigt
und können mit Doppelklick/Rechtsklick eingesehen werden.
Die Funktion sollte bei IPv4, IPv6, http und https gegeben sein.
Optional können die Daten über: „Logging, Logging all packets and infos“ in einer ECP
und ECI-Datei abgelegt und mit etterlog ausgewertet werden
(ECP -> EtterCap Packet Log; ECI -> EtterCap Packet Info)
Für IPV6-Umgebungen stehen weitere Hilfs- und Testprogramme aus dem Paket thc-ipv6 zur Verfügung.
Eine Übersicht der Tools befindet sich in der /usr/share/doc/packages/thc-ipv6/README
und online unter: http://tools.kali.org/information-gathering/thc-ipv6
Angriffe auf das Domain-Name-System demonstrieren/erkennen
3.5
Aktiviere auf dem MitM-Host ein DNS-Spoofing
- Ändere beim Einsatz von dnsspoof dazu die /etc/dnsspoof.hosts ...
dnsspoof -f /etc/dnsspoof.hosts
oder für ettercap die /etc/ettercap/etter.dns um Anfragen mit der MitM-IP-Adr. zu beantworten
ettercap -T -P dns_spoof
- Berücksichtige Groß/Kleinschreibung in der DNS-Konfiguration
- Teste Anfragen mit nslookup, host oder dig (die ohne Arpspoofing noch direkt an den MitM-Host gerichtet werden)
nslookup Server-Name [MitM-IP]
- Beurteile erneut die Risiken im Intranet/Internet
Teste nun, ob im Browser http://Server-FQDN/-Anfragen über den MitM-Host laufen
Inhaltskontrolle mit dem Proxyserver SQUID
Für eine Kontrolle der https-Kommunikation benötigt der Squid folgende Compile-Options.
- ./configure --with-openssl --enable-ssl-crtd
- squid -v | grep ssl # Zeigt die Compile-Settings '--enable-ssl-crtd' und '--with-openssl'
HINWEIS: Der Proxy muss die https-Server direkt (ohne eine Weiterleitung an Parent) kontaktieren können.
In der squid.conf wird (zur Kontrolle von https) die Angabe "http_port ..." erweitert.
sslcrtd_program security_file_certgen -s /var/lib/ssl_db -M 4MB
acl step1 at_step SslBump1
ssl_bump peek step1
#----beginn der ssl_bump Konfiguration
always_direct allow all
ssl_bump bump all
sslproxy_cert_error allow all
http_port 3128 ssl-bump cert=/etc/squid/squid.pem
key=/etc/squid/squid.pem generate-host-certificates=on
In der Datei /etc/squid/squid.pem werden die Dateien einer vertrauenswürdigen CA benötigt (ca-NoPassphrase.key + ca.crt).
Im Ordner "/var/lib/ssl_db/" werden dann die von ssl_crtd autom. generierten Zertifikate abgelegt.
Diese Ordner-Struktur wird mit ssl_crtd bzw. security_file_certgen erzeugt.
Netzwerkanalyse mit "Burp Suite"
Die BurpSuite ist ein Netzwerkanalysetool der Firma PortSwigger zum Testen von Web-Anwendungen.
Sie enthält den Burp Proxy, der HTTP/HTTPS-Verkehr abfängt und Header modifiziert.
Wie sslstrip kann die BurpSuite HTTPS-Zugriffe in HTTP umzuwandeln (aber auch umgekehrt).
Die offizielle Website ist: http://portswigger.net/.
Enthaltene Tools sind: HTTP-Proxy, Scanner, Intruder, Spider, Repeater, Decoder, Comparer, Extender und Sequencer.
Der Start ist nach der (betriebssystemabhängigen) Installation über BurpSuiteCommunity oder als Java Applikation (java -jar burpsuite*.jar) möglich.
Im Menü kann der Proxydienst folgend konfiguriert werden:
- Temporary project, next, use Burp defaults, Start Burp #entfällt eventuell
- Proxy, Options, Proxy Listener, Edit Bind to adress=All interfaces
- Intercept, Intercept is off
Vertrauenswürdiges Zertifikate importieren
- CA Certificate, Import PKCS12 ... (auch Export erzeugter möglich)
cat ca.key ca.crt | openssl pkcs12 -export -out ca.p12
BrowserProxy auf localhost:8080 einstellen. Anzeige im "HTTP history" Tab (Request|Response)