Client cannot create ssh session after aprspoof attack.

[sakas23]

Hello jtesta.

I trying to use this tool in a local enviroment.

i have installed it successfully and then i run start.sh and afterwards i run a arpspoof attack.

The problem tha i have is that when i try to connect to the ssh server from the victim, it shows this message.

Any help is appreciated.

Thanks in advance.

[jtesta]

Looks like your SSH client has the StrictHostKeyChecking option set. That causes it to immediately kill the connection without allowing the user to accept the new (spoofed) hostkey.

Set StrictHostKeyChecking to "no" and try again. After accepting the new hostkey, the MITM should work.

[sakas23]

Hello jtesta.

Thanks for your instant reply.

Do you have an idea how to disable this option in a windows 10 machine ?

Or this option is to be changed in the server's conf file?

Thanks in advance.

[jtesta]

The option is controlled in the ssh_config file. I'm not sure where that lives on Windows 10, but you can try searching the filesystem.

On 2/18/20 10:44 AM, sakas23 wrote:

Hello jtesta.

Thanks for your instant reply.

Do you have an idea how to disable this option in a windows 10 machine ?

Thanks in advance.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/jtesta/ssh-mitm/issues/24?email_source=notifications&email_token=AAWYA63S6GJ7ZLCDKL3H3DDRDP64RA5CNFSM4KXGPRIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMCO7WQ#issuecomment-587526106, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAWYA62OIZ66Q3GJ4EUENV3RDP64RANCNFSM4KXGPRIA.

-- Joseph S. Testa II Founder & Principal Security Consultant Positron Security

[sakas23]

The option is controlled in the ssh_config file. I'm not sure where that lives on Windows 10, but you can try searching the filesystem. … On 2/18/20 10:44 AM, sakas23 wrote: Hello jtesta. Thanks for your instant reply. Do you have an idea how to disable this option in a windows 10 machine ? Thanks in advance. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#24?email_source=notifications&email_token=AAWYA63S6GJ7ZLCDKL3H3DDRDP64RA5CNFSM4KXGPRIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMCO7WQ#issuecomment-587526106>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAWYA62OIZ66Q3GJ4EUENV3RDP64RANCNFSM4KXGPRIA. -- Joseph S. Testa II Founder & Principal Security Consultant Positron Security

So the configuration must be done in the client right?

[jtesta]

On 2/18/20 11:09 AM, sakas23 wrote:

So the configuration must be done in the client right?

Yep.

[sakas23]

Hello jtesta,

Finally i managed to make it work.

I will use this tool as part of my project that i have.

Therefore, i would like to ask you some technical details, how it works, the philosophy of the program, etc..

I saw the code in the start.sh file, but i would like appreciate it if you could explain it a little bit.

Thanks in advance.

[jtesta]

Glad to hear that it works now!

Here's an overview of how it works: the project is a patch to OpenSSH. The rationale was that, since OpenSSH has maximum compatibility with clients (since its essentially the standard server implementation), it would be best to start with that. I added code to accept all password authentication, and replay it to the original destination server while logging everything in between. Simple concept, but took a long time to get working!

If you have any other specific questions, please let me know!

[sakas23]

Hi jtesta. Thanks for the reply.

So about the procedure, when we run the start.sh script, what is happening in the background in terms of the keys/fingerprints that are used? Because iam a little bit confused how it works.

And then with the arpspoof attack, the attacker redirects the login request to the server? How it works?

Please iam very interested in learning how this tool rly works!

Thank you in advance again

[jtesta]

When the user runs start.sh, the sshd_mitm executable listens on port 2222. The iptables tool is also used to re-direct all TCP port 22 traffic to localhost:2222. Hence, any TCP port 22 traffic intercepted while ARP spoofing ends up going to localhost:2222 instead of its original destination.

When any connection to port 22 is intercepted, the sshd_mitm executable will present the client with its own unique host key. Obviously, this will not match what the user's client is expecting, so the user's client will complain. Most users will (unfortunately) ignore this warning and continue on to enter their password. At that point, sshd_mitm receives the password, accepts the connection without any validation (it just assumes the password is correct), then launches its own ssh client to the original destination. That ssh client is given the original username and captured password. The sshd_mitm executable will then route all input & output back and forth between the victim and the original destination, all while logging everything to disk.

[sakas23]

Thank you for further explaining your tool.

Really appreciated.

So when the client types the credentials, those are going through the network in plaintext?

How the attacker manages to capture them?

And something else if you could help me.

How the public key authetication method resolves this attack?

And again rly thanks for explaining.

[jtesta]

When the victim enters their password, it is encrypted and sent to the sshd_mitm server. Since the password was encrypted to the hostkey controlled by sshd_mitm, then sshd_mitm also has the private key to decrypt the password. Therefore, the plaintext password is obtained.

The reason that this attack works against password authentication is because plaintext passwords can be replayed to the original destiination. However, in public key authentication, the attacker would not capture any useful data that can be replayed. Replaying the same data to the original destination would always result in failure. If you want to learn more, there are probably some tutorials around that explain in more detail how public key authentication works, and why a man-in-the-middle doesn't capture anything useful.

