Saturday, March 26, 2022

Two Modest Writeups from Insomni'Hack 2022 CTF

This year the Insomni'Hack security conference took place again after the last two editions were cancelled due to Covid-19. It was great to see everyone IRL again, and indeed the place was crowded. After two days of conferences the legendary capture the flag (CTF) hacking competition took place on Friday night. A couple of colleagues from Compass Security and Swisscom teamed up to solve the challenges. My personal CTF experience is very limited, for that reason I was very happy to be able to solve two beginners' challenges on my own. Let's dig in.

Wordle

This challenge is themed on the web-based word game which gained enormous popularity in 2022. In order to solve the challenge, you need to analyze a Linux binary to which you must provide a specific input – a typical crackme. Here's what happens when executed several times:


As in the original game, one needs to guess a five letter word. Interestingly, one of the solutions is /bin/sh. I used the Ghidra open source reverse engineering tool to understand what's going on behind the scenes. Let's first have a look at strings in the binary. The .rodata memory segment contains the string constants that we can recognize from the program output:

Using Ghidra's decompiler view, we can identify the logic when processing user input:

On line 15, a string provided by the user is read from standard input (stdio) using the insecure gets() function. It will get stored in the .bss memory segment at address 0x003020c0. Next on line 16, memory contents located 32 byte further in memory at address 0x003020e0 are compared with the specific dword value 0xdeadbeef. Using a five character string as input, program execution will take the else-branch at line 21 which results in the output seen above: "Nice try but the word was XXXXX". There we see the use of an array PTR_s_PWNED_00302020 which is used to refer to the list of wordle strings. The value of index iVar2 originates from FUN_00100bad() in line 10, which is most probably a random number generator.

We need to provide a longer input in order to take the if-branch in line 17. Specifically, 32 arbitrary bytes (padding) and then the magic 0xdeadbeef value. We see the same array access providing a random wordle string, which is used as argument to system(). This means, we need to execute the program repeatedly, until the "/bin/sh" string is returned, effectively providing a shell on the target system. Here's my python solution using pwntools:



Gothard

The next challenge is a network forensic challenge. A pcap file is provided containing the captured network traffic from a compromised system. Not sure if the typo was intended, but if referring to the Swiss mountain an association to the tunnel & network tunneling can be made.

When opening the file with Wireshark, we see traffic between two hosts. All packets are of type ICMP type 8 & 0 – echo (ping) request & reply respectively. The outbound ping packets are unusually big. We also see embedded HTTP traffic in the hexdump. Obviously data is being exfiltrated using the arbitrary ping payload bytes. As a guess, I thought this could relate to ping tunneling. A Google search returns the ptunnel utility as a first result. ptunnel uses a simple protocol to encapsulate network traffic, as can be seen on their website:

So obviously we need to parse the header, ignore the retransmitted packets and concatenate the payloads of the remaining packets to reassemble the exfiltrated data. I used python and the pyshark wrapper for tshark:

This resulted in a tar.gz archive and the flag was stored inside of file home/inso/Documents/Audit/Client_Y/0.null/Conf_SCRT_findings.jpg:





Sunday, February 6, 2022

Kleine (aber wichtige) Unschönheit bei den Netzsperren gegen Online-Geldspiele

Staatlich angeordnete Netzsperren

Am 10. Juni 2018 haben die Schweizer Stimmberechtigten das Bundesgesetz über Geldspiele (BGS) mit einer Zustimmung von 72,9% und einer Stimmbeteiligung von 34,52% angenommen. Damit wurden erstmals Netzsperren in der Schweiz eingeführt, dies mit der Absicht Online-Casinos in der Schweiz im Sinn von Heimatschutz und Protektionismus vor ausländischer Konkurrenz zu schützen. Art. 86 BGS verpflichtet demnach Fernmeldedienstanbieterinnen zur «Sperrung des Zugangs zu nicht bewilligten Spielangeboten»:

Art. 86 Bundesgesetz über Geldspiele


Die Verordnung über Geldspiele (VGS) legt in Art. 93 nur unspezifisch fest, wie diese Netzsperren zu erfolgen haben:

Gemäss Gutachten des Rechtswissenschaftliches Instituts der Universität Zürich (F. Thouvenin / B. Stiller) vom 16. September 2016 wurden drei Arten von Netzsperren berücksichtigt:

  1. IP-Adresssperren beim ISP
  2. DNS-Sperren beim ISP
  3. Applikationsfilter oder Proxy-Server beim ISP

Das Gutachten kommt übrigens zum Schluss: «Aus rechtlicher Sicht ist die Eignung von Netzsperren zur Erreichung der vom Gesetzgeber verfolgten Ziele [...] äusserst fraglich.»

Gutachten: Netzsperren (Thouvenin/Stiller)

 

