`eseries_themoon_rce` check erroneously shows "vulnerable"

[ghost]

​

[lucyoa]

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.

[Keskebeu]

use exploits/routers/linksys/eseries_themoon_rce

Exploit failed to transfer payload

[6feferonka9]

Same issue here

[atjn]

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 :)

[DHIRAL2908]

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.

[OverlordAdmin]

Same issue scanning a Synology router.

[Lamera]

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

[imiddle]

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

[xqxSpl0iT]

The same issue was tested in 3 routers