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

Intercept public key authentication and put client in fake environment #14

Open
jtesta opened this issue Mar 28, 2018 · 6 comments
Open

Comments

@jtesta
Copy link
Owner

jtesta commented Mar 28, 2018

Public key authentication doesn't divulge any useful information to an attacker, hence a true MITM can't be done. However, it is possible to intercept the connection and drop the victim into a fake environment hosted on the attacker's machine. This would be difficult to trick humans with (since they would expect the target server to be a certain way, and would quickly notice the glaring differences), but automated client processes could leak lots of sensitive information.

For example, an automated client process may ignore the mismatched host key, log in with key authentication (which drops them into a fake environment--no interaction with the real server ever occurs), then immediately issue a sudo or su command and supply the root password (which we can log!). Of course, after that, the client would try to run programs/read files that don't exist, which would result in failure. However, the attacker can potentially observe this process, update their fake environment iteratively, and eventually provide the structure that the automated client expects, yielding more sensitive data.

This would be rather sneaky!

@kubrickfr
Copy link

Hi,

What happens at the moment if someone uses public key to log on a server? Does the connection still succeed? Do we still get the interactive / SFTP session log? (which is what I'm actually interested in)

Thanks.

@jtesta
Copy link
Owner Author

jtesta commented Sep 5, 2018

Sorry for the late response. I didn't notice this until now.

If someone uses a public key, then currently the connection will fail. I made a note in the TODO list of the README that a mechanism should be added to automatically de-spoof pubkey-only connections. At the moment, the best thing to do would be keep an eye on the process and manually remove IPs from arpspoof/ettercap if you notice the connections failing for them.

@antnks
Copy link

antnks commented Dec 20, 2018

+1 for public key support and fake environment!

Repository owner deleted a comment from manfred-kaiser Jun 11, 2020
@littlebear2
Copy link

littlebear2 commented Sep 13, 2021

When I tried your pubkey_auth branch, this breaks password authentication.

I have 2 users. One is allowed to login with public key and the other can only login with a password.

When enabling public key authentication, both users are forced to login with publickey authentication.

Why is password authentication broken, when public key is enabled?

I read on another page that this should be possible: https://pypi.org/project/ssh-mitm/

I'm not using ubuntu, so I can not use your prebuilt snap 😞

@jtesta
Copy link
Owner Author

jtesta commented Sep 13, 2021 via email

@littlebear2
Copy link

Thanks for the response 👍 I will try the other project

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

No branches or pull requests

4 participants