-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
[BUG] Template scans user-specified port #5546
Comments
That's because the value of the |
@dwisiswant0 so that is the template fault or what? Because it produces a lot of false positive on my end |
try this command, cc @dwisiswant0
Output:
|
JavaScript argument is different from a dynamic runtime variable. That stdout you're seeing is the output from variable, so this is expected behavior. |
@dwisiswant0 huh? but that is a lot of false positive. Should we remove the template or what? How to fix that? |
Port: "6379" So, no matter what port value you supply to the engine, it will still try to connect to the port (argument) as (statically) defined in its template. |
@dwisiswant0 But the output looks like this, then how to fix it? I have asked many times but still no answer yet
The expected result is something like this because 6379 ISNT open
|
Here's your answer - #5546 (comment)
I see. Do you have any idea why it's connecting to the port from variable instead of argument, @tarunKoyalwar? |
@daffainfo - can you confirm if you're supplying to the engine without port value to that template, will it connect to the hardcoded |
@dwisiswant0 yes, youre correct. It will connect to harcoded port value. If i specifed the port in the argument, it will replaces the hardcoded port value |
Got you. A temporary fix for this issue seems to be changing the property used for hardcoded port values from the JavaScript protocol. Meanwhile, I'm gonna reopen this issue until we get confirmation from the team. |
@daffainfo @dwisiswant0 , this is expected behaviour , if you remember each tcp template had something like
basically nuclei would run it on given address (host:port) and on hardcoded port as well , but later on we simplified it to do this check internally by using Port field which first probes if port is open ( cached as well) and then attempts to run the template #4123 ideal solution would be that templates have service field like but this is more of a long term solution and the current behaviour you are experiencing is expected @daffainfo current solution is to improve matchers in template so it doesn't produce FP |
Is there an existing issue for this?
Current Behavior
Even though port is already specified in the template, let's say this template
/javascript/enumeration/redis/redis-require-auth.yaml
. This template will scan port 6379, but if you specified another port in the user input, for example port 110. The template will scan 110 instead of 6379Expected Behavior
The template should be stopped
Steps To Reproduce
Im using an IP address from shodan
Relevant log output
Environment
Anything else?
I also found weird case like this, I scanned my own website which is daffa.info with port 443. And the output was something like this:
As you can see it looks like they scanned port 443 and 6379? And it only happen if I specified port 80 and 443 in my input
The text was updated successfully, but these errors were encountered: