flagchecker

Effective Cheating Detection for CTFs/competitions. Feel free to submit PR requests.

This idea was inspired by the way flags were generated in the Korean domestic CTF contest called Cyber Conflict Exercise.

I decided to create this from the scratch.

How it works

In many recent CTF competitions, docker has been used for effective competition management such as container isolation and log tracing.

All Docker containers use the host kernel, which eventually means that inserting kernel modules could affect the docker instance. Wikipedia says that

Docker uses resource isolation features of the Linux kernel such as cgroups and kernel namespaces to allow independent "containers" to run within a single Linux instance, avoiding the overhead of starting virtual machines.

This also means that hooking a syscall from the host kernel will eventually affect the container too.

With this in mind, I developed a simple Linux kernel module called flagchecker that generates a random flag and records it somewhere within the host instance to keep the record of user's flag submissions.

What flagchecker does is as follows:

1. Hooks the read() syscall.

2. When the binary calls for a read() syscall, it looks for the string.

   To ensure that the server does not suffer from the performance bottleneck, the module only reads for the first 255 byte.

3. When there is a value that matches with the hardcoded flag value

   1. The random value is generated. (0-9, a-f)

   2. Replaces the original string with the randomly generated value.

   3. /srv/flag.py is then executed to record the randomly generated value.

This project was tested on a small CTF named BingoCTF sponsored by Power of Commmunity (POC).

During the test, I created an additional server within the instance to gather the flag and and communicate with the scoreboard server.

Having the flagchecker on the same machine made it easier for the scoreboard server to integrate and for organizers to check cheating attempts.

How to use

Please refer to the each directory for more information.

Known Issues

1. Reading partial data of the flag will leak the original content of the flag.

   For example, head -c68 /flag will only read the partial data of the flag, leading to the leakage of the original flag. Make sure to make that the original value of flag is randomly generated and does not conflict with other flags.

2. Kernel will crash when you rmmod after insmod multiple times.

   It is better off to reboot the server to remove multiple kernel modules.

3. Side Channel Attacks

   I haven't verified or succeed on exploiting this bug, but it may be possible that strstr is vulnerable to timing attacks. (Reported by a person who tested this module during the initial development.)

4. Does not work on latest kernels

   OS that ships with 5.x may not work. There seem to be many workarounds for this but I was not able to succeed on testing it. If anyone's interested to fix it, submitting PR would be really helpful.