exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

ssh.mitm.v1.txt

ssh.mitm.v1.txt
Posted Jul 24, 2002
Authored by Robert

All versions of SSH and OpenSSH which use computability mode 1.99 are vulnerable to a mitm attack without the duplicate key warning because the attacker can force protocol version 1, so the only warning the user gets asks him if he wants to add the new key. Still suspicious, but less so.

tags | protocol
SHA-256 | 98d4d1bb0a58e04cbf0d8839a3f693e46ecfcac7a397eef7bae93eb8985ab548

ssh.mitm.v1.txt

Change Mirror Download

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

SSH Protocol Weakness Advisory
Monday, July 22 2002
- - rtm

OK, here it is guys... I saw this today when I was looking at the newest issue of phrack (59)
and I discovered that an old little technique of SSH man in the middle attacks I had been working
on was now part of a Phrack article....
Luckily, source code hadn't been disclosed yet, and neither will mine. I just wanted to get this
issue out in the open so people could secure themselves while they can.
Remember, that the ssh daemon

So far, all vendors are vulnerable to this little trick, including commercial based SSH and OpenSSH.
http://www.ssh.com
http://www.openssh.com

You can find more details about the attack at http://www.sekurityfocus.com/phrack59/

Basically, ssh daemons advertise one of two major versions, depending on what is supported by the
software /configuration files, for SSH protocol version 1, or 2. Compatibility mode is enabled with a
version of 1.99. It is servers which advertise this compatibility mode of 1.99 which are vulnerable to
the attack. Servers in compatability mode have both protocols 1 and 2 enabled.
If the client has a key enabled for say, only SSH protocol 1 or 2, the malicious interloper, "Mallory,"
using ssh mitm arp techniques which are available in say, ettercap or dsniff, can advertise the opposite
protocol in the fake sshd version string used in the banner handshake.
If a client has only used say, SSH 1 authentication in the past, it will not contain a SSH2 key, so
no "Host Identification has changed" message will be present when the fake server advertises its public
host key. The targeted victim will only see a "KEY NOT PRESENT" prompt and will be asked if they want
to add the key.
Obviously, this removes some of the fear paranoid users would feel when facing a real mitm attack.
Remember, this is not a direct vulnerability in the SSH 1 or 2 protocols, but rather a slight trick that
can be abused.


POTENTIAL SOLUTIONS
- -------------------
Client-Based:
Check known_hosts and known_hosts2 in your ~/.ssh directory, and check to see which keys you use for each host.
If you only use ssh1, force the ssh protocol to protocol 1, by specifying the -1 option.
Or if you use ssh2, force the ssh protocol 2 with the -2 option.
If you receive a hostkey change identification, you know something must be up!

Server-Based:
Disable sshd? <- Isn't this always the best security approach, especially now? :)
Really, there isn't anything to do except mail users and tell them which protocol to force, and to ensure
that strict host key checking is always on!

I guess we'll have to wait for the vendors to release an inventive patch for this one...
Now, what I want to know is why somebody who works at SuSE has not been publishing these details openly!?!


Thanks
A concerned citizen,
- -Robert
-----BEGIN PGP SIGNATURE-----
Version: Hush 2.1
Note: This signature can be verified at https://www.hushtools.com

wl8EARECAB8FAj08fQcYHGF1dG80NTg1NDVAaHVzaG1haWwuY29tAAoJEN2oSjCxkGUr
ea8An09wB6B9xI7BM3ydj8v0atKOPOp8AKCII7jep+cFbx1pqNllqhHNhSovkw==
=wPYb
-----END PGP SIGNATURE-----


Communicate in total privacy.
Get your free encrypted email at https://www.hushmail.com/?l=2

Looking for a good deal on a domain name? http://www.hush.com/partners/offers.cgi?id=domainpeople

Login or Register to add favorites

File Archive:

March 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    16 Files
  • 2
    Mar 2nd
    0 Files
  • 3
    Mar 3rd
    0 Files
  • 4
    Mar 4th
    32 Files
  • 5
    Mar 5th
    28 Files
  • 6
    Mar 6th
    42 Files
  • 7
    Mar 7th
    17 Files
  • 8
    Mar 8th
    13 Files
  • 9
    Mar 9th
    0 Files
  • 10
    Mar 10th
    0 Files
  • 11
    Mar 11th
    15 Files
  • 12
    Mar 12th
    19 Files
  • 13
    Mar 13th
    21 Files
  • 14
    Mar 14th
    38 Files
  • 15
    Mar 15th
    15 Files
  • 16
    Mar 16th
    0 Files
  • 17
    Mar 17th
    0 Files
  • 18
    Mar 18th
    10 Files
  • 19
    Mar 19th
    32 Files
  • 20
    Mar 20th
    46 Files
  • 21
    Mar 21st
    16 Files
  • 22
    Mar 22nd
    13 Files
  • 23
    Mar 23rd
    0 Files
  • 24
    Mar 24th
    0 Files
  • 25
    Mar 25th
    12 Files
  • 26
    Mar 26th
    31 Files
  • 27
    Mar 27th
    19 Files
  • 28
    Mar 28th
    42 Files
  • 29
    Mar 29th
    0 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close