I know this is positioned as a hacking tool, but it seems actually pretty useful. It's pretty easy to lose track of where your keys are used and how you might perform hops. Having that diagram be generated for you really looks useful and can help you navigate this.
I'm sure there are good practices to solve this (and please suggest them, I'm always looking to learn more), but I'm no expert. I do daily drive linux and am terminally terminal, so it wouldn't surprise me if the GUI people are even worse. I think this is a general problem with a lot of terminal based tools, is that there are far higher expectations to read the documentation and less focus on design (and importantly, design that makes sense to someone that isn't you). Totally fine for hacky projects but with something as mature as ssh it seems like we'd have far better tools built in or to exist. I'm sure many do exist, but are they well known? (I'm happy to see any tools if you all have some suggestions)
Yes, it is a very useful tool. Used to do very similar when I worked as a sysadmin in larger infrastructures that largely get managed over ssh. A surprisingly large number of infrastructures have keys setup for individual sysadmins across all hosts, through straight sshd user auth.
One problem this helps with is getting into older servers with an unknown password and can't be rebooted for business reasons. At some point, some person may have setup keys to that host, and the only way to find out which is to basically try all hosts and all users. So having something that snakes through an infrastructure like this would help get into that host.
It's for post-exploitation, all the "crunchy outside, chewy interior" 90s style insecure enterprise networks separated from the elements by a perimeter firewall have 10.x ipv4 addressing.
I don't think anything changed in this respect since the 90's.
(Well, except we have more of the nu-style "expose all ports to the Internet and protect them with an HTML form and a q1w2e3 password, #yolo" corporate networks.)
I'm curious why this tool wouldn't use all the settings in the ssh config to attempt to connect to hosts.. instead it only picks a subset of those settings. For example, of the config file specifies a port besides 22, it won't be able to connect to that host (or for example, if the config file sets `PubkeyAcceptedAlgorithms=+ssh-rsa` which is necessary, albeit insecure, if using an older private key file on a newer version of ssh which disables RSA key exchange)
I see no downside to just using the hostname from the config file instead of trying to apply a few select options from the config, and non-standard ports are extremely common
Is there any risk with running this locally just to see what SSH traversal is available? I have several legitimate hosts I SSH into regularly, some are cloud hosting.
This is a good reminder to give keys only to huma s and in case of e.g. backups use specific users and limit the commands this user can access on the remote machines via jails or the authorized key file.
Combined with the admission that the tool is intended for hacking, I would be concerned that it would suddenly start to phone home with all keys and hosts at some point after users have started using it.
Agree, and especially if it's from a dubious source. Piping it directly from curl to bash makes that near impossible if you run it multiple times.
Even suggesting that for something like this in the readme is a red flag to me.
It's probably just a bad habit on the part of the author, but it may very well be intended to promote such unsafe practices with the intent to at least have the option to exploit it at some point later.
"near impossible" referred to the specific act re-reading the code every time you run it, which you should do if you use the exact method for executing it that is in the readme.
There are many ways more competent/sane users who realize the danger can work around those.
My concern is that some percentage of users are likely to follow the method in the readme to the letter, without knowing or caring about the danger. Either the author knows this (if not-> incompetent, which is not likely), doesn't care (maybe it's mostly intended for black hack hacking).
Or it's actually a trap, where it's first presented as a useful tool, but where a phone home addon is injected at some point later, and able to collect massive numbers of keys before it's detected.
Obviously, but the howto in the readme does lay the groundwork for a huge security concern if some admins start to run it recurrently in that way, without reading the code every time.
> The tool is marketed as fileless.
Which is great if your purpose is indeed to use it for hacking, and you run it on machines that you've already compromised, not on your own.
For anyone else, I think it's vital to only run it from an instance where you can download it and examine the code every time there is a change. I would do a git pull for that, not a curl command. Git makes it easier to go through all changes every time you do a pull.
30 comments
[ 4.6 ms ] story [ 72.5 ms ] threadI'm sure there are good practices to solve this (and please suggest them, I'm always looking to learn more), but I'm no expert. I do daily drive linux and am terminally terminal, so it wouldn't surprise me if the GUI people are even worse. I think this is a general problem with a lot of terminal based tools, is that there are far higher expectations to read the documentation and less focus on design (and importantly, design that makes sense to someone that isn't you). Totally fine for hacky projects but with something as mature as ssh it seems like we'd have far better tools built in or to exist. I'm sure many do exist, but are they well known? (I'm happy to see any tools if you all have some suggestions)
One problem this helps with is getting into older servers with an unknown password and can't be rebooted for business reasons. At some point, some person may have setup keys to that host, and the only way to find out which is to basically try all hosts and all users. So having something that snakes through an infrastructure like this would help get into that host.
"IPv4 Only: Like all of the best programs, the script does not support IPv6. I can't imagine there will be support for this anytime soon."
What are considered "all the best programs" these days? Is IPv6 adoption really so looked down upon?
(Well, except we have more of the nu-style "expose all ports to the Internet and protect them with an HTML form and a q1w2e3 password, #yolo" corporate networks.)
It was a joke.
I see no downside to just using the hostname from the config file instead of trying to apply a few select options from the config, and non-standard ports are extremely common
It seems there is room to expand from checking Bash history to also other popular shells (eg `fish`).
https://github.com/byt3bl33d3r/DeathStar
already excludes most modems and iot. :(
probably need a rewrite in sh and dropbear
Even suggesting that for something like this in the readme is a red flag to me.
It's probably just a bad habit on the part of the author, but it may very well be intended to promote such unsafe practices with the intent to at least have the option to exploit it at some point later.
I’m not sure whether pressing the „fork” button and inspecting it in your local repository is “near impossible”.
There are many ways more competent/sane users who realize the danger can work around those.
My concern is that some percentage of users are likely to follow the method in the readme to the letter, without knowing or caring about the danger. Either the author knows this (if not-> incompetent, which is not likely), doesn't care (maybe it's mostly intended for black hack hacking).
Or it's actually a trap, where it's first presented as a useful tool, but where a phone home addon is injected at some point later, and able to collect massive numbers of keys before it's detected.
The tool is marketed as fileless. How are you going to run it on a system which has no writable space?
Obviously, but the howto in the readme does lay the groundwork for a huge security concern if some admins start to run it recurrently in that way, without reading the code every time.
> The tool is marketed as fileless.
Which is great if your purpose is indeed to use it for hacking, and you run it on machines that you've already compromised, not on your own.
For anyone else, I think it's vital to only run it from an instance where you can download it and examine the code every time there is a change. I would do a git pull for that, not a curl command. Git makes it easier to go through all changes every time you do a pull.