# H1-2006 CTF Writeup I am fairly new to CTFs - this is just my second CTF after [H1-415 CTF](https://twitter.com/Hacker0x01/status/1217561343986782209), at which I didn't get far at all. I think the most valuable thing I can do for anyone who comes across this writeup, is to describe exactly what I was thinking at each step along the way, including all my failures and dead ends. I personally always find those parts the most valuable in any bug report or writeup that I read. --------------------------------------- # TL;DR **For those impatient, here is a condensed walk-through of the CTF. If you're here after the long writeup, you can safely skip this part.**. 1. Subdomain enumeration yields several subdomains: `app.bountypay.h1ctf.com` (customer portal with username/password login), `staff.bountypay.h1ctf.com` (staff portal with username/password login), `api.bountypay.h1ctf.com`, `software.bountypay.h1ctf.com`(denies access from public IPs). 2. Content discovery on `app.bountypay.h1ctf.com` reveals `/.git/config` which references GitHub repo at [https://github.com/bounty-pay-code/request-logger.git](https://github.com/bounty-pay-code/request-logger.git) 3. Source code in the repo exposes the presence of [`/bp_web_trace.log`](http://app.bountypay.h1ctf.com/bp_web_trace.log) file, which gives us three things: * Log file gives us `username` and `password` for authentication on the customer portal, `app.bountypay.h1ctf.com`. Using these credentials we're presented with 2FA challenge. On every access It gives us a random `challenge` (md5 hash) that we need to guess a valid `challenge_answer` for. * Log file also gives us a `challenge_answer` (for the past login attempt), but no `challenge` itself. The solution is that `challenge` is simply an md5 hash of the `challenge_answer`, and there is nothing preventing the re-use of the old challenge, so we compute md5 hash of that `challenge_answer` and use this pair to login. * Last thing the log file gives us is the following endpoint: `GET /statements?month=04&year=2020` 4. Authentication cookie is base64-encoded JSON such as `{"account_id":"F8gHiqSdpK","hash":"de235bffd23df6995ad4e0930baac1a2"}`, where `hash` is the actual session, while `account_id` can be freely tampered with. 5. The `/statements` endpoint above reveals that it makes a server-side request to `https://api.bountypay.h1ctf.com/api/accounts/F8gHiqSdpK/statements?month=04&year=2020`. When accessed directly, the API endpoint responds with 401 `["Missing or invalid Token"]`. Observe the same account id value, `F8gHiqSdpK`, within the request path- which is in fact taken from `account_id` of the session cookie and interpolated into request path without any sanitization. By changing `account_id` within our authentication cookie we can thus achieve SSRF via Path Traversal - but for now only on same host. 6. Front page on `api.bountypay.h1ctf.com` reveals an endpoint that allows a redirect: `https://api.bountypay.h1ctf.com/redirect?url=https://www.google.com/search?q=REST+API`. It uses a whitelist and does not appear to allow an Open Redirect, but several BountyPay subdomains are whitelisted, including `software.bountypay.h1ctf.com`. 7. Content discovery on `software.bountypay.h1ctf.com` via SSRF with the aforementioned redirect (which bypasses IP restriction) reveals `/uploads` folder with Directory Listing enabled. The only file within it, [`BountyPay.apk`](http://software.bountypay.h1ctf.com/uploads/BountyPay.apk), can be downloaded directly from a public IP. 8. APK interacts with a Firebase instance and presents a series of screens that eventually lead to obtaining a header name (`X-Token`), a header value (`8e9998ee3137ca9ade8f372739f062c1`) and a host name (`api.bountypay.h1ctf.com`). One way those could be obtained is by decompiling the code and following the designed challenges, which involve sending [deep links](https://developer.android.com/training/app-links/deep-linking) to the app. The data of interest could either be intercepted with a proxy, or retrieved from `/shared_prefs/user_created.xml` with `adb`. Or alternatively one could also have interacted with Firebase directly, using the credentials that are located in `res/values/strings.xml`. 9. `X-Token: 8e9998ee3137ca9ade8f372739f062c1` allows us to make API calls directly on `api.bountypay.h1ctf.com` without SSRF - including `POST` calls that we could not do before. Content discovery on the `/api` directory reveals `/api/staff` endpoint. * `GET` request returns some JSON data for a couple of staff members, which includes `staff_id`field with values like `STF:KE624RQ2T9`. * `POST` request returns `["Missing Parameter"]` message. The parameter it wants is `staff_id`, and for the valid staff ids it gives `HTTP/1.1 409 Conflict` with message ` ["Staff Member already has an account"]`. Response code hints at the fact that it could provision the new account if we give it a valid staff id who's account has not yet been set up - e.g. a new joiner. 10. [BountypayHQ](https://twitter.com/BountypayHQ) Twitter account has a tweet `Today we welcome Sandra to the team!!!`, which is the new joiner we're looking for. We can find [Sandra's](https://twitter.com/SandraA76708114) twitter account among either [following](https://twitter.com/BountypayHQ/following) or [followers](https://twitter.com/BountypayHQ/followers) lists for BountypayHQ, and in her timeline we see [this tweet](https://twitter.com/SandraA76708114/status/1258693001964068864) with a photo featuring her staff access card that shows her Staff ID: `STF:8FJ3KFISL3`. 11. Using this `staff_id` in a `POST` request to `/api/staff` provisions a new account, giving us `username` and `password` to access Staff portal at `staff.bountypay.h1ctf.com`. 12. After logging in with Sandra's credentials and inspecting available endpoints and JS source code, it becomes apparent that the goal of the next challenge is to upgrade her account to Admin. We can see the endpoint for this in JS code, `/admin/upgrade?username=`, but it can only be done by an admin user. We can "report" any page, which makes admin user visit it, but there is an exception that pages under `/admin` would not be visited. There are two separate vulnerabilities that need to be chained to achieve the desired result. * Firstly, the trick is to notice that JS code uses very loose selectors (that are based on class only) to perform several actions: `$(".upgradeToAdmin").click` would issue the request to upgrade the account, and `"#tab4" === document.location.hash && $(".tab4").trigger("click")` allows us to force Admin to do the click on an element with `.tab4` class. Coincidentally, there is a feature to change avatar - which is a string used as a class name. Setting it to `upgradeToAdmin tab4` and reporting that page (`/?template=ticket&ticket_id=3582#tab4`) allows us to force Admin to make the API call. * What remains is to make sure the above call is made with the correct username, which is taken from an input with name `username`: `let t = $('input[name="username"]').val();`. There is no such input on the page we're reporting (where we can control the class via avatar), `/?template=ticket&ticket_id=3582#tab4`, but there is one in the login page, `/?template=login?username=sandra.allison`. Since backend is PHP we can force `template` parameter to be an array with both `ticket` and `login` values - and luckily for us, a rather weird backend implementation renders both templates and appends them one after another in the response. We can thus piece it all together in a request such as `/?template[]=login&username=sandra.allison&template[]=ticket&ticket_id=3582#tab4` that we "report" to Admin and this concludes the Privilege Escalation step. In response we're given a new session cookie - when logged in with that cookie we can see a new tab with customer account usernames and clear-text passwords, including Mårten's credentials. 13. Back to Customer portal, `app.bountypay.h1ctf.com`, we login with new credentials and use same `challenge`/`challenge_answer`pair as before to bypass login 2FA. We now have access to the transactions that need to be processed, but there is one last challenge - it is protected by another 2FA. The task is to exfiltrate challenge answer (code) from a page rendered in the backend within Headless Chrome, and the only thing we know about that page, is that is takes a stylesheet from a URL that's under our control and likely embeds it in that page. It can indeed be verified that our stylesheet is embedded within a `` tag with e.g. Burp Collaborator. Under this setup it's not actually possible to exfiltrate data using [recursive techniques](https://medium.com/@d0nut/better-exfiltration-via-html-injection-31c72a2dae8b) such as asynchronous `@import` loading - because imports within `` (unlike `