Finding Exposed APIs and Services: A Practical Guide for Devs

As developers, we're constantly building and deploying applications, often exposing APIs, web services, and various network ports. While we strive for security from the outset, it's easy for misconfigurations or forgotten test services to slip through the cracks, leaving potential vulnerabilities exposed to the internet.

Traditional internal network scanners are great for your local dev environment, but what about the public-facing attack surface of your deployed applications? How do you quickly find out what's actually visible to the entire internet, beyond what you think you've configured?

This is where tools designed for internet-wide reconnaissance come in handy. Today, we'll explore how to use a tool like ScanSearch to identify publicly accessible services and potential weak points in your infrastructure, mimicking what an attacker might see.

The Problem: Unintended Exposure

Imagine you've deployed a new microservice. You're sure you've locked down all the ports, but what if:

• A Docker container exposed a port that wasn't properly firewalled.
• An old, forgotten test API endpoint is still live.
• A service that should be internal is inadvertently listening on 0.0.0.0 and exposed to the internet.
• A default configuration for a database or caching layer is accessible without authentication.

These scenarios are more common than we'd like to admit. Proactively finding them can save you a lot of headache down the line.

Introducing ScanSearch: Internet-Wide Device & Service Discovery

ScanSearch is an internet-wide search engine specifically designed for network devices, services, and vulnerabilities. Think of it like Google, but for IP addresses, open ports, and service banners. It continuously scans the internet and indexes what it finds, allowing you to query this vast dataset.

It's a powerful tool for understanding your public-facing footprint, performing competitive analysis (e.g., how are others deploying similar services?), or even discovering interesting IoT devices.

Practical Example: Finding Exposed NGINX Instances by Banner

Let's say you're deploying a web application behind NGINX. You want to ensure that only the intended NGINX instances are visible on standard web ports. You can use ScanSearch to look for NGINX services on common HTTP/HTTPS ports.

ScanSearch uses a query language similar to other search engines. You can specify keywords, ports, and other criteria.

Here's a basic query to find NGINX services:

nginx

This will give you a very broad list. To narrow it down to services explicitly identifying themselves as NGINX and running on common web ports (80, 443, 8080, 8443), you might use something like this:

nginx port:80,443,8080,8443

This query searches for the term nginx within service banners or other indexed data, specifically filtering for devices with those ports open. The results would show you IP addresses, ports, and often the full banner of the service, which could reveal version numbers or other identifying information.

Drilling Down: Finding Specific API Endpoints

What if you have a specific API endpoint that should never be exposed publicly, but you're worried it might be? While ScanSearch doesn't crawl individual API paths like a traditional web crawler, it can help you find the underlying service.

Let's say you're using a specific framework or have a unique string in your service banner for an internal API gateway. You could search for that string.

For example, if your internal API uses a custom header or a unique string in its default response that gets picked up by banner scanning, you could search for it. Let's assume your internal API gateway often exposes the string X-Internal-API-Gateway in its HTTP headers (though ideally, you wouldn't expose this):

X-Internal-API-Gateway

If you get any hits, that's a red flag. You'd then investigate those IP addresses to determine if they belong to your infrastructure and if the exposure is intended or not.

Discovering Open Databases or Caching Layers

Another common exposure risk is unauthenticated databases or caching layers. ScanSearch can help here too. You can search for common database banners or default ports.

To look for MongoDB instances, for example, which typically run on port 27017:

mongodb port:27017

Or for Redis, typically on port 6379:

redis port:6379

If you find your own infrastructure in these results, especially without any authentication requirements, it's critical to secure those services immediately.

Staying Proactive

Regularly checking your public-facing services with tools like ScanSearch should be part of your deployment and maintenance routine. It's a quick way to gain an outside-in perspective on your infrastructure and catch unintended exposures before they become a problem.

Remember, the goal isn't just to find vulnerabilities but to understand your true internet footprint. By doing so, you can build more resilient and secure applications.

Further Reading:

• Check out ScanSearch for more query examples and capabilities.
• Review best practices for securing your APIs and network services.