Network

Introduction In my last blog post (Scanning for IP-Forwarding Systems / Routers), I explained why it can be useful during pentests to identify IP-forwarding systems (also known as routers or gateways) and showcased a script that can be used to identify such systems. In this post, I’ll show how this can be done in IPv6 networks when your host has a routable IPv6 address configured. Script The script can be found on GitHub: ip6-forwarding-scanner. The usage is quite simple: ...

Introduction Systems which have IP forwarding or routing enabled (so called routers or gateways) will forward IP packets to other networks where the system is connected to. In pentests, it can be useful to search for such systems, because these systems could be used to access otherwise inaccessible networks and systems. I wrote a small script that automates this task. Script The script can be found on GitHub: ip-forwarding-scanner. The usage is quite simple: ...

Introduction Wireshark 4.2.0 added a new functionality [1] that can be used to directly launch a web browser with the SSLKEYLOGFILE environment variable set, in order to easily sniff and decrypt TLS traffic from a started application. Howto This new feature can be found in the Tools menu and then under TLS Keylog Launcher (1). You can specify to which file where the SSLKEYLOGFILE variable should point to (2) in order to save the key material. Then, a command can be provided in the command line input field (3), which is then started with the SSLKEYLOGFILE variable set. If an application supports the SSLKEYLOGFILE mechanism [3], the TLS keys are the automatically stored in the configured file and Wireshark is able to decrypt the content (4) and show it in cleartext (5). ...

Introduction In pentests, connecting devices to your own network can be very useful. This enables you to analyze the network traffic and use a transparent proxy to intercept and inspect data transmitted between the devices and servers. This approach helps finding potential security weaknesses in applications and network communications. In order to make this process easier, I created a script that starts a new WiFi that can be used to analyze the network traffic of the connected clients. ...

