Skip to content
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

unreliable results #11

Open
TwinTechSolutions opened this issue Jun 29, 2020 · 7 comments
Open

unreliable results #11

TwinTechSolutions opened this issue Jun 29, 2020 · 7 comments

Comments

@TwinTechSolutions
Copy link

Hi , I used my own shodan api keys ,

i got theses in owned
148.244.67.69:22:root:root
78.134.3.86:22:root:root
174.98.52.139:22:root:root
174.98.110.179:22:root:root
171.103.80.7:22:root:root

but couldnt connect

@noptrix
Copy link
Owner

noptrix commented Jan 19, 2021

@TwinTechSolutions thx. will work on this

@TormentedSoul666
Copy link

This is due to not checking for being really logged in with e.g. "id" or the like but simply relying on not getting "Access denied" back. This is a poor approach, because nowadays most SSHs have asynchronous behavior and send for example strings like "Copyright by Sonicwall" etc. back, which the script interprets as success. The -e switch is not working and together with the just mentioned issues producing a long list of owned.txt entries with various user:pass combos for the same host. Sending commands via -c inline or - as described - "line by line" doesn't seem to work at all.

I've tried to use this tool in a CTF red teaming scenario and it was honestly unusable.

If I find some time on weekend, I'll do a put request in the next week.

@TormentedSoul666
Copy link

"[*] found a login (check owned.txt)
[+] sending ssh commands from payload
Exception in thread Thread-228922:
Traceback (most recent call last):
  File "/usr/lib/python3.8/threading.py", line 932, in _bootstrap_inner
    self.run()ultiple targets
  File "/usr/local/lib/python3.8/dist-packages/paramiko/transport.py", line 2154, in run
    self.packetizer.close()ts
  File "/usr/local/lib/python3.8/dist-packages/paramiko/packet.py", line 207, in close
    self.__socket.close()gets
  File "/usr/lib/python3.8/socket.py", line 500, in close
    self._real_close()targets
  File "/usr/lib/python3.8/socket.py", line 494, in _real_close
    _ss.close(self)le targets
OSError: [Errno 9] Bad file descriptor"

Seems to have the same source of issue

@noptrix
Copy link
Owner

noptrix commented May 13, 2021

@TormentedSoul666 yes, i know. PR would be nice, thanks. in any case, i will fix most of the things mentioned in all issues.

@TormentedSoul666
Copy link

@noptrix I'll have some time next week and take a look at threading (The high RAM usage is probably due to loading all file contents at once and not using a queue), why the -e doesn't exclude the host when already pwned, fine tune the pwned detection a bit by not relying on the Paramiko exception and look into why it's not sending the payload correctly.

Anyways: Awesome idea and so far very good approach. Sorry for my other rage post, I was in the middle of a paid job and got a little frustrated.

@noptrix
Copy link
Owner

noptrix commented May 13, 2021

@TormentedSoul666 thank you. no worries, all fine:) i will also start working on it... cheers

@Silentassassin22
Copy link

This is still a issue, anyone know any good alternative tools to use?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants