(Not-So-Secret) Tunnel: Digging into Exposed ngrok Endpoints

ngrok is a popular developer tool to expose local ports to the internet, which can be helpful when testing applications or private network devices. Despite the large reconnaissance surface for development environments exposed by ngrok, most security research has focused on offensive applications for ngrok, such as (https://www.huntress.com/blog/abusing-ngrok-hackers-at-the-end-of-the-tunnel). Instead, I will focus on two new reconnaissance vectors: 1. ngrok domain squatting; and 2. ngrok tunnel enumeration.

By default, ngrok HTTP tunnels exposes HTTP traffic via randomly-generated .ngrok.io endpoints such as https://5e9c5373ffed.ngrok.io. These subdomains can be harvested from a variety of OSINT sources, such as GitHub repositories, documentation, StackOverflow answers, and “how-to” blogposts. Unfortunately, paid ngrok users can select any .ngrok.io subdomain for their tunnels, allowing them to squat on these subdomains in wait for unsuspecting users copy-pasting commands that use these hard-coded “random” endpoints. I will show examples of squatting that yielded interesting webhook callbacks and leaked information.

ngrok also allows users to create TCP tunnels which are exposed via ports 10000-20000 on *.tcp.ngrok.io. Due to the ease of enumerating these values as compared to HTTP tunnels, users can easily map out the entire ngrok TCP tunnel space. This unveiled a house of horrors, from Jenkins dashboards to even VNC and MySQL servers that allowed anonymous access! I will share a statistical breakdown of one such mapping that clearly shows that ngrok users may have been far too reliant on security by obscurity.

I will conclude by sharing some tips on using ngrok safely through built-in authentication options and domain reservation. I will also share real-life examples of ngrok endpoints popping up in production code, further highlighting the potential of ngrok as a reconnaissance source.