Open l0rdnic0 opened 4 years ago
Hi, probably it is a limit connections per second from the cisco side... Are you trying the script on Windows or Linux ? please try to connect manually to the telnet port inmmediatly when the code hungs just to see if there is a problem with script run enviroment or if is problem from the cisco router.
Please try to google about login credential recovery on cisco switches, there is probably a way to recover/blank them using serial-db9 or something, or even opening the cisco switch and serial-ttl directly to the main board maybe.
there are also other telnet-brute force scripts out there: https://github.com/lochv/telnet-bruteforce https://github.com/dtrinf/telnet-bruteforce and there is also tools like THC Hydra that I mention on the README.md but this scripts helps on the code verification part.
There are usually some brute-force prevention methods, conections per second limit, verification codes (like that one that it is acts like a captcha), etc.
some times the connections per seconds are tied to remote IP, so you could assigns several IP's to your linux iface and rotate them in each try to connect to telnet.
Please if you need further help on this don't heasitate, ask again.
Thanks for your quick reply. Looking deeper into this I think the issue is what is being expected. So I' am running your code from a Debian based os, Below is a result of a telnet session..
User Access Verification
Username: dfg Password:
% Authentication failed
Username:
Here is the output of that through your script with Debug turned on.
Telnet(192.168.3.2,23): send 'password1\n\n' Telnet(192.168.3.2,23): recv '\r\n\r\n% Authentication failed\r\n\r\nUsername: ' [+] Trying user: administrator2 Telnet(192.168.3.2,23): send 'administrator2\n' Telnet(192.168.3.2,23): recv '\r\nUsername: ' [+] Trying user: administrator3
What I think is happening here is the code is reading until : from this line while True: # while requesting input response = tn.read_until(":", 1) # until input request
Thank you for your advice. Yes I can recover the switches if I visit each remote location and power the switches off and preform password recovery on them... trying to avoid that since I have a list of possible username/passwords. I will look at the other tools you noted.
It could sound kind of obvious but are you completely sure that you forgot the password and it is not other problem? I think that Cisco central management console it can disable telnet login to users on devices, and sometimes switches failback to default credentials, some time I had a bad cisco switch that even when I put valid credentials after some time i could not login into web ui and have to try with cisco:cisco or admin:cisco and it worked...
Hello,
I found your code helpful for trying to recover a number of Cisco Switchs during a merger. However, I'm trying to identify a solution to a problem that I am facing. I am using an index file containing a number of known username:password combinations. When I launch the script it runs as expected and passes the first username and password combination. After sometime the switch rejects the username and password and then the script reports that its trying the second user in the index file. Here is the output I see. sferris@ip:~/recover> python ./telnet_login.py 192.168.3.2 test.txt [+] Port 23: Open [-] Port 23: Connecting... Opening... test.txt [+] Trying user: administrator1 [+] Trying password: passwword1
[+] Trying user: administrator2 [+] Trying user: administrator3 [+] Trying password: password3
I never see password number 2 as it moves from username2 directly to username3 and after the third failure the switch drops the connection, but the script just hangs and I am forced to break out of it.
I am running this script on a know working device as a test so in my index file of usernames and passwords the fourth line contain the correct combination, so if I re run the script it logs in and notes the correct username and password.
Any idea why the script would jump the second password and go right to the third username? Also, why the connection would not timeout after the session drops so that main starts back up?