[Dshield] 0wnlng Windows machines

Stasiniewicz, Adam stasinia at msoe.edu
Tue Feb 27 01:44:41 GMT 2007

Not quite right.  In a MITM attack a host between the two end points is
impersonating each end point to the other.  For example, take the following

Joe User (A)  <->  Evil Guy (B)  <->  SSL Web Server (C)

So in the above example, A thinks B is C and C thinks B is A (hence MITM).
How this is accomplished is a discussion for another time.  Anyway, A will
begin an SSL connection with B while B will begin an SSL connection with C.
If there is no checking if the certificate is trusted, B could generate its
own cert (saying it was C) and present it to A when A connects.  Then,
because B is also connected to C, B can proxy all traffic from A to C.  In
the process monitoring usernames/passwords/etc in the clear.

But if a certificate is signed by a trusted CA the above is not possible.
Take the following model:

Joe User (A)  <->  Evil Guy (B)  <->  SSL Web Server (C)

Certificate Authority (D) 

D has signed C certificate certifying that C really is C.  A's manufacturer
or administrator has included D public certificate in the list of trusted
CAs.  Now when A connects to B, B has a certificate that says it is C, but
since it was not signed by D, A knows that it might be fake (and the user
will get a warning prompt).

It should also be noted; that they way the D identifies C is by DNS name.
This way the certificate issued to C is only good at identify it as C; it
cannot be used to identify itself as anyone else.

Hope that cleared things up,
Adam Stasiniewicz

-----Original Message-----
From: list-bounces at lists.dshield.org [mailto:list-bounces at lists.dshield.org]
On Behalf Of Tony Earnshaw
Sent: Monday, February 26, 2007 2:05 PM
To: General DShield Discussion List
Subject: Re: [Dshield] 0wnlng Windows machines

Darren Spruell wrote, on 26. feb 2007 15:37:

>> FWIW use https not for certified authentication, but purely to encrypt
>> all traffic between the site and the client; it is webmail, after all.
> Fair enough, however even the server authentication portion of SSL has
> a tie-in to the encryption portion. With encryption, a primary thing
> you're worried about is confidentiality of the data. Encryption alone
> won't keep your data secret from a third party if that third party can
> perform a man in the middle attack and intercept connections between
> the server and client. The server will happily encrypt data between
> itself and the attacker, and the client will gladly encrypt data
> between itself and the attacker, allowing the attacker to see the
> communication in cleartext. Therefore, your efforts to keep the
> communications secured fall apart. For this reason, validation of the
> server certificate is important to data confidentiality as well - the
> attack fails when the client tries to validate that it is about to
> carry on secure communications with the webmail server and the
> certificate fails to validate properly. (In theory; the effectiveness
> of this measure has a lot to do with the understanding of the client
> that they have a hijacked connection and shouldn't just click yes to
> continue anyway.)

Forgive me, I've read about Bob and Alice too; the only significance of 
the CA certificate that we issue (and that is what is the springing 
point of this thread) is to state who issues it and if that instance can 
be trusted.

It has (and neither has the data transmission) nothing to do with the 
encryption involved or its decryption, we are dealing with asymmetric 
encryption, in which anyone ("man in the middle") not in cognizance of 
the private key can go and hmmm ... fiddle hmmm ... with himself.


Tony Earnshaw
Email: tonni at hetnet dot nl

SANS 2007 March 29 - April 6 in San Diego, CA offers 52 Courses
taught by our top rated instructors plus a huge vendor tools expo.
Register Today! http://www.sans.org/info/2501 (BROCHURECODE: ISC)

More information about the list mailing list