[sakas23]

So the client tries to login with the password, encrypted with the host key provided by the attacker, the attacker decrypts it and then it forwards it to the server unecrypted? And then receives the reply from the server and forwards it back to the client?

I dont know iam a little bit confused.

Please bare with me . :(

[jtesta]

You're mostly correct. The attacker re-encrypts the password to the original destination to establish the other half of the SSH connection. Then the attacker has two SSH sessions: one with the victim, and one with the original destination. It receives data from either end, decrypts it with the proper key, logs it, then re-encrypts it to the other side.

[sakas23]

And when the attacker sends the encrypted credentials, how does the server decrypts the credentials?

I mean that because the attacker has his onw host and private key. Or i misunderstood again??

[jtesta]

Yes. Anyone can generate their own public & private key. So the sshd_mitm server does that to create their own host key. The victim's ssh client encrypts the password to the sshd_mitm's public key, so the attacker can decrypt it.

Encryption has no meaning when you don't know the identity of who you're communicating with!

On 2/23/20 1:59 PM, sakas23 wrote:

And when the attacker sends the encrypted credentials, how does the server decrypts the credentials?

I mean that because the attacker has his onw host and private key. Or i misunderstood again??

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/jtesta/ssh-mitm/issues/24?email_source=notifications&email_token=AAWYA62UM7RNWBOE7BJFINTRELBQ5A5CNFSM4KXGPRIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMWEJTQ#issuecomment-590103758, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAWYA6ZEFJ6A3UMMS7BL5VDRELBQ5ANCNFSM4KXGPRIA.

-- Joseph S. Testa II Founder & Principal Security Consultant Positron Security

[sakas23]

Yeah and after the attacker decrypts the credentials from the client, what is happening bewteen the attacker and server?

Thats where iam confused.

[jtesta]

sshd_mitm simply runs "ssh username@original_destination", gives the ssh client the password to complete the connection, then routes all input and output back to the victim.

On 2/23/20 4:53 PM, sakas23 wrote:

Yeah and after the attacker decrypts the credentials from the client, what is happening bewteen the attacker and server?

Thats where iam confused.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/jtesta/ssh-mitm/issues/24?email_source=notifications&email_token=AAWYA6YHUOZYIRADUZOKLEDRELV4VA5CNFSM4KXGPRIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMWIN5I#issuecomment-590120693, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAWYA6YMCOVOSELMFR4SAS3RELV4VANCNFSM4KXGPRIA.

-- Joseph S. Testa II Founder & Principal Security Consultant Positron Security

[sakas23]

Ok now i think i understood it.

The attacker just tries to login with the credentials just received and decrypted, and if successfull, he retoures the traffic between the client and server.

And when the ssh-mitm server creates an ssh client session, he accepts the fingerprint given by the server and then uses the credentials to login right?

[jtesta]

That's correct.

On 2/23/20 5:10 PM, sakas23 wrote:

Ok now i think i understood it.

The attacker just tries to login with the credentials just received and decrypted, and if successfull, he retoures the traffic between the client and server.

And when the ssh-mitm server creates an ssh client session, he accepts the fingerprint given by the server and then uses the credentials to login right?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/jtesta/ssh-mitm/issues/24?email_source=notifications&email_token=AAWYA66MOGEXN5P3GN4BT5DRELX4NA5CNFSM4KXGPRIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMWI2CA#issuecomment-590122248, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAWYA66YBC6ORNASRNJKXU3RELX4NANCNFSM4KXGPRIA.

-- Joseph S. Testa II Founder & Principal Security Consultant Positron Security

[sakas23]

jtesta rly thank you for spending time answering my questions.

Rly appreciated.

[jtesta]

Sure thing!

On 2/23/20 6:45 PM, sakas23 wrote:

jtesta rly thank you for spending time answering my questions.

Rly appreciated.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/jtesta/ssh-mitm/issues/24?email_source=notifications&email_token=AAWYA637L2J3HLJNMQW4AITREMDBRA5CNFSM4KXGPRIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMWK54A#issuecomment-590130928, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAWYA64FVMCOMJIVHNWUY7DREMDBRANCNFSM4KXGPRIA.

-- Joseph S. Testa II Founder & Principal Security Consultant Positron Security

[sakas23]

Hello jesta.

Hope you are doing great.

I would like to ask you something else again. :)

About the attack, the ssh_ mitm server what kind of host key-pair does it use? (ECDSA, DSA,RSA or Ed25519)

Thanks in advance.

[jtesta]

I think it might use all of them to maximize compatibility with the victim's client.

On 3/1/20 7:42 PM, sakas23 wrote:

Hello jesta.

Hope you are doing great.

I would like to ask you something else again. :)

About the attack, the ssh_ mitm server what kind of host key-pair does it use? (ECDSA, DSA,RSA or Ed25519)

Thanks in advance.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/jtesta/ssh-mitm/issues/24?email_source=notifications&email_token=AAWYA645XBMBP6WVSVKU6QDRFL6G7A5CNFSM4KXGPRIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENNRVEY#issuecomment-593173139, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAWYA65J5IN2NBR76HK3XWTRFL6G7ANCNFSM4KXGPRIA.

