-
Notifications
You must be signed in to change notification settings - Fork 87
Service Example
For this example we are walking through the following challenge:
The service implements a simple calculator that solves a user-provided formula.
Once connected, the program asks the user for a username, a password and a title. After that, the program will ask the user for the formula to solve and eventually the submitted title and the result of the computation are stored inside a file named {username}_{password}.txt
(username and password corresponds to the parameters provided during the interaction).
The scriptbot uses the following mapping between values for the service (username, password, title) and values for the iCTF framework (flag_id
, secret_token
, flag
):
name in service | name for ictf |
---|---|
username | flag_id |
password | secret_token |
title | flag |
To store the flag in the service (setflag.py
), the Scriptbot performs the following actions:
- the scriptbot communicates to our infrastructure that it is going to update the username/
flag_id
, the password/flag
and the title/secret_token
for the simple_calc service - the scriptbot interacts with the simple_calc challenge, using the
set_flag.py
script, to set the new title/flag
and username/flag_id
- the simple_calc service stores the file with the parameters provided by the setflag script
To retrieve the stored flag (getflag.py
), the Scriptbot uses the service's "retrieve" functionality to cat the file corresponding to the given username/flag_id
. To do this, the scriptbot must provide the password/secret_token
, which is known only to the Scriptbot:
Since the teams don't know the password/secret_token
, they can't simply cat the saved results (which contain the title/flag
) through the retrieve functionality. To get the flag, they have to hack the service.