This is a continuation of the previous post talking about BSidesROC onion related CTF challenges.
One team figured this one out. The point of this challenge is to exemplify a common problem with onion services. Basically, if you don’t configure the web server correctly, there are cases where an onion service might leak additional information about the host. For example, if you were hosting an onion web service on the same server as another web service, you could sometimes replace the Host header with something like “localhost” and have crushing results.
Here’s the clue:
A host is a host to most to most
except to most that want to host
an anonymous host to be a ghost:
don't co-host local hosts,
or repost hosts' POSTs,
and at most,
don't boast,
or your anonymity is toast.
http://bsidesrocdiny55l.onion
Going to that URL would just show you a static page with some silly JavaScript visualization. Under the hood what I’m running are 3 docker containers. I have an NGINX reverse proxy, a web server hosting the onion service, and a second web server that contains the answer. The reverse proxy is really what you’re exploiting here. It’s configured to direct requests to appropriate containers based on the host header you send it.
Here’s what my docker-compose.yml file looked like:
version: '2'
services:
proxy:
image: jwilder/nginx-proxy
ports:
- "4000:80"
volumes:
- /var/run/docker.sock:/tmp/docker.sock:ro
web1:
image: nginx
environment:
- VIRTUAL_HOST=bsidesrocdiny55l.onion
volumes:
- ./web1/public:/usr/share/nginx/html
web2:
image: nginx
environment:
- VIRTUAL_HOST=localhost
volumes:
- ./web2/public:/usr/share/nginx/html
So if you used something like BurpSuite or the Firefox plugin Modify Headers you could replace the normal header with “localhost” and you’ll see this:
Only one team figured this one out.
Answer: NEVER_TEST_A_TESTA