-- Joseph S. Testa II Founder & Principal Security Consultant Positron Security

[sakas23]

Hello jtesta.

Thanks for your answer.

Is there any way that it can be changed to ECDSA? Because when the strict checking is enabled, it says that the key that the mimt sends is ED25519.

And one more thing.

I tried to monitor the traffic while the attack is happening and i noticed that there are no packets going from the attacker to the client and vise versa. I mean we should see some traffic right?

Thanks in advance.

[jtesta]

It could, in theory be configured to only use one host key type, but why would the user want that? The only reason I can think of is if the target servers all use one type; a perceptive victim then wouldn't notice anything out of the ordinary. However, I think this scenario is pretty rare.

If you really wanted to change it, though, look in the /home/ssh-mitm directory for the server configuration file (offhand, I don't know what its path is). You can manually edit it and disable any host key types you don't want.

Where were you monitoring traffic from? The MITM machine? If so, you may not be seeing it because the kernel doesn't pass the packets up to the sniffing application. The iptables routing rules might interfere with it.

On 3/2/20 5:49 PM, sakas23 wrote:

Hello jtesta.

Thanks for your answer.

Is there any way that it can be changed to ECDSA? Because when the strict checking is enabled, it says that the key that the mimt sends is ED25519.

And one more thing.

I tried to monitor the traffic while the attack is happening and i noticed that there are no packets going from the attacker to the client and vise versa. I mean we should see some traffic right?

Thanks in advance.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/jtesta/ssh-mitm/issues/24?email_source=notifications&email_token=AAWYA64YQ7GTQ2FMGHIRMNDRFQZWFA5CNFSM4KXGPRIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENRJOFQ#issuecomment-593663766, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAWYA62T4D2AN2XZZBVKHLLRFQZWFANCNFSM4KXGPRIA.

-- Joseph S. Testa II Founder & Principal Security Consultant Positron Security

[sakas23]

Yes i run wireshark from the attacker's machine. If i run wireshark from another machine, should i be able to see them or again it will not work?

[jtesta]

In a switched network, you can't sniff traffic on other ports without ARP spoofing. But if you do that to the MITM machine (which is already ARP spoofing the client and destination/gateway), you'll break the network connection for the MITM machine and the attack will fail.

Optionally, if you have a managed switch, you could enable port mirroring to copy all the traffic from the MITM device's port; that'll let you sniff the MITM machine's traffic without breaking its connectivity.

There also might be something else for you to change on the MITM's kernel in order to intercept packets, but I haven't ever done this.

On 3/2/20 6:22 PM, sakas23 wrote:

Yes i run wireshark from the attacker's machine. If i run wireshark from another machine, should i be able to see them or again it will not work?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/jtesta/ssh-mitm/issues/24?email_source=notifications&email_token=AAWYA6YPJN7AJYBX42VIIELRFQ5VBA5CNFSM4KXGPRIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENRMFKI#issuecomment-593674921, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAWYA6YKN3MPYWLR2QJL24LRFQ5VBANCNFSM4KXGPRIA.

-- Joseph S. Testa II Founder & Principal Security Consultant Positron Security

[sakas23]

jtesta again i have to thank you for answering my questions and baring my efforts to learn. :)

[jtesta]

Sure, no problem!

On 3/2/20 6:29 PM, sakas23 wrote:

jtesta again i have to thank you for answering my questions and baring my efforts to learn. :)

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/jtesta/ssh-mitm/issues/24?email_source=notifications&email_token=AAWYA665PGR32I7XRCFHJO3RFQ6PJA5CNFSM4KXGPRIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENRMVDA#issuecomment-593676940, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAWYA65GCPASKB23UII57OTRFQ6PJANCNFSM4KXGPRIA.

-- Joseph S. Testa II Founder & Principal Security Consultant Positron Security

[sakas23]

Hello jtesta.

I would like to ask you something again, because i got confused.

When the client tries to connect to the SSH server, then diffie helman key exchange is taking place and then they will exchange encrypted data using a session key created by the key exchange process.

So the host public and private keys are eventually will be used only for signing packets?

[jtesta]

Yes, the host key is only used to sign the DH public key, which is generated and rotated automatically.

On 3/3/20 8:02 AM, sakas23 wrote:

Hello jtesta.

I would like to ask you something again, because i got confused.

When the client tries to connect to the SSH server, then diffie helman key exchange is taking place and then they will exchange encrypted data using a session key created by the key exchange process.

So the host public and private keys are eventually will be used only for signing packets?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/jtesta/ssh-mitm/issues/24?email_source=notifications&email_token=AAWYA62ZTOEK7UKM5AYGR73RFT5UVA5CNFSM4KXGPRIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENTMSJA#issuecomment-593938724, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAWYA62WC4ID43EHDOVKUJ3RFT5UVANCNFSM4KXGPRIA.

-- Joseph S. Testa II Founder & Principal Security Consultant Positron Security

[sakas23]

Thank you jtesta. Because i rly want to understand how SSH works and i read some things and i wanted to share with you my concerns.