In the world of cybersecurity and ethical hacking, challenges often serve as valuable training grounds for aspiring professionals.
“Frown – An Instrumentation Challenge” is one such intriguing puzzle that promises to test your skills in setting up a complex environment and finding innovative solutions.
In this article, we’ll delve into the nuts and bolts of this challenge, explore the development and deployment process, and provide insights into tackling this unique instrumentation challenge.
Whether you’re a beginner looking to sharpen your skills or an experienced enthusiast seeking a new adventure, the journey through “frown” promises to be both enlightening and rewarding.
<! . . . . . . . . . .!>
<! . . . .[][] . . . .!> cursor keys
Lines: 4 <! . . . .[][] . . . .!> or
Figures: 18 <! . . . . . . . . . .!>
Level: 1 <! . . . . . . . . . .!> rotate
Score: 313 <! . . . . .[Frida INFO] Listening on 127.0.0.1 TCP port 27042
Port: 27042 <! . . . . . . . . . .!> [w]
<! . . . . . . . . . .!> <-[a] [s] [d]->
<! . . . . . . . . . .!>
[] <! . . . . . . . . . .!> [space]
[][][] <! . . . . . . . . . .!> |
<! . . . . . . . . . .!> V
<! . . . . . . . . . .!>
<! . . . . . . . . . .!> [p] - pause
<! . . . . . . . . . .!> [q] - quit
<! . . . . .[] . . . .!>
<! . . . .[][][][] . .!>
<![][][][][][][][][] .!>
<![][][][][][][][][] .!>
<![][][] .[][][][][][]!>
<+--------------------+>
\/\/\/\/\/\/\/\/\/\/
Nuts And Bolts
This challenge should be deployed to a fresh Ubuntu VM. There is an ansible playbook that takes care of that.
Using systemd socket activation a fresh docker instance per incoming SSH connection is spawned. Once authenticated via SSH, a game of Tetris spawns in that container. This is where the challenge begins.
A second, long living container called frown-service
should also run and serves as a flag server where keys found in the challenge binary are exchanged for a flag, if correct.
Solutions
See solution for details on how to solve this challenge.
Development
There are two containers to develop. The flag service and the main challenge container. Both of them need to be connected to a network called frownnet
(or if you want something else, update the rest with it) when started. Do that with:
docker network create frownnet
Next, build the relevant containers after changing to the challenge
directory (a symlink actually) with:
docker build -t frown:local --progress=plain -f Dockerfile.dev . |& tee /dev/null
docker build -t frown-service:local --progress=plain -f Dockerfile.flag . |& tee /dev/null
Finally, run them. Start by booting the service container. It needs the name frown-service
as the challenge binary will post there. Both should have the frownnet
network.
docker run --rm --name frown-service -it --network frownnet frown-service:local
docker run --rm -it -p1234:1234 -p27042:27042 --network frownnet frown:local
Then, run the game with tetris
in the challenge container.
To debug the challenge, set HOST_DEBUG
from CMakeLists.txt
to ON
and start tetris with gdbserver :1234 tetris
.
Production Deployment
An ansible playbook targetting Ubuntu should take care of everything needed to get this up and running. Make sure you have a new host/vm and can ssh to it. The user you SSH with should also be able to use sudo
. Then, change to the ansible/ directory and run ./play <target ip>
where <target ip>
is the address for the host. If it’s your first time running ansible, run the ./install-deps.sh
script first (ideally in a fresh venv).
Example:
❯ ./play.sh 192.168.167.135
targetting 192.168.167.135, will ask for sudo password
BECOME password:
PLAY [setup the frown challenge] **********************************
TASK [Gathering Facts] ********************************************
ok: [192.168.167.135]
...
If you want to configure local authentication (skipping the tie in with GitHub / Gitlab accounts), the password can for the user
user account can be set here.
Usage
The challenge can be configured in two ways for initial authentication. The primary (and default method) is to allow users that authenticate using any valid GitHub / Gitlab SSH key. This means the user needs to have their appropriate private key ready, while authenticating to the game SSH’d service. For local only authentication, the username to use is user
.
Example ssh
commands would therefore be:
ssh -p24 'user@github'@remote-host
ssh -p24 'myuser@gitlab'@remote-host
ssh -p24 user@remote-host
(local auth mode, password set in ansible variables file)