routersploit
routersploit copied to clipboard
`eseries_themoon_rce` check erroneously shows "vulnerable"
It's not possible to uniquely verify exploitation of every vulnerability. By using blind command injection test approach we are going down the road of changing integrity of the device during scanning.
RouterSploit is supposed to be an exploitation framework not a scanner (yes, we have modules that scan for vulnerabilities but its not what we are aiming for). We assume that people have certain level of knowledge and know what they are doing.
The only thing that we can add is introducing some kind of assurance based on the quality of check method - does it really exploit specific vulnerability or just checks for the existence of specific file.
@lucyoa A reasonable change that I could imagine would be to extend scanners to return one state in the set:
VULNERABLE, // Verifiably vulnerable
INVULNERABLE, // Verifiably invulnerable
MAYBE_VULNERABLE, // Conditions for vulnerability are met (e.g. file existance),
// though we can't verify without affecting the device's integrity
UNKNOWN // Requires manual fiddling
Though whether that is the simplest change or not is a different story. :)
use exploits/routers/linksys/eseries_themoon_rce
Exploit failed to transfer payload
Same issue here
I have had the same issue with a bunch of different routers. The problem is just that soooo many devices will send back valid response headers, even though nothing is on that particular URL.
If there really isn't a better way to check for the vulnerablility, i think it should never be able to directly verify the vulnerabililty. So if a valid response header comes back, it should simply return "Could not be verified" instead of "Is vulnerable". That change would be very simple to implement, and would be a much more accurate description of what it actually checks for, at least in my opinion :)
Yeah I have the same issue. It shows a Tenda router vulnerable... While I execute any command on CMD, it does nothing... I think its actually a false positive.
Same issue scanning a Synology router.
I have the same problem with a homemade router.
cmd (MIPSLE Reverse TCP) > run [] Using wget method [] Using wget to download binary [-] Exploit failed to transfer payload
Right now the check
method for this exploit returns True whenever a GET request for /tmUnblock.cgi
returns a status code of 200, 301, or 302.
Is there a more specific check that could be made against the text of the response, @lucyoa ?
My (not vulnerable) router returns status 200 with a meta refresh tag to its home page, so I can contribute the following patch which removes the false positive for my router but probably still allows a lot of other false positives:
--- a/routersploit/modules/exploits/routers/linksys/eseries_themoon_rce.py
+++ b/routersploit/modules/exploits/routers/linksys/eseries_themoon_rce.py
@@ -83,7 +83,13 @@
path="/tmUnblock.cgi",
)
- if response and response.status_code in [200, 301, 302]:
+ if response is None:
+ return False
+
+ if '<meta http-equiv="refresh"' in response.text:
+ return False
+
+ if response.status_code in [200, 301, 302]:
return True # target is vulnerable
return False # target is not vulnerable
The same issue was tested in 3 routers