Improving port scans against API servers

I don’t know about you, but I’ve been port scanning my targets for decades.

While many tools come and go, I have always found Nmap to be my favorite for port scanning. It’s been a staple in my arsenal for so long that it would be fair to say I have blinders on when it comes to most competing tools.

It’s even a key recommendation in my Beginner’s Guide to API Hacking.

Hell, back in the Windows XP SP2 days, when Microsoft removed raw socket support, I sent in a few pull requests to Fyodor just to get Nmap working properly on Windows again so I could do my port scans. It’s hard to believe that was over 20 years ago.

Ya, I get it. I’m old.

But I don’t believe in the saying, “You can’t teach an old dog new tricks.”

I’m always learning. Always improving.

That is proven by the fact that I recently updated my methodology for port scanning during recon of API servers.

Let me explain why.

It’s all Jason Haddix’s fault.

I recently attended Jason’s TBHM Live Training course. As always, he did a great job showcasing his updated bug hunter’s methodology. One part of the training included a discussion on using Project Discovery’s Naabu port scanner instead of Nmap to check for live TCP ports quickly.

I was about to rebut his point about it being faster than Nmap for initial port scans right up until I tried it. Because you can do a more thorough service discovery scan with Nmap afterward as an argument to Naabu, it changed my opinion of using it.

I actually like how you can tune Naabu like that. By the time the class was done, I had tweaked the tool config to my own liking, and it improved my methodology by reducing the port scan time by more than half.

Let me show you how.

Naabu 101 – The Basics

OK, so let’s get right to it.

You can do your basic port scans with nothing more than naabu -host TARGET. The defaults are alright, but it barely does anything different than Nmap this way.

But then you can start applying their flags…

Flags to know

• -p : Define which port(s) you want to scan. Individual ports can be delimited with commas. A range can be delimited with a dash. A shortcut is to use only a dash, which represents scanning ALL ports. ie: naabu -p 80,443 -host localhost, naabu -p 0-1024 -host localhost, or naabu -p - -host localhost
• -c : The number of internal worker threads. By default, this is 25. ie: naabu -c 30 -host localhost
• -rate : the number of packets to send per/second. The default is 1000. ie: naabu -rate 2000 -host localhost
• -s : The scan type. This can be followed with “s” for a SYN scan (default… requires elevated privs), or “c” for a CONNECT scan. If you are not running Naabu escalated, it will fall back to a CONNECT scan. ie: sudo naabu -s "s" -host localhost
• -warm-up-time : The time in seconds between phases of scans. By default, this is 2. ie: naabu -warm-up-time 5 -host localhost
• -retries : The number of times a request will be tried. The default is 3. ie: naabu -retries 5 -host localhost
• —silent : Only displays results in the output. This reduces the informational and debug messages sent to the screen.
• -nmap-cli : nmap command to run on any found results.

My optimized port scan

Now that you have a basic idea of how Naabu works, let’s combine some of the flags to tweak out the ultimate command for port scans. The result will be a full scan against every port, followed by a service discovery scan and fingerprint with Nmap against the detected ports.

It looks something like this:

naabu -p - -rate 2000 -c 50 -retries 2 -warm-up-time 1 -silent -host crapi.apisec.ai -nmap-cli 'nmap -sV -oX scan.xml'

Let me explain why I configured it this way…

1. -p – : I am scanning all 65535 ports on the target so we don’t miss any potential additional services hosted on the target server.
2. -rate 2000 : The defaults for 1000 packets are too low. I doubled the number of packets sent out per second.
3. -c 50 : I increased the internal threads to 50 to improve the concurrency of processing.
4. -retries 2 : I don’t want to retry the port connection more than twice if something goes wrong. We do want to retry in case there are gremlins in the wire… but we don’t need to try it 3 times as the default wants.
5. -warm-up-time 1 : I reduced the time between scan phases to 1 second.
6. -silent : I reduced the output to the screen. This way, if I want to tee it out to other files, I don’t have extra cruft in the logs.
7. -nmap-cli ‘nmap -sV -oX scan.xml’ : After the initial scan with Naabu, the list of open ports is pushed into nmap for a service discovery scan. All output is saved in a compatible Nmap XML file so it can be passed to other tools like gowitness later.

Wait. Why not optimize with half-open SYN scanning?

The astute may have looked at my scan command and wondered why I was doing a full CONNECT scan instead of a half-open SYN scan. Reducing the number of packets by ignoring the three-way handshake would speed it up, wouldn’t it?

You’d think so. But not really.

Here’s why.

When expanding the number of packets already being sent out across even more threads, the lingering of the socket teardown on a half scan actually takes MORE time. While fewer packets are indeed being sent to the target, as there isn’t a completion or a reset of the connection, it takes more time to cycle the connections for some reason. In 100 scan tests, every single one of them took longer with a SYN scan when using Naabu.

In addition, I always like to run with the fewest privileges when I can, especially when scanning since I am usually doing that on ephemeral resources anyway.

So, no root for you. It’s simply not needed.

As you can see from the scan of the OWASP crAPI server being hosted by APISec University the attack surface is more than the web app and API. Sure the web app is being detected on port 80, but it’s running on what appears to be a Docker Swarm (ports 2377/7946), which really should be better firewalled, as those ports shouldn’t be exposed directly to the Internet. YMMV in how you interpret that as part of your recon.

So what happens to Nmap now?

If Naabu is so useful, what happens to Nmap now?

Nothing.

I still believe it’s a more mature scanner, and the Nmap Scripting Engine (NSE) is awesome for additional checks and discovery. But Naabu is being added for the initial port scan recon to see if it’s open; Nmap is still being used for the heavy detection logic once a port is discovered.

Conclusion

Jason changed my mindset for the initial port scan recon. Naabu works quite well to detect if a port is actually open and does so quickly. Because it can call out to Nmap to do the service discovery, it gives me what I need for the more detailed scan, providing me the best of both worlds.

The result? Port scans against my targets are being completed in half the time, and I still have the depth and detail I want in an Nmap format that can be pushed into other tools that rely on it.

So give Naabu a try. You might be surprised how well it works for you.

One last thing…

Have you joined The API Hacker Inner Circle yet? It’s my FREE weekly newsletter where I share articles like this, along with pro tips, industry insights, and community news that I don’t tend to share publicly. If you haven’t, subscribe at https://apihacker.blog.

The post Improving port scans against API servers appeared first on Dana Epp's Blog.

*** This is a Security Bloggers Network syndicated blog from Dana Epp's Blog authored by Dana Epp. Read the original post at: https://danaepp.com/improving-port-scans-against-api-servers