Sunday, June 21, 2020

Demo-ing Dhaval Kapil's icmptunnel in Docker

A recent NCL competition included a challenge that frustrated a number of participantes, one that dealt with extraction of data from a PCAP, containing ICMP tunneling traffic (i.e., the PCAP file was provided, the goal was to extract the data to acquire the flag).

The local community college as a Cyber Club, which typically meets on Friday nights. Membership is made up of current ITN students and alumni. With the recent school closures and quarantines, the in-person meetings were cancelled. However, the "die hards" decided to move the meetings online, using Discord's voice and screen sharing capabilities. (We were already using Discord as a message server.)

There was enough frustration with the NCL challenge that four of us (from the group) attacked the problem in two parts: 1) Create an architecture in which our own PCAPs could be generated, and 2) write tools or processes that can extract/un-tunnel the data from the captured ICMP packets.

Solving problem #1 took a couple weeks, mostly due to selection of the ICMP tunnel software. There's three variants on Github. We selected Dhaval Kapil's ICMPtunnel utility (link below). Being the most stubborn in the group, I was the first to complete part 1. The configuration is easy, once you realize that English is probably not the author's first language (i.e., there are logic errors in the documentation).

I used Docker and OpenVSwitch to create the architecture (image below). To keep things simple (some people have no Docker or OpenVSwitch experience), I automated as much as possible (links much below), so that users would only need to run a couple scripts to create the architecture (one to build/pull images, another to deploy the containers and network).

The architecture simulates a network architecture where a client resides behind a firewall, which blocks "normal" traffic but allows ICMP echo requests and echo replies through the firewall. A "proxy" serves as the ICMP tunnel endpoint, which decapsulates the IP traffic from the ICMP traffic and forwards it on to the target web server.

Two others used VMs to simulate their architectures, using the same tunnel software. They were hung up on the same logic errors that had stumped my efforts. They were able to fix their architectures by looking at the Docker-based scripts.

This past Friday (yesterday), two of the others demo'd their tools (scripts) to extract content from ICMP PCAP files, produced by connecting a Wireshark sniffer into the architecture (my code includes the Wireshark container with a web interface, from LinuxServer (link below).

One Club member (DgtlCwby) has created a very tightly written Bash script, which controls tshark and walks through the process of extracting the data. It works, producing an output identical to the graphic pulled from the web server.

Another student produced a Python/Scapy script which also works. He expressed some concerns about the code, having built it from a number of online articles and wanting to improve it. This turned out to be a deep rabbit hole, into which the four of us fell, make suggestions for at least two hours past the normal "end" time. They were still tweaking the script when I bailed, to join another call.)

DgtlCwby has given me permission to generate an article based on his script, explaining each step, which is what I'll be doing in the coming days (we're all learning as we go).

Links:

Wednesday, January 1, 2020

Today's project (setting up a knockd lab for CTF training) isn't improving my opinion of Ubuntu packaging much. This isn't the first time in the past week that I've run across munged packages and old code.

The scenario for the lab is that rubber hose cryptography was employed against an evil hacker and produced the following:

  • the hacker's handle
  • his workstation password
  • a sequence numbers = 2222, 3333, 4444
  • and that an encryption key will be available on a certain port

The student will be tasked with finding the hidden server in the hacker's private network, figuring out how to open the port on the server, and obtaining the key from the open port. The unstated facts include that only nmap and netcat are available on the hacker's workstation.

In the first 30 minutes, I was able to design a Docker container that runs supervisord, knockd, socat, and an internal (to the container) version of iptables. In the subsequent hour, I'd tried various things to get knockd to properly run the close-port command. Even the configuration examples provided by the original authors didn't work. The "iptables -D" commands would work on the command line but not when called by knockd.

To make the story short, if you're using the Ubuntu knockd package, the close command will need to be wrapped in "bash -c 'the command'" before it'll work properly. I've added "patching" to my to-do list but it's near the bottom (won't be any time soon). At the top of the list is adding this instance to the OVS architecture, which resides behind a Guacamole instance, and adding a dynamic flag calculation for use in CTFd.