Ngrok: A Double-Edged Sword in Development Environments
The development environment is another attack surface
Today, I’d like to share a story about how one of our customers experienced a security incident during their
development process. This tale serves as a stark reminder that even with all the advanced security measures in
place, risks can still emerge from the most unexpected corners. In this case, the culprit was an open ngrok instance.
A Chink in the Armor
Our customer, an avid developer, was working on a TypeScript project on his Mac. This project involved building a GitHub integration, for which he was using ngrok to expose his local development server to the internet. The project also involved backend services connected to a database. Thankfully, it was a development database, with no live data at risk.
Everything was going as planned until one day, the security team noticed alerts from their EDR. The development machine was making DNS queries to a Command and Control (CNC) server, a tell-tale sign of a potential compromise.
The Plot Thickens
At first, the method of intrusion was unclear. The team initially puzzled over how the attacker could have gained access. The breakthrough came when they discovered that an ngrok instance had been left running on the developer’s machine. The ngrok tunnel, intended to facilitate the development of the GitHub integration, had inadvertently become a gateway for the attacker.
# A typical ngrok command might look something like this:
./ngrok http 3000
The above command would expose the local server running on port 3000 to the internet via a randomly generated ngrok URL. This URL was what the attacker had stumbled upon.
The Question of Discovery
The question that then begs an answer is: how did the attacker come across this open ngrok instance? While we can’t say for sure in this particular case, there are a couple of possibilities. One is that the attacker may have used a tool to scan for open ngrok instances. Alternatively, the details of the ngrok instance might have been accidentally shared or exposed in some way.
It’s worth noting that ngrok is a powerful tool widely used in development environments. Many blogs and resources explain how to use ngrok to facilitate local development.
If an attacker can find an open ngrok instance, they can potentially exploit it to gain unauthorized access to the system it’s connected to. This is why it’s crucial to follow best practices for securing ngrok instances, such as using secure access tokens and limiting the IP addresses that can connect to the instance.
# A command line example for using ngrok with GitHub webhooks might look something like this:
./ngrok http -hostname=dev.example.com 3000
The Moral of the Story
This incident serves as a sobering reminder of the inherent risks involved in development. Despite having an EDR system and a firewall in place, the risk was not entirely mitigated. Furthermore, this is not the only risk in development environments. Other potential threats exist, such as malicious NPM packages but that’s enough for this time.
In the end, we were fortunate that the CNC server was already flagged in our intelligence feed, allowing us to swiftly respond to the incident. However, it was a close call that underscores the importance of maintaining a robust security posture at all times, even during development.
Ngrok, much like a double-edged sword, can be an invaluable tool for developers, but it can also pose significant risks if not used cautiously.