Security and Dependability


Codesafe Testing

This module on Security and Dependability contains challenges from varying parts of Codesafe development, with some that have been developed to align with the lecture material and learning outcomes of UC Irvine's SWE 266P Software Security and Dependability, specifically the Spring 2025 offering of the course taught by Dr. Joshua Garcia. The current set of challenges are NOT meant to be completed in any order.


Lectures and Reading


Challenges

Scenario

In this challenge, you are a entry-level DevOps engineer for Panoptes, a small start-up working in the space of security information and event management (SIEM) solutions (think Splunk, SentinelOne, Datadog Wazuh), or logging infrastructure. You are taking a look through an internal-only application that is meant to support a dashboard showing system and server statistics, and you find the usage of os.system(...), which you learned to be vulnerable to OS command injection attacks. You find this in internal_sys_dashboard.py.

While the threat of actual exploitation is relatively low since the code is meant for internal-only applications, you decide to tackle it yourself to avoid any future issues. Leaving it vulnerable could allow the system dashboards to be used as a privilege escalation vector for attackers that manage to get inside the Panoptes internal network. Someone could even end up using the code in the future for an external-facing application!

Tasks

  1. Refactor away vulnerable usages of os.system(...). Not all usage of it leads to an OS command injection vulnerability and is tested for, but you may still refactor all usages of it anyways.
  • There may be different ways to accomplish this while maintaining original functionality - you can investigate refactoring using subprocess, implement input validation, or even try out other ways... (at your discretion).
  1. Maintain the original functionality of internal_sys_dashboard.py. All the test cases in checker must pass, in addition to the example exploits no longer working and the test cases that test for the exploits' failure passing

You do not need to add or adjust any of the test cases in checker. You may write helper functions in internal_sys_dashboard.py. You must modify internal_sys_dashboard.py in the /challenge directory, but there is a non-writable copy in /challenge/backup in case you need to restore the original and start over.

All of the test cases in checker must pass for the Python executable to give you the flag. In this challenge, you can read (but not modify!) the checker script.

Make sure to run the checker script by doing the following in the /challenge directory:

$ ./checker


30-Day Scoreboard:

This scoreboard reflects solves for challenges in this module after the module launched in this dojo.

7-Day | 30-Day | All-Time

Rank Hacker Badges Score