Scenario: "Rio de Janeiro": Do we have another option?
Level: Easy
Type: Fix
Access: Email
Description: This scenario server is dedicated to Jenkins, a Java application managed by systemd. Jenkins is failing to start. Troubleshoot and find the problem, then apply the solution so Jenkins runs properly.
Test: The service must return the string "Sign in - Jenkins" amongst some other html code. You can check with the command curl -s localhost:8888/login | grep Jenkins | head -n1
The "Check My Solution" button runs the script /home/admin/agent/check.sh, which you can see and execute.
Description: A critical health check script at /opt/scripts/health.sh is supposed to run every 10 seconds. This check is triggered by a systemd timer. The script's job is to check the local Nginx server and write its status (e.g., "STATUS: OK") to the log file at /var/log/health.log. The log file is not being updated, and it appears the health check is failing.
Find out why the health check system is broken and fix it. The check will pass once the /var/log/health.log file is being correctly updated by the timer with a STATUS: OK message.
Test: The /opt/scripts/health.sh script writes STATUS: OK to /var/log/health.log every 10 seconds.
The "Check My Solution" button runs the script /home/admin/agent/check.sh, which you can see and execute.
Scenario: "Manhattan": can't write data into database.
Level: Medium
Type: Fix
Access: Public
Description: Your objective is to be able to insert a row in an existing Postgres database. The issue is not specific to Postgres and you don't need to know details about it (although it may help).
Helpful Postgres information: it's a service that listens to a port (:5432) and writes to disk in a data directory, the location of which is defined in the data_directory parameter of the configuration file /etc/postgresql/14/main/postgresql.conf. In our case Postgres is managed by systemd as a unit with name postgresql.
Description: There's an Nginx web server installed and managed by systemd. Running curl -I 127.0.0.1:80 returns curl: (7) Failed to connect to localhost port 80: Connection refused , fix it so when you curl you get the default Nginx page.
Test:curl -Is 127.0.0.1:80|head -1 returns HTTP/1.1 200 OK
Description: There is a Python WSGI web application file at /home/admin/wsgi.py , the purpose of which is to serve the string "Hello, world!". This file is served by a Gunicorn server which is fronted by an nginx server (both servers managed by systemd). So the flow of an HTTP request is: Web Client (curl) -> Nginx -> Gunicorn -> wsgi.py . The objective is to be able to curl the localhost (on default port :80) and get back "Hello, world!", using the current setup.
Test:curl -s http://localhost returns Hello, world! (serving the wsgi.py file via Gunicorn and Nginx)
Description: There's an etcd server running on https://localhost:2379 , get the value for the key "foo", ie etcdctl get foo or curl https://localhost:2379/v2/keys/foo
Description: A developer put an important password on his webserver localhost:5000 . However, he can't find a way to recover it. This scenario is easy to to once you realize the one "trick".
Find the password and save it in /home/admin/mysolution , for example: echo "somepassword" > ~/mysolution
"Moyogalpa": Security Snag. The Trials of Mary and John
Scenario: "Moyogalpa": Security Snag. The Trials of Mary and John
Level: Medium
Type: Fix
Access: Email
Description: Mary and John are working on a Golang web application, and the security team has asked them to implement security measures. Unfortunately, they have broken the application, and it no longer functions. They need your help to fix it.
The fixed application should be able to allow clients to communicate with the application over HTTPS without ignoring any checks. (eg: curl https://webapp:7000/users.html) and serve its static files.
Test:curl https://webapp:7000/users.html should return the content of file.
The "Check My Solution" button runs the script /home/admin/agent/check.sh, which you can see and execute.
Description: (You can learn about Linux Libraries before starting this scenario).
The Linux shared library liblzma.so has been compromised (the real compromised XZ Utils liblzma has not been used). The liblzma.so at the path /usr/lib/x86_64-linux-gnu/liblzma.so.5.2.5 is the good one. Consider the same library liblzma.so.5.2.5 at other paths as compromised or malicious (ideally we would have used other real versions with different checksums).
Find all instances of this "malicious" liblzma library (remember, it's the same library but in different directory locations) and make it so none of the running processes use it, while the applications "webapp" and "jobapp" (both of which managed by systemd) still run properly (eg, stopping those applications is not a solution).
Test:lsof | grep liblzma.so.5 returns only the liblzma in the path: /usr/lib/x86_64-linux-gnu/liblzma.so.5.2.5
The "Check My Solution" button runs the script /home/admin/agent/check.sh, which you can see and execute.
There is a web server (Caddy) on HTTP port :80 but curl http://127.0.0.1 doesn't work. Find out what's wrong and make the necessary fixes so the web server returns a URL.
Note: as a limitation, the file /home/admin/db_connector.py must not be modified so that the challenge is considered solved properly. The web server has to respond on the IP address 127.0.0.1; not only on "localhost".
Test: The command curl http://127.0.0.1 returns a URL address.
The "Check My Solution" button runs the script /home/admin/agent/check.sh, which you can see and execute.
Description: A Python web application running on port 5000 from the /opt directory is experiencing severe performance issues; every request takes more than 5 seconds to complete. The application is supposed to use the redis-server cache service for speed.
Your mission is to diagnose the performance bottleneck and restore the application to its normal, fast response time.
Do not change the Python application file slow_app.py.
Test:curl localhost:5000 returns Data from FAST cache!
The "Check My Solution" button runs the script /home/admin/agent/check.sh, which you can see and execute.
Scenario: "Hong-Kong": can't write data into database.
Level: Hard
Type: Fix
Access: Paid
Description: (Similar to "Manhattan" scenario but harder). Your objective is to be able to insert a row in an existing Postgres database. The issue is not specific to Postgres and you don't need to know details about it (although it may help).
Postgres information: it's a service that listens to a port (:5432) and writes to disk in a data directory, the location of which is defined in the data_directory parameter of the configuration file /etc/postgresql/14/main/postgresql.conf. In our case Postgres is managed by systemd as a unit with name postgresql.
Description: There is a web server on :5000 with a form. POSTing the correct form password into this web service will return a secret.
Save this secret provided by the web page (not the password you sent to it) to /home/admin/mysolution, for example: echo "SecretFromWebSite" > ~/mysolution
TIP: a developer worked on the web server code in this VM, using the same 'admin' account.
