You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[*] Running module exploits/routers/linksys/eseries_themoon_rce...
[+] Target is vulnerable
[*] Invoking command loop...
[*] It is blind command injection - response is not available
[+] Welcome to cmd. Commands are sent to the target via the execute method.
[*] For further exploitation use 'show payloads' and 'set payload <payload>' commands.
'show payloads'
set payload mipsle/reverse_tcp
run
Immediately upon pressing the enter/return key and sending the command, I get the following error, and it exit's me from the program and returns me to my command line:
Traceback (most recent call last):
File "/opt/routersploit/routersploit/interpreter.py", line 389, in command_run
self.current_module.run()
File "/opt/routersploit/routersploit/modules/exploits/routers/linksys/eseries_themoon_rce.py", line 54, in run
shell(self, architecture="mipsle", method="wget", location="/tmp")
File "/opt/routersploit/routersploit/core/exploit/shell.py", line 124, in shell
data = payload.generate()
File "/opt/routersploit/routersploit/modules/payloads/mipsle/reverse_tcp.py", line 21, in generate
reverse_ip = utils.convert_ip(self.lhost)
File "/opt/routersploit/routersploit/core/exploit/utils.py", line 69, in convert_ip
res += bytes([int(i)])
ValueError: invalid literal for int() with base 10: ''
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "rsf.py", line 29, in <module>
routersploit(sys.argv)
File "rsf.py", line 25, in routersploit
rsf.start()
File "/opt/routersploit/routersploit/interpreter.py", line 125, in start
command_handler(args, **kwargs)
File "/opt/routersploit/routersploit/core/exploit/utils.py", line 177, in wrapper
return fn(self, *args, **kwargs)
File "/opt/routersploit/routersploit/interpreter.py", line 394, in command_run
print_error(traceback.format_exc(sys.exc_info()))
File "/usr/lib/python3.8/traceback.py", line 167, in format_exc
return "".join(format_exception(*sys.exc_info(), limit=limit, chain=chain))
File "/usr/lib/python3.8/traceback.py", line 120, in format_exception
return list(TracebackException(
File "/usr/lib/python3.8/traceback.py", line 509, in __init__
self.stack = StackSummary.extract(
File "/usr/lib/python3.8/traceback.py", line 340, in extractif limit >= 0:
TypeError: '>=' not supported between instances of 'tuple' and 'int'
root@kali:/opt/routersploit#
And then I have to restart the program, reload global configuration/port settings, etc, and then, if I was to attempt to just run steps 5 and forward (in the above replication steps), it would, and will, still give the same errors with the same result as detailed above.
Your Environment
RouterSploit Version used:
Codename : I Knew You Were Trouble
Version : 3.4.1
Operating System and version: Linux kali 4.19.118-Re4son-v7+ armv7l GNU/Linux
Currently, and for several weeks, the eseries_themoon_rce module has been throwing multiple errors resulting in the complete exit of the program upon execution of either payload contained within the module, on either architecture. I have avoided the use of the module as much as I can, in the spirit of a future update potentially correcting the error but it is immediately relevant to my current work project so I decided to make contact regarding the error.
Expected Behavior
I expected that the module would, at the least, function correctly instead of error-exiting, although I have experienced on-and-off issues of various natures with this particular module for quite a few years now.
The text was updated successfully, but these errors were encountered:
I did just run git pull and pull an update, however I ran the module again, and it still hasn't changed the performance from the situation described in my original message. I didn't think it would, as the changes were to README.md and two of the wordlists. Just wanted to let you know.
The Routersploit Version is still Version: 3.4.1
I believe that this may have something to do with a device)target showing as positive (vulnerable) to an exploit, but not using the architecture the exploit is intended for. I experienced the same issue as my original issue with a device I knew wasn't the mipsle or mipsbe architecture and it did the same error. However, I was also able to achieve the same error on a different exploit module as well. I'll provide more information and specifics if it would be helpful, just let me know!
Steps to Reproduce (for bugs)
Taking it from the initial startup of the program to error, here are the steps I've taken.
sudo python3 rsf.py
use scanners/autopwn
set target 54.77.xx.xxx
(IP Address redacted for client confidentiality, if it is desired to be disclosed please contact me directly)run
Upon completion of the scan, the target is vulnerable to:
use exploits/routers/linksys/eseries_themoon_rce
set target 54.77.xx.xxx
run
Output:
set payload mipsle/reverse_tcp
run
Immediately upon pressing the enter/return key and sending the command, I get the following error, and it exit's me from the program and returns me to my command line:
And then I have to restart the program, reload global configuration/port settings, etc, and then, if I was to attempt to just run steps 5 and forward (in the above replication steps), it would, and will, still give the same errors with the same result as detailed above.
Your Environment
Linux kali 4.19.118-Re4son-v7+ armv7l GNU/Linux
Python 3.8.3
Current Behavior
Currently, and for several weeks, the eseries_themoon_rce module has been throwing multiple errors resulting in the complete exit of the program upon execution of either payload contained within the module, on either architecture. I have avoided the use of the module as much as I can, in the spirit of a future update potentially correcting the error but it is immediately relevant to my current work project so I decided to make contact regarding the error.
Expected Behavior
I expected that the module would, at the least, function correctly instead of error-exiting, although I have experienced on-and-off issues of various natures with this particular module for quite a few years now.
The text was updated successfully, but these errors were encountered: