Re: authentication method shell variable?
--- Benjamin Donnachie [EMAIL PROTECTED] wrote: Jaqui Greenlees wrote: In a recent discussion about secure ssh use the idea of having ssh export the authentication method as a shll variable. The idea being to limit su access to only those who have used a public / private key pair for authentication. Easy... Compile sshd with the match keyword patch (http://bugzilla.mindrot.org/show_bug.cgi?id=1180), and use it to ensure that members of the admin group can only log in using public/private key authentication. Also make these users a member of the wheel group, and ensure that only they can su - check out /etc/pam.d/su. For example, in /etc/ssh/sshd_config add: Match Group admins PubkeyAuthentication yes PasswordAuthentication no ChallengeResponseAuthentication no In /etc/pam.d/su ensure the following is uncommented: # Uncomment the following line to require a user to be in the wheel group. auth required /lib/security/$ISA/pam_wheel.so use_uid I use this method to ensure that admins can only log in using public/private keys and have access to perform admin functions while (hopefully) ensuring that normal users cannot mess about. This also has the advantage that if any user uploads their own keys to ~/.ssh that they will not be able to gain admin rights!!! Ben Thanks Ben, that is exactly what I was looking for. Jaqui __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Need some education: Man-in-the-Middle Attacks
The fact that SSH tells you the fingerprint has changes. If the user is dumb enough to pass by it, and don't care, then he deserves to be Hijacked. On 8/31/06, Christ, Bryan [EMAIL PROTECTED] wrote: But if Eve is later challenged to prove her identity (that she must now maintain the illusion of being Alice), what prevents Eve from passing the challenge on to the real Alice, getting valid results, and then passing them back to Bob? On Thu, 2006-08-31 at 10:01 +0400, Eygene Ryabinkin wrote: Bryan, I was looking at the diagram on the URL listed below and contemplating how host fingerprinting prevents MITM attacks. http://www.vandyke.com/solutions/ssh_overview/ssh_overview_threats.html So my question is this... Given the illustration in the URL above, what prevents Eve from *first* contacting Alice to obtain a fingerprint which then gets passed to Bob on the first connection attempt? She can obtain it, but the fingerprint is closely related to the Alice's private key that Eve can not obtain easily. So there is no reason for Eve to pass Alice's fingerprint to Bob, because later she will not be able to prove to Bob that she has the corresponding private key and it will break the connection between Bob and Eve.
Re: Need some education: Man-in-the-Middle Attacks
Hi, That is why CAs (certification authorities) exists ! ! they are trusted third parties ! They mantain a database with the public keys of the entities they are confident of. The CA isues certificates signed by itself granting identities ! Cheers Christian 2006/8/30, Mark Senior [EMAIL PROTECTED]: On 8/29/06, Christ, Bryan wrote: All, Please pardon my naivete. I was looking at the diagram on the URL listed below and contemplating how host fingerprinting prevents MITM attacks. http://www.vandyke.com/solutions/ssh_overview/ssh_overview_threats.html So my question is this... Given the illustration in the URL above, what prevents Eve from *first* contacting Alice to obtain a fingerprint which then gets passed to Bob on the first connection attempt? The server passes the client its public key; the client generates a fingerprint of this public key, and verifies that it matches a known one from previous connections. Eve can pass Alice's public key to Bob, but she doesn't possess Alice's private key, so she has no way to interfere further with the communications (beyond tampering at a network level - introducing delay, dropping the connection, etc.) Only if Eve gets in the way of the very first connection attempt, can she pass her own public key off as Alice's, without Bob detecting it. On the first connection, he'd have to either trust what he sees, or verify the fingerprint offline somehow. On subsequent connections, the mismatch would be obvious.
Re: Need some education: Man-in-the-Middle Attacks
On Aug 31, 2006, at 2:02 PM, Christ, Bryan wrote: My question is this... What prevents Eve from passing along the challenge information to Alice? In other words, even though Eve does not have the private key, and therefore cannot decrypt, Alice does. Therefore Eve could send the information to Alice, get a valid response, and then Eve passes that response back to Bob. Bob still has no way of know that Eve is impersonating Alice and/or brokering messages. In this situation, Eve would only see the encrypted traffic, because Alice's responses are encrypted with Bob's public key. I'm far from an expert on this, but I'm pretty sure that public key encryption is used just to set up symmetric key encryption so this is a bit oversimplified. But the answer you are looking for is that if Eve simply passes the traffic back and forth, she won't have the private keys to decrypt the traffic--she just sees a garbled mess (of course Eve can do this if she wants--but at this point, she's just acting as a router). In order for Eve to decipher the traffic (and perform a meaningful attack), she has to impersonate Alice by connecting to each with a separate ssh session, in which case the keys don't match-- ssh keeps the fingerprints on file. If Alice tries a MITM attack on the very first time Bob connects to Alice, though, Bob won't have the fingerprint on file. If Bob is cautious, however, he will have gotten the fingerprint from Alice beforehand, using the telephone, PGP/GPG or some other means, and he would notice that the fingerprint of Eve's key doesn't match the fingerprint that Alice told him to expect. On Wed, 2006-08-30 at 15:58 -0600, Daniel DeLeo wrote: As far as I know, the fingerprint is based on the public key (or is the key? someone who knows more than I might want to clarify this) of the SSH server. Eve could pass on the fingerprint, but she would not have the private key, so data encrypted using the public key associated with that fingerprint could not be decrypted by Eve. Of course, nothing stops Eve from presenting her own key and hoping that the user doesn't check the fingerprints. On Aug 29, 2006, at 3:35 PM, Christ, Bryan wrote: All, Please pardon my naivete. I was looking at the diagram on the URL listed below and contemplating how host fingerprinting prevents MITM attacks. http://www.vandyke.com/solutions/ssh_overview/ ssh_overview_threats.html So my question is this... Given the illustration in the URL above, what prevents Eve from *first* contacting Alice to obtain a fingerprint which then gets passed to Bob on the first connection attempt?
RE: Need some education: Man-in-the-Middle Attacks
As part of the session setup, the server sends the public key to the client. The client then encrypts a random piece of data with the public key and sends it back to the server. The server uses the private key to decrypt it. This random data becomes the session key. In order for Eve to be able to MITM, she would have to be able to decrypt the data to get the session key. To do this, she would need Alice's private key. This is also the reason that Eve can't observe the contents of the session, even if she's been intercepting it since it's inception. This is slightly simplified. The sshd man page has a more complete description: http://www.hmug.org/man/8/sshd.php Seren -Original Message- From: Christ, Bryan [mailto:[EMAIL PROTECTED] Sent: Thursday, August 31, 2006 2:21 PM To: Seren Thompson Subject: RE: Need some education: Man-in-the-Middle Attacks Okay. I have followed that so far, but I still have a question. The presumption is that Bob and Alice have verified keys (via phone call, etc). But even then, what prevents Eve from passing host challenge information on to Bob. In other words, although Eve cannot decrypt the message, because she does not have the private key, Alice can because she does. Eve could simply pass the challenge information on to Alice, get a valid reply, and then Eve would pass that back to Bob. Bob would never know that Eve is impersonating Alice and brokering messages. On Thu, 2006-08-31 at 11:38 -0600, Seren Thompson wrote: This is true and why fingerprinting is useful. For the first connection attempt, Bob needs some way of verifying that the public key being presented is the same as Alice's public key. The way to do this is usually an out-of-band exchange where Bob calls Alice or meets with her and manually verifies that the fingerprint of her key matches the fingerprint of the key he's being presented. The purpose of a fingerprint is for this human-verification process, since it's easier to read than the full public key. This is the same reason SSL works. Most browser come with certificates preinstalled which is why you can verify that Verisign or some other authority has issued a web-site's ssl cert. Without the certs being preinstalled in the browser, you'd initially have to verify the authenticity of the certs for each website or signing authority, the way you (should) do for self-signed certs. -Original Message- From: Christ, Bryan [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 30, 2006 4:05 PM To: Mark Senior Cc: secureshell@securityfocus.com Subject: Re: Need some education: Man-in-the-Middle Attacks Only if Eve gets in the way of the very first connection attempt, can he pass her own public key off as Alice's, without Bob detecting it. This is exactly my concern. Isn't that scary? On Wed, 2006-08-30 at 12:52 -0600, Mark Senior wrote: On 8/29/06, Christ, Bryan wrote: All, Please pardon my naivete. I was looking at the diagram on the URL listed below and contemplating how host fingerprinting prevents MITM attacks. http://www.vandyke.com/solutions/ssh_overview/ssh_overview_threats.html So my question is this... Given the illustration in the URL above, what prevents Eve from *first* contacting Alice to obtain a fingerprint which then gets passed to Bob on the first connection attempt? The server passes the client its public key; the client generates a fingerprint of this public key, and verifies that it matches a known one from previous connections. Eve can pass Alice's public key to Bob, but she doesn't possess Alice's private key, so she has no way to interfere further with the communications (beyond tampering at a network level - introducing delay, dropping the connection, etc.) Only if Eve gets in the way of the very first connection attempt, can she pass her own public key off as Alice's, without Bob detecting it. On the first connection, he'd have to either trust what he sees, or verify the fingerprint offline somehow. On subsequent connections, the mismatch would be obvious.
Re: Need some education: Man-in-the-Middle Attacks
Bryan, But if Eve is later challenged to prove her identity (that she must now maintain the illusion of being Alice), what prevents Eve from passing the challenge on to the real Alice, getting valid results, and then passing them back to Bob? Eve (and Alice) is not challenged in any way. As ssh server (Alice _is_ ssh server and Eve is trying to pretend to be the ssh server) it only signs the so-called 'exchange hash' that is generated independently by Alice and Bob in the process of Diffie-Hellman exchange. And this hash is not transmitted over the wire. The following should help you to understand the things: an exempt from RFC4253 (http://www.ietf.org/rfc/rfc4253.txt), section 8: - 8. Diffie-Hellman Key Exchange The Diffie-Hellman (DH) key exchange provides a shared secret that cannot be determined by either party alone. The key exchange is combined with a signature with the host key to provide host authentication. This key exchange method provides explicit server authentication as defined in Section 7. The following steps are used to exchange a key. In this, C is the client; S is the server; p is a large safe prime; g is a generator for a subgroup of GF(p); q is the order of the subgroup; V_S is S's identification string; V_C is C's identification string; K_S is S's public host key; I_C is C's SSH_MSG_KEXINIT message and I_S is S's SSH_MSG_KEXINIT message that have been exchanged before this part begins. 1. C generates a random number x (1 x q) and computes e = g^x mod p. C sends e to S. 2. S generates a random number y (0 y q) and computes f = g^y mod p. S receives e. It computes K = e^y mod p, H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K) (these elements are encoded according to their types; see below), and signature s on H with its private host key. S sends (K_S || f || s) to C. The signing operation may involve a second hashing operation. 3. C verifies that K_S really is the host key for S (e.g., using certificates or a local database). C is also allowed to accept the key without verification; however, doing so will render the protocol insecure against active attacks (but may be desirable for practical reasons in the short term in many environments). C then computes K = f^x mod p, H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K), and verifies the signature s on H. Values of 'e' or 'f' that are not in the range [1, p-1] MUST NOT be sent or accepted by either side. If this condition is violated, the key exchange fails. This is implemented with the following messages. The hash algorithm for computing the exchange hash is defined by the method name, and is called HASH. The public key algorithm for signing is negotiated with the SSH_MSG_KEXINIT messages. First, the client sends the following: byte SSH_MSG_KEXDH_INIT mpint e The server then responds with the following: byte SSH_MSG_KEXDH_REPLY stringserver public host key and certificates (K_S) mpint f stringsignature of H stringV_C, the client's identification string (CR and LF excluded) stringV_S, the server's identification string (CR and LF excluded) stringI_C, the payload of the client's SSH_MSG_KEXINIT stringI_S, the payload of the server's SSH_MSG_KEXINIT stringK_S, the host key mpint e, exchange value sent by the client mpint f, exchange value sent by the server mpint K, the shared secret This value is called the exchange hash, and it is used to authenticate the key exchange. The exchange hash SHOULD be kept secret. The signature algorithm MUST be applied over H, not the original data. Most signature algorithms include hashing and additional padding (e.g., ssh-dss specifies SHA-1 hashing). In that case, the data is first hashed with HASH to compute H, and H is then hashed with SHA-1 as part of the signing operation. - So without the knowledge of either 'x' or 'y' Eve will not get the shared secret and will be excluded from the encrypted communications. Surely there is an Eve's option to solve the discrete logarithm problem for 'e' or 'f', but it is not so easy ;)) The only meaningful way for ordinary attacker to be the real MITM is to establish two SSH channels: Alice-Eve, Eve-Bob and proxy them. -- Eygene
Re: Need some education: Man-in-the-Middle Attacks
I think that the vulnerability which you pointed out is: (1) Usually Client(Bob) can check whether he is really connected to the Server(Alice) by checking the Server's host key with the data which Bob has in the known_host directory. But in the very first connection to the Server, the host key is not installed yet. So in this occation Eve might BE ABLE to IMPERSONATE Alice by sending Eve's host key. (2) If Eve pretends Alice Server, Bob would send his authentication information, which Eve receives and later she might use to login to Alice with Bob's account. Or Eve might forward the authentication information to Alice and send Eve's session key to both Bob and Alice. (1)'This MitM can be detected(avoided) in following ways: (a) System Administrator tells the fingerprint of Alice's host key to Bob (either offline or through another trusted channel) and asks him to check the fingerprint shown on the console together with the initial alert message. -It is virtually impossible to forge a public-private key pair with the SAME fingerprint as Alice's pubkey. (b) Bob's terminal be configured to reject all unknown hosts (StricHostKeyChecking Yesin the OpenSSH) and Alice's host key is supplied installed offline. However, (b) is rather burdensome and there are always sufficient number of careless users, who overlook the fingerprint mismatch. Therefore there is a chance for Eve to succeed in this attack. (2)'If Eve succeeds in pretending Alice's node, Bob's account is stolen and the session is open to eavesdrop -as long as PASSWORD authentication is used in version 1. Therefore SSH(version 1) using password authentication is by NO MEANS secure shell. I have demonstrated this kind of MitM attack in a lecture. However, authentication using either RSA or DSA can avoid stealing the authentication information, because the authentication information(secret key) is not sent to the Server. It might be possible to just forward the authentication information to Alice and send Eve's session key to A B, to make the session decryptable for EVE. But it is detected during the user authentication. Therefore there are still a number of obstacles to Eve's perfect crime, as long as RSA/DSA authentication is used. If password authentication is unavoidable, at least protocol 1 be disabled. It is because most (every?) MitM tools request protocol version 1 in establishing the session. I am not sure whether protocol 2 detects that the authentication process is eavesdropped. -- Masahito Gotaishi, Researcher R D Initiative, Chuo University 1-13-27 Kasuga, Bunkyo, Japan, 112-8551 DDI:03-3817-1621, FAX:03-3817-1606
