Select your country

Not finding what you are looking for, select your country from our regional selector:

Rechercher

Insomni’hack 2023 CTF Teaser – DoH writeup

woman reading on computer

For this 2023 edition, i chose to focus on the DoH (DNS Over Https) protocol because it has gained popularity for attackers as a command and control (C2) communication channel for hiding DNS traffic through HTTPS rather than using the traditional DNS tunneling. In this post, i will describe in details how to solve the challenge.

For this challenge, i used the famous Godoh C2 framework maintained by Sensepost that uses DNS-over-HTTPS as a transport medium. For more details about how it works in practice, please refer to their article here.

Description

 

 

The Powell Motors company provides a PCAP file which contains evidences of a potential data exfiltration with a large volume of suspicious DNS over HTTPS (DoH) requests. By analyzing the network traffic behavior, CSIRT team discovered that the attackers used the Godoh C2 framework as a covert channel for command and control (C&C) or data exfiltration to bypass security measures. Since the organization performed SSL break/inspection, all DoH traffic can be extracted from the PCAP Capture and analyzed. However, the security team was not able to find a way to decrypt data exchanges between the client and the C2 server. Some security researchers on social media also pointed that attackers left a backdoor in the C2 server that could allow remote code execution by sending a special crafted message using the C2 client…

  • Hint : Among the 5 secret keys returned by the DNS server, one of them is used to interact with the live c2 
  • Provided assets
  • PCAP capture : 2023-01-20-4023142337.pcap

Abstract

The PCAP capture contains a large amount of DNS-over-HTTPS traffic generated by the GoDoH C2 framework. By analyzing the communications, it appears that the C2 server is still up and running. The active domain contains a list of DNS record types. The obsolete NINFO record type returns a random hexadecimal value which looks like an AES secret key. Among the 5 secret keys returned by the DNS server, one of them is used by the active GoDoH server to encrypt data blobs in communications. By decrypting the GoDoH exchanges between the client and server, several responses sent by the client include a specific prefix “736372742e6368” followed by a command-line. By modifying the GoDoH client, we can send a special crafted message back to the server to perform remote code execution. Once exploited, the user is chrooted to a particular directory with a restricted shell. By using common bypass techniques, the user can break out of the chroot jail and find the flag.

Exploitation

Tools used

  • Wireshark
  • Golang
  • Docker
  • GCC

Reconnaissance

By analyzing the PCAP file using Wireshark, we can find a lot of DoH traffic using Google provider and two DNS lookup requests with an unknown type id 56 in the middle of nowhere… If we do a quick search on the Internet, this kind of id refers to the NINFO record type (ref. https://en.wikipedia.org/wiki/List_of_DNS_record_types). Maybe this kind of DNS record could store valuable information…

 

Let’s start by querying the insomnihack.tech for NINFO records and see if there is something interesting.

Extracting all possible AES keys returned by the NINFO record (Among the 5 possible keys, there is one used by the C2 server to encrypt blob data)

 

Replaying GoDoH exchanges

The quick and easy way to understand exchanges is to replay the network traffic from the PCAP file against a GoDoH server locally.

 

If we look at the TCP streams on Wireshark, we can extract the following parameters:

  • name parameter refers to the DNS lookup response sent by the C2 client.
  • type parameter refers to the record type id.

DoH TCP Streams

These parameters can help us reconstruct the DNS lookup responses made by the client.

Next, we can develop a simple script to parse the PCAP file and replay the GoDoH exchanges.

To specify the AES key from the command line, we can use the custom GoDoH project here. This will help us save time when testing AES keys on our local server.

Starting GoDoH server by specifying an AES key

 

Replaying GoDoH against our local server using DoHReplay tool

 

If we pick up a wrong key, the server will return errors that indicate that it was not able to decode and decompress the encrypted data blobs:

We can restart the local server by specifying another AES key until we find the right one. Once the right key is found (9773e2216d31e339b69b2b9ed0c9cf58), the output helps us identify what kind of commands were issued by the attackers from the C2 server:

The last output shows that the server seems to have received an arbitrary command with the specific prefix 736372742e6368 which seems to be some kind of backdoor.

 

Modifying the GoDoH client to perform RCE on C2 server

To trigger any commands on the server, we can modify our C2 client to send arbitrary outputs as follows:

 

Rather than hardcoding the output command, we also added an additional parameter to the init() function:

 

Performing RCE through the C2 backdoor

The last output command issued by the client gives us a hint on how to start to interact with the live C2 server.

 

Simple command to extract the content of the ‘/etc/issue’ file on C2 server

Output received from our netcat listener

Notice that the live GoDoH server only accepts HTTP and HTTPS outbound traffic !

The output reveals that the GodoH process is running in a kind of jail (chroot env) for alpine linux OS. By trying the basic linux commands like ls and such, we quickly figure out that only the following commands are available:

  • echo
  • base64
  • cat
  • whoami

To escape from the jail, we need to compile a binary and drop it on the server to break out of the chroot. The answer is on the Internet, and our precious can be found here… This binary first needs to be compiled for Alpine Linux, so let’s start a new Alpine docker container, install the necessary packages and compile the devil to retrieve the flag:

Since the chmod command is not available from the jail, we need to find a way to execute our binary. A simple trick is to load our binary using the dynamic linker/loader /lib/ld-musl-x86_64.so.1 from musl-dev package.

Finally, we have all the pieces to build our final exploit command and grab the flag.

 

Capturing the Flag!

Final exploit to grab the flag!

 

 

Réponse à incident

Vous faites face à une Cyber attaque ?

24/7/365 nos experts vous accompagnent réponse à incident.