CommNet

Platform: Hack The Box | Category: Web | Type: Challenge | Difficulty: Easy | OS: NA | Author: D3v0o0Nu11 | Date: 2026-01-27 | Status: Solved Techniques: broken_access_control, idor_exploitation

Summary

Cut off from each other and besieged by undead propaganda, humanity's survivors rely on CommNet—until the white-hats break in to silence the broadcast and reconnect the enclaves.

Recon

Port scan

nmap -p- -sV -sC <TARGET> --min-rate 1000 -Pn

Enumeration highlights

• Event: Hack The Box | ID: 2026_01_27_hackthebox_commnet
• Tags: nodejs, idor, express, access-control, secure-coding
• Indicators: m.id = ?, recipient_id IS NULL
• Source: 2026_01_27_hackthebox_commnet.md

Foothold

Vulnerability / Misconfiguration

1. Broken_access_control
2. Idor_exploitation

<command>

Exploitation

• See original writeup content for detailed exploitation.

Privilege Escalation

Enumeration

sudo -l
find / -perm -4000 2>/dev/null
getcap -r / 2>/dev/null
cat /etc/crontab
ps aux

Exploitation

1. N/A for challenge-type writeup; see exploitation above.
2. Flag obtained via challenge solve.

<command>

Flags

Key Takeaways / Lessons

• broken_access_control
• idor_exploitation
• Tags: nodejs, idor, express, access-control, secure-coding

Original Writeup

<details><summary>Click to expand original content</summary>

CommNet — Hack The Box

Description

Cut off from each other and besieged by undead propaganda, humanity's survivors rely on CommNet—until the white-hats break in to silence the broadcast and reconnect the enclaves.

Analysis

During a source code audit of the CommNet application, critical vulnerabilities were discovered in the message handling mechanism (routes/messages.js):

1. IDOR (Insecure Direct Object Reference): The GET /api/messages/:id endpoint allowed any authenticated user to view any message in the database by simply specifying its ID. Access control checks (whether the user is the sender or recipient) were missing.
2. Broadcast message leakage: The general message list (GET /api/messages/) displayed all broadcast messages (recipient_id IS NULL), allowing access to system or confidential information not intended for everyone.
3. Unauthorized broadcasting: The POST /api/messages/ endpoint allowed any user to send broadcast messages, as there was no role verification when recipient_id was absent.

Solution

To fix the vulnerabilities, the following changes were made to routes/messages.js:

1. Restricting Access to Message List

Removed the OR m.recipient_id IS NULL condition so users only see messages where they are the sender or recipient.

// Before
WHERE m.sender_id = ? OR m.recipient_id = ? OR m.recipient_id IS NULL

// After
WHERE m.sender_id = ? OR m.recipient_id = ?

2. Fixing IDOR

Added a check to verify the message belongs to the current user when requesting by ID.

// Before
WHERE m.id = ?

// After
WHERE m.id = ? AND (m.sender_id = ? OR m.recipient_id = ?)

3. Restricting Broadcast Permissions

Added user role verification. Only administrators can send messages without specifying a recipient (broadcast).

// Added
const userRole = req.session.role;
if (!recipient_id && userRole !== 'admin') {
    return res.status(403).json({ success: false, error: 'Only admins can send broadcasts' });
}

</details>

---

Auto-tracked: saved to WriteUps; run /xesor-revise to fold lessons into XESXor_Methodology.md.

signed by XESXOR