Kurs2: Projekt IT-Security TopPage
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)
3.2
  • Analysiere die beim Verbindungsaufbau ausgehandelte Chiffrensammlung mit wireshark.
    - http://de.wikipedia.org/wiki/Cipher_Suite (Cipher Suite bei Wikipedia)
    - https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslciphersuite (Cipher Suite apache-doc)
    - openssl ciphers [-V] [-v]     #zeigt [more] [verbose] Infos zu den Cipher-Suiten

    Eine Chiffrensammlung besteht aus den folgenden 4 Algorithmen:
    - Schlüsselaustausch (RSA, DHr, DHd, EDH, ECDH[E], PSK, SRP)
    - Authentifizierung (keine, DH, RSA, DSS, ECDSA)
    - Hashfunktion (MD5, SHA[1], SHA2 mit 256 384 o. 512Bit, SHA3)
    - sym. Verschlüsselung (keine, RC2, RC4, DES, 3DES, IDEA, Camellia, AES)
      jeweils mit einem Betriebsmodi (ECB, CBC, GCM, CFB, OFB, CTR, XTS)

    Der SSL3-Verbindungsaufbau vom [B]rowser zum [S]erver
    [B] -> [S] Client Hello
    [B] <- [S] Server Hello, Certificate, Server Hello Done                          
    [B] -> [S] Client Key Exchange, Change Cipher Spec, Finished
    [B] <- [S] [NewSessionTicket], Change Cipher Spec, Finished
    [B] <=> [S] Encrypted Application Data
    Der Verbindungsaufbau mit Diffie-Hellman Schlüsselaustausch
    [B] -> [S] Client Hello
    [B] <- [S] Server Hello, Certificate, Server Key Exchange, Server Hello Done
    [B] -> [S] Client Key Exchange, Change Cipher Spec, Hello Request, Hello Request 
    [B] <- [S] New Session Ticket, Change Cipher Spec, Encrypted Handshake Message
    [B] <=> [S] Encrypted Application Data
    Könnte die https-Kommunikation mit bekanntem private-Key sichtbar werden?
    - http://en.wikipedia.org/wiki/SSL/TLS#Applications_and_adoption
    - http://de.wikipedia.org/wiki/Diffie-Hellman_key_exchange

  • 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.
       Client-FQDN=PDB[Client].spe4.de; Client-IP=172.20.x.x; Client-Mac=01:02:03:04:05:06
       MitM-FQDN  =PDB[MitM].spe4.de;   MitM-IP  =172.20.x.x; MitM-Mac  =01:02:03:04:05:06
       Server-FQDN=PDB[Server].spe4.de; Server-IP=172.20.x.x; Server-Mac=01:02:03:04:05:06
    - 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 ;-)
  • Installiere (wenn nicht vorhanden) auf dem MitM-Host das Paket dsniff.
    - http://www.monkey.org/~dugsong/dsniff/, http://software.opensuse.org/package/dsniff
    Bewerte ob hier Dual-Use-Software nach §202c StGB (Hackerparagraf) verwendet werden darf.
    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
    Am MitM-Hosthttp
    sub2 Digest-Login sichtbar?
    sub1 Basic-Login sichtbar?
    - Übersende (auf dem gleichen Weg) Formulardaten per GET/POST vom Client zum Server
    Am MitM-Hosthttp
    GET Daten sichtbar?
    POST Daten sichtbar?
    - 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?
    Am MitM-Hosthttps
    sub2 Digest-Login sichtbar?
    sub1 Basic-Login sichtbar?
    GET Daten sichtbar?
    POST Daten sichtbar?

Die Sicherheit in einer "geswitchten" Umgebung
3.4 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
    ettercap -T -P dns_spoof [-M arp[:remote] //Client-IP/ //DNS-IP/]
    # optional noch mit -> -P dns_spoof -L ECP-Datei -m INFO-Datei
    # Alternativ: DnsSpoof nachträglich starten: p, dns_spoof
    

Inhaltskontrolle auf Firmenproxies
3.6
  • 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.
    ssl_crtd -s /var/lib/ssl_db [-M 4MB]
    ODER:
    security_file_certgen -c -s /var/lib/ssl_db -M 4MB
    chown -R squid:squid /var/lib/ssl_db/
    
  • 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)
    

Meinlf Mühlenjost 2022