WebNet0 picoCTF 2019 Solution

Description

1. Step 1

   Load the RSA key into Wireshark

   Observation

   I noticed the challenge provided both a pcap file and an RSA private key alongside it, which suggested that the TLS traffic in the capture could be decrypted by supplying the private key to Wireshark's TLS protocol preferences.

   In Wireshark, go to Edit > Preferences > Protocols > TLS (formerly SSL). Under RSA Keys, add the downloaded key file. Then close and re-open the pcap so Wireshark applies the decryption key.

   What didn't work first

   Tried: Looking for TLS settings under Edit > Preferences > Protocols > SSL instead of TLS.

   Older versions of Wireshark labeled the protocol 'SSL' while newer versions use 'TLS'. If you are on a recent Wireshark build and only see a TLS entry, that is the correct one. The SSL entry was renamed but the functionality is the same.

   Tried: Adding the key file and immediately searching packets without re-opening the pcap.

   Wireshark decrypts on load. If you add the key while the pcap is already open, the existing packets are not re-decrypted automatically. You need to close and re-open the pcap file (or use File > Reload) for the key to take effect and show decrypted Application Data.

   Learn more

   TLS encrypts network traffic using symmetric keys negotiated during a handshake. Wireshark can decrypt these sessions when given the server's RSA private key, because the private key decrypts the pre-master secret from the handshake, which derives all session keys. This only works with RSA key exchange, not DHE or ECDHE (ephemeral Diffie-Hellman), which generates session keys that the static private key cannot recover.

2. Step 2

   Follow TLS streams to find the flag

   Observation

   I noticed that after loading the RSA key, Wireshark began showing decrypted TLS Application Data packets, which suggested the plaintext HTTP responses were now accessible and the flag would be visible by following a TLS stream.

   After adding the key, right-click on a TLS Application Data packet and select Follow > TLS Stream. Browse each stream for the flag - it appears in the HTTP response header of one of the conversations.

   What didn't work first

   Tried: Right-clicking a packet and selecting Follow > TCP Stream instead of Follow > TLS Stream.

   TCP Stream shows the raw encrypted bytes, not the decrypted content. Even with the RSA key loaded, you must choose Follow > TLS Stream to see the plaintext HTTP data that Wireshark has decrypted in memory.

   Tried: Searching the HTTP response body for the flag instead of looking at the response headers.

   In this challenge the flag is embedded in an HTTP response header, not in the page body. If you only read the body content in the TLS stream output, you will miss it. Scroll up to the header section of each response or use Wireshark's Find Packet (Ctrl+F) to search for 'picoCTF' across all packet content.

   Learn more

   Once Wireshark has the RSA private key, TLS Application Data decrypts to readable HTTP. Follow TLS Stream shows the full request and response in plaintext. Use Edit > Find Packet and search for 'picoCTF' in packet bytes to locate the relevant packet without examining each stream individually.

   Packet captures combined with private keys are a powerful forensic tool. This is why forward secrecy (DHE/ECDHE key exchange) is strongly recommended - without forward secrecy, a leaked private key can decrypt all past recorded sessions.

Flag

Wireshark decrypts TLS when the server RSA private key is provided - the flag is in an HTTP response header inside the encrypted stream.