Die Notiz zum Geldspielgesetz "Internetsperre" und ihre Alternativen vom 4. Juli 2017 hält schliesslich fest, dass DNS-Sperren aus heutiger Sicht die favorisierte Lösung ist:

Notiz zum Geldspielgesetz

Sperrlisten

Die Eidgenössische Spielbankenkommission (ESBK) und die interkantonale Geldspielaufsicht gespa (ehemals Comlot) erstellen je eine «schwarze Liste» der in der Schweiz nicht bewilligten Spiel-Internetseiten, die auf der Website der beiden Behörden und im Bundesblatt veröffentlicht wird. Die schwarzen Listen und ihre Aktualisierungen werden den Internetzugangsprovidern so elektronisch zur Verfügung gestellt, dass diese den Zugang zu den aufgeführten Internetseiten automatisiert sperren können.

Beide Behörden stellen die Listen in unterschiedlichen Formaten zur Verfügung:

  1. Die ESBK stellt ein (unsigniertes) PDF Dokument auf ihrer Webseite zum Download bereit. Nicht das beste Format für die maschinelle Verarbeitung, aber immerhin ist die URL statisch.
  2. Die gespa hingegen stellt die Liste als Textdatei zur Verfügung, mitsamt Signatur und Zertifikat um die Authentifizität und Integrität der Einträge zu validieren.

ESBK Sperrliste

 

Wurde eine Internetseite gesperrt, so werden die Nutzerinnen und Nutzer, die von der Schweiz aus darauf zugreifen wollen, auf eine Stopp-Seite umgeleitet. Die Spielerinnen und Spieler werden so darüber informiert, dass der Inhalt, auf den sie zugreifen wollten, in der Schweiz nicht bewilligt ist und die Internetseite daher auf Anordnung der zuständigen Behörden gesperrt wurde. Weiter enthält diese Stopp-Seite direkte Links zu den in der Schweiz bewilligten Angeboten.

Screenshot der Sperrseite

Netzsperren in der Realität

Was passiert wenn man nun auf eine gesperrte Seite zugreift? Bei Verwendung der vom ISP standardmässig zugeteilten DNS Servern werden modifizierte IP Adressangaben zurückgegeben, bewerkstelligt durch eine Response Policy Zone (RPZ). Als Beispiel wird die Domain cryptokitties.co verwendet, die seit dem 5. Oktober 2021 auf der gespa Sperrliste steht. Löst man die Domain mit dem Public DNS Resolver von Google auf, so erhält man folgende Resultate:

DNS Auflösung mit Google

Setzt man hingegen den DNS Resolver eines Schweizer ISPs ein erhält man ein anderes Resultat. Der Browser wird dazu gebracht eine Verbindung mit einem anderen Server herzustellen. Die hinter der geänderten IP Adresse bereitgestellte Webseite ist natürlich die vom Bund spezifizierte Sperrseite auf die die User*in umgeleitet werden soll.

DNS Auflösung mit Swisscom

Dieses Vorgehen funktioniert völlig transparent bei unverschlüsseltem HTTP Verkehr. Bei gegenwärtigen Browsern wird zwar einen Hinweis links von der Adressleiste eingeblendet wonach die Verbindung unsicher sei. Aber das trifft zu unabhängig davon, ob die Verbindung gekapert wurde oder nicht. Heutzutage ist die Mehrheit des Web traffics standardmässig per HTTPS verschlüsselt was zu einer kleinen Unschönheit in diesem Setup führt. Versucht man auf eine gesperrte Seite mit HTTPS zuzugreifen wird man mit einer Sicherheitswarnung des Browsers konfrontiert. Erst wenn man diese Warnung ignoriert und wegclickt wird die Sperrseite angezeigt. 

 

Zertifikatswarnung

Chrome macht uns darauf aufmerksam, dass das Zertifikat ungültig ist. In erster Linie sieht man, dass es am 16. März 2019 abgelaufen ist. Die aufmerksame Leser*in wird aber auch feststellen, dass der Subjectname (i-dnsn-blocko-1.sharedit.ch) nicht mit dem Domainname in der Adressleiste (cryptokitties.co) übereinstimmt. Selbst wenn die Sperrseite die beiden Angaben richtigstellen würde, könnte aufgrund des fehlenden Chain-of-Trusts kein valides Zertifikat präsentiert werden. Und das ist auch richtig so: TLS, Zertifikate und PKI sorgen dafür, dass es weder einem Betrüger noch dem Bund möglich ist die Identität eines Servers zu fälschen und somit eine gesicherte Verbindung zu kapern. Deshalb würde die Erneuerung des bei oben abgebildetes Zertifikats auch keine zufriedentstellende Lösung bringen.

In diesem Sinne: https://xkcd.com/386/