Introduction Recently, I read on Twitter that SNI spoofing can be used to bypass deep packet inspection. This is the Tweet: Ok, so SNI spoofing is cooler than I thought. It’s easy to bypass these deep packet inspection devices and Next Gen firewall filters. Want to visit a “malicious” website? Getting blocked? Just change the SNI value to a windows update address. - @nullenc0de on Twitter (https://twitter.com/nullenc0de/status/1159805999332638720) I wanted to understand how this works and how it can be done, so started playing around with curl. ...

Introduction I was recently playing around with DNSSEC and figured out that the root DNS zone . uses NSEC and not NSEC3 to prove the absence of a resource record. This looked interesting to me and triggered some ideas. So I did some experiments and here are the results. TL;Dr: The most interesting facts: The root DNS zone uses NSEC can be therefore be DNSSEC zone walked There are more than 1500 TLDs More than 90% of all TLDs haven DNSSEC configured The most used algorithm for signing DNS zones is RSA/SHA-256 53 TLDs also use NSEC and can therefore also be DNSSEC zone walked Note: The results may not be exactly accurate because it was not always verified if every query was always successful. ...

Introduction In pentests, you often need to create X.509 certificates (e.g. for TLS) or Certificate Authorities (CAs) to mimic secure environments during your tests. Manually generating these certificates with tools like openssl can be time-consuming and error-prone, especially when you’re in a hurry. Who remembers all these commands? Whether you’re setting up a fake webserver for data exchange, a proxy setup, a machine-in-the-middle (MITM) attack, testing secure connections, or creating your own CA chain, manually generate these certificates should not take much time. ...

Introduction WireGuard is a relatively new open-source software for creating VPN tunnels on the IP layer using state of the art cryptography. I attended a self-organized session by the creator and developer Jason Donenfeld at the 34c3 who explained how WireGuard works and how it can be used. I was quite impressed by it’s simplicity and gave it a try. It worked more or less out of the box. Now I created a more advanced setup for accessing my home network. ...

Einführung Jedes mal, wenn ich meine IP Adresse wissen will, gebe ich bei einer Suchmaschine “my ip address” ein und klicke auf eines der Ergebnisse. Dies ist nicht sehr elegant. Auf einem Server ohne Browser ist dies gar nicht möglich. Deshalb habe ich ein Script geschrieben, welches mir meine IP Adressen (IPv4 und IPv6) anzeigt. Script Das Script sieht folgenermassen aus: #!/usr/bin/env bash #IPURL="https://icanhazip.com/ip" IPURL="https://motd.ch/ip.php" print_usage(){ cat << EOI Displays IP addresses of the current host used for internet connections. Usage: myip [options] Options: -6 Show only IPv6 addresses (public ip address by default). -4 Show only IPv4 addresses (public ip address by default). -h Show usage help. -l Show local insted of public addresses. -g Show geolocation (using geoiplookup). No options produces a more verbose output. EOI } check_dependencies(){ local FAIL=0 for tool in "$@" do if ! hash "$tool" &> /dev/null then echo "The tool $tool does not exist." FAIL=1 fi done if [[ "$FAIL" == 1 ]] then exit 1 fi } print_public_ipv4_address(){ echo "$(curl -s -4 -L $IPURL || echo "")" } print_public_ipv6_address(){ echo "$(curl -s -6 -L $IPURL || echo "")" } print_public_ipv4_geolocation(){ geoiplookup "$PUBLIC_IPV4_ADDRESS" | awk -F": " '{printf($2)}' } print_public_ipv6_geolocation(){ geoiplookup6 "$PUBLIC_IPV6_ADDRESS" | awk -F": " '{printf($2)}' } print_local_ipv4_address(){ echo "$(curl -s -4 -L --write-out %{local_ip} $IPURL -o /dev/null || echo "")" } print_local_ipv6_address(){ echo "$(curl -s -6 -L --write-out %{local_ip} $IPURL -o /dev/null || echo "")" } main(){ while getopts 46ghlv name do case "$name" in 4) flag_4=1 ;; 6) flag_6=1 ;; g) flag_g=1 ;; h) print_usage exit ;; l) flag_l=1 ;; ?) print_usage >&2 exit 2 ;; esac done if [[ -n $flag_l && -n $flag_4 ]] then print_local_ipv4_address fi if [[ -n $flag_l && -n $flag_6 ]] then print_local_ipv6_address fi if [[ -z $flag_l && -n $flag_4 ]] then print_public_ipv4_address fi if [[ -z $flag_l && -n $flag_6 ]] then print_public_ipv6_address fi if [[ -z $flag_l && -z $flag_4 && -z $flag_6 ]] then PUBLIC_IPV4_ADDRESS=$(print_public_ipv4_address) PUBLIC_IPV6_ADDRESS=$(print_public_ipv6_address) echo -e "Public IPv4 address: ${PUBLIC_IPV4_ADDRESS:--}" echo -e "Public IPv6 address: ${PUBLIC_IPV6_ADDRESS:--}" LOCAL_IPV4_ADDRESS=$(print_local_ipv4_address) LOCAL_IPV6_ADDRESS=$(print_local_ipv6_address) echo -e "Local IPv4 address: ${LOCAL_IPV4_ADDRESS:--}" echo -e "Local IPv6 address: ${LOCAL_IPV6_ADDRESS:--}" echo "" if [[ -n "$PUBLIC_IPV4_ADDRESS" && -n "$LOCAL_IPV4_ADDRESS" ]] then if [[ "$PUBLIC_IPV4_ADDRESS" != "$LOCAL_IPV4_ADDRESS" ]] then echo "IPv4: NAT" else echo "IPv4: No NAT" fi fi if [[ -n "$PUBLIC_IPV6_ADDRESS" && -n "$LOCAL_IPV6_ADDRESS" ]] then if [[ "$PUBLIC_IPV6_ADDRESS" != "$LOCAL_IPV6_ADDRESS" ]] then echo "IPv6: NAT" else echo "IPv6: No NAT" fi fi if [[ -n "$flag_g" ]] then check_dependencies geoiplookup geoiplookup6 if [[ -n "$PUBLIC_IPV4_ADDRESS" ]] then PUBLIC_IPV4_GEOLOCATION="$(print_public_ipv4_geolocation)" echo "Geolocation IPv4: $PUBLIC_IPV4_GEOLOCATION" fi if [[ -n "$PUBLIC_IPV6_ADDRESS" ]] then PUBLIC_IPV6_GEOLOCATION="$(print_public_ipv6_geolocation)" echo "Geolocation IPv6: $PUBLIC_IPV4_GEOLOCATION" fi fi fi } main "$@" Die aktuellste Version davon gibt es auf GitHub in meinem Scripts Repository: myip. ...

Einführung Verbindet man sich zum ersten Mal per SSH mit einem Server, sieht man den Fingerabdruck des Servers. Diesen sollte man im Idealfall vergleichen und erst mit yes bestätigen, wenn man sich sicher ist, dass es sich um den richtigen Fingerprint handelt. Stimmt der Fingerabdruck nicht, könnte man Opfer einer Man in the Middle Attacke sein. Das Vergleichen der Fingerprints ist etwas mühsam und mittels fuzzying (beispielsweise mit dem Tool ffp) können sehr ähnliche Fingerprints erstellt werden, welche dem Menschen auf den ersten Blick gleich erscheinen. Man kann sich einfach vor gefälschten SSH Fingerprints schützen, indem man diese in einem DNSSEC signierten speziellen DNS Record hinterlegt. Hierfür gibt es den speziellen SSHFP Record. ...

Einführung Setzt man DNSSEC ein, muss man bei jeder Änderung der Zone oder wenn die Signatur abgelaufen ist die Zone neu signieren. Setzt man dynamisches DNS ein (wie in diesem Blogpost beschrieben: Eigener Dynamischen DNS (DDNS) Service betreiben (Eigenes DynDNS), ist es am einfachsten wenn der Nameserver die Zone nach einem Update selber neu signiert. Das Problem Es gibt den Host monpi.example.org, welcher seinen DNS-Eintrag regelmässig anpasst. Bei dieser Zone wurde neu DNSSEC aktiviert: ...

Einführung DNS Antworten können signiert werden, damit man überprüfen kann, ob es sich um eine richtige und vertrauenswürdige Antwort handelt. Die DNS Antworten werden vom authoritativen DNS Server signiert. Die Schlüssel, welche die Antworten signieren, werden von dem DNS Server eine Zone höher signiert. Über diese Chain-of-Trust können Anwendungssoftware und DNS Resolver prüfen, ob eine Antwort vertrauenswürdig ist oder nicht. Mit dem DNS Server bind kann man seine Zonen selber signiert anbieten. Ich zeige das am Beispiel der Domain example.org. ...

Einführung SSH kann dazu verwendet werden, Ports von und zu anderen Geräten weiterzuleiten. So kann zum Beispiel via SSH auf eine Datenbank auf einem Server zugegriffen werden, welche sonst nur Verbindungen von sich selber akzeptiert. Ein anderer Anwendungsfall wäre die Bereitstellung eines Dienstes in einem Netzwerk, welches die Clients im Netz wo der Server steht sonst keinen Zugriff hätte. Dies geht über ein (längeren) SSH-Befehl. Braucht man das öfters, lohnt sich die Konfiguration in der Datei ssh_config. ...

Einführung Manche Dienste will man nur für bestimmte Geräte zugänglich machen. Befindet sich der Server und der Client im selben Layer 2 Netz, ist es einfach die Verbindungen nur für bestimmte MAC-Adressen zuzulassen. Kommt die Verbindung nicht von der konfigurierten MAC-Adresse, wird der Verbindungsaufbau nicht zugelassen und der Dienst ist für dieses Gerät somit nicht verfügbar. Mein Anwendungsfall: Music Player Daemon (MPD) Um Musik zu hören verwende ich den Music Player Daemon (MPD). Dieser kann man über eine einfache TCP Verbindung steuern (im Notfall auch mit telnet :)). Ich mag es auch die Musik von meinem Telefon aus mit einem speziellen Client zu steuern. Jedoch möchte ich nicht allen im Netzwerk Zugriff auf den MPD geben (Port 6600). Deshalb lasse ich nur Verbindungen von meinem Mobiltelefon zu, was ich über die MAC-Adresse des Telefons steuere. ...

Einführung Mit iptables kann man unter Linux eine Firewall konfigurieren. In diesem Artikel zeige ich die wichtigsten Befehle und Arbeitsschritte um eine Firewall für IPv4 und IPv6 einzurichten. Hilfsvariabeln und Hilfsfunktionen Folgende Hilfsvariabeln vereinfachen einem die Kontrolle über de einzelnen Befehle und Konfigurationsdateien: IPTABLES="/sbin/iptables" IPTABLES_SAVE="/sbin/iptables-save" IPTABLESCONFIG="/etc/iptables/iptables.rules" IP6TABLES="/sbin/ip6tables" IP6TABLES_SAVE="/sbin/ip6tables-save" IP6TABLESCONFIG="/etc/iptables/ip6tables.rules" IP46TABLES="ip46tables" Die Hilfsfunktion ip64tables verwende ich, um Befehle gleichzeitig mit iptables und ip6tables auszuführen. Somit verhindert man den Fehler, dass man Regeln nur für IPv4 und nicht für IPv6 erstellt: ...