Add dojo Command-Line Application
#964
Conversation
Container auth token is now a signed token instead of a random byte string. - The server signs the account id, challenge id, and an additional string. - The challenge ID is included to ensure that the token matches the active challenge. This allows for verification of the owner of the token and efficient authentication of challenge containers.
Changed return from just the user id to both the user and challenge ids. - Required for challenge matching.
Added the API endpoint for use by internal container integration.
Key features:
- Gets an authentication token from request headers (auth_token).
- Performs authentication that the token is correctly signed and matches the active challenge container.
- API calls create a session for the duration of the request.
- The session is destroyed upon completion of the request.
CTFD is open with IP 10.0.0.117. - iptables configured to accept connections from 10.0.0.0/8 (challenge containers?) to 10.0.0.117 (ctfd).
If we were to use the before/teardown_request decorators, it would have to be applied to the entire application. - The overhead of this seems excessive, and I see no advantage in running the session teardown check on every endpoing. - Why Flask does not offer the ability to specify before/after/teardown at the namespace level, I do not know.
Challenge containers now communicate with the nginx container instead of the ctfd container.
Added a python application, starting with a whoami command.
Added a testcase for the dojo cli application. - WHOAMI command is tested to ensure it returns the name of the random user.
Switched from URLSafeSerializer to URLSafeTimedSerializer to ensure that container tokens are only valid for the maximum lifespan of a container.
dojo-cli.nix is at ./core, not ./code...
Switched from `Requests` to `Urllib`.
Custom auth token header isn't showing up for some reason.
Switched from using auth_token as header to AuthToken. - Headers with underscores are dropped? Fixed incorrect signing of container token. - Docker was incorrectly using `challenge.challenge_id` instead of `challenge.id`.
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
Improved error handling of CLI application. Create an `apiRequest` function with "robust" error handling for use in later versions.
Attempt to allow challenge containers to communicate with the main dojo node. - Open 192.168.42.1 to challenge containers.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| iptables -F WORKSPACE-NET 2>/dev/null || iptables -N WORKSPACE-NET | ||
| iptables -A WORKSPACE-NET -s 10.0.0.0/24 -m conntrack --ctstate NEW -j RETURN | ||
| iptables -A WORKSPACE-NET -s 10.0.0.0/8 -d 10.0.0.3 -m conntrack --ctstate NEW -j ACCEPT | ||
| iptables -A WORKSPACE-NET -s 10.0.0.0/8 -d 192.168.42.1 -m conntrack --ctstate NEW -j ACCEPT | ||
| iptables -A WORKSPACE-NET -s 192.168.42.0/24 -m conntrack --ctstate NEW -j RETURN |
There was a problem hiding this comment.
Challenge containers are now allowed to open NEW connections to 192.168.42.1 with no port restriction. That address is the host-side bridge for the infrastructure stack, so accepting all traffic from every 10.0.0.0/8 container exposes every service bound on the host (docker daemon, databases, etc.), not just nginx. If the intent is to permit the CLI to reach the web frontend, this rule needs to narrow the destination ports or IP to the nginx container specifically; otherwise any compromise inside a challenge gains unrestricted network access to internal control planes.
Useful? React with 👍 / 👎.
1 participant
Overview
Adds a command line application,
dojo, which allows for limited interaction with a custom set of integration APIs. The application authenticates using theDOJO_AUTH_TOKENenvironment variable, which has been changed to be a set of signed values tying the token to the user and their current challenge.In order to allow for communication between the application and the dojo, challenge containers have been given network access to the nginx container. In theory the iptables configuration in
dojo/dojo-initshould ensure that this is the only other container that the challenge containers can access, but someone more familiar with iptables should sanity check this.Integrations
Added a new namespace to the pwn.college api,
integrations. Endpoints within the integrations namespace expect requests to use theauth_tokenAuthTokenheader to provide the current container's authentication token.Command
whoami
A simple command which prints out information about the current user. Prints the user's name and id.
Invoked by calling
dojo whoamiin a terminal.