Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect results for possibly downed hosts #17

Open
vermsec opened this issue Mar 13, 2023 · 8 comments
Open

Incorrect results for possibly downed hosts #17

vermsec opened this issue Mar 13, 2023 · 8 comments
Assignees
Labels
bug Something isn't working

Comments

@vermsec
Copy link

vermsec commented Mar 13, 2023

Hi @d0nutptr! Thanks for the tool its really the best.

I've noticed one issue with it when using it in my workflow. So what I do is after getting the subdomains from various sources I do a DNS resolve on them to get the IP addresses and use armada to check all TCP 65535 ports. Here if any Host is down or doesn't exist anymore armada responds weirdly on it. Its either all 65535 ports which are open or a lot of ports majorly sequential in order which it says are open. When in reality none of the ports are open. I've verified this issue with multiple such hosts and also tried different levels of rate limiting but still the behavior persists. And I've verified the host with nmap which responds the host is down and if I use -Pn it says all ports are filtered. But armada sees these filtered ports as open.

For instance I ran against this IP 103.97.3.19:

armada-1

Now if I run armada on the same host:
armada-2

And the final result which armada gives is majorly all the ports are open (Even with ratelimiting the results are pretty much the same):
image

Which if we verify with nmap, we get them as filtered
image

I'm not sure if this is intended to keep high speed for scans but if we can add a ping sweep or a way for armada to better detect this would be really good. My current workaround for this is to do a ping sweep via nmap and then use all the live hosts for armada to scan on. I guess results like these must be similar on hosts behind a firewall.

@d0nutptr
Copy link
Contributor

d0nutptr commented Mar 14, 2023

Oh that's really interesting!

Thanks for sharing so much detail - this really is the ideal Github issue xD

Sometime this week I'll go and dig into the issue and write a fix! Armada's interpretation of packets is a little basic, tbh. It looks for certain flags in a response and doesn't do much else. I will go back and build a more accurate host detection based on what nmap is doing :)

@d0nutptr d0nutptr added the bug Something isn't working label Mar 14, 2023
@d0nutptr d0nutptr self-assigned this Mar 14, 2023
@vermsec
Copy link
Author

vermsec commented Apr 11, 2023

Hi @d0nutptr, Any update on this?

@d0nutptr
Copy link
Contributor

Oh shit.. so sorry on that. I'm opening the project up right now and will begin debugging :)

@d0nutptr
Copy link
Contributor

d0nutptr commented Apr 12, 2023

Okay, so the update:

I've been able to reproduce the issue locally, though it's inconsistent. I see some discrepancies from how nmap and armada are sending packets (they're close, but different).

I have two theories on what could be causing the problem but I think i need to wait until tomorrow since the subject IP stopped doing the behavior after enough testing 😅

The two ideas are:

  • Nmap juggles sending ports, armada does not. I can force nmap to use a specific port instead of juggling them which could help me see if nmap can cause this non-filtered behavior; however, by the time I thought to try this the IP stopped exhibiting the behavior 😞

  • TCP End of Option List marker. Nmap does not send this, armada does. This is causing armada packets to be 8 bytes longer than nmap's packets. Based on the way I'm sending the packets, I'm not sure how to control this so it'd be a bit more of a time investment to figure that out. If the port juggling doesn't seem to be the cause, i'll investigate this one.

Anyway, I'll try and pick this back up tomorrow but I may have to wait until Thursday night as my Wednesday is a little busy!

@vermsec
Copy link
Author

vermsec commented Apr 12, 2023

No worries! Thanks for the update😊

You're right about the inconsistency of this issue, I've seen this happening on other IPs as well but works sometimes.

@d0nutptr
Copy link
Contributor

Awesome update!!!!

I've been able to get nmap to recreate the issue by restricting transmission to a particular ephemeral port.

image

This indicates that, to resolve the issue with armada, we need to rotate the transmission of packets with a couple of ephemeral ports.

I'm actually considering rewriting armada with some significant improvements in other areas, but this makes sense to include for reliability.

@d0nutptr
Copy link
Contributor

d0nutptr commented Apr 13, 2023

Hmm actually I'm less sure now ^^;

Nmap actually reports all of those ports open even if you let it juggle the ports. It appears to be a speed issue.

Nmap is correctly reporting them as filtered when the scan is slow, but if i set the minimum rate to 1000 then nmap starts reporting all of them as open just like armada.

Armada has a default speed of 10k packets a second. If you reduce that down to 50 then armada begins correctly reporting the ports as not open.

So, in conclusion, you probably need to run armada with a slower speed. For example:

# to run armada at 50 packets a second
armada -t <IP> -p <PORTS> --rate-limit 50

Let me know if this helps and is sufficient for your issue!

@vermsec
Copy link
Author

vermsec commented Apr 13, 2023

I'm not sure if speed is the issue here, I've tried --rate-limit with 10 and 50 values but still I get random ports reported as open.
image

While on some IPs Armada's speed is no problem and reports accurate data. Can we add another verification step right after the port scan where armada sends packets again to the discovered open ports to verify if they indeed are open. It won't take a huge hit on the speed I think but an additional --verify option to check would be good.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants