Aloha, Thad. To clarify this point about SSL and https:
> User B can type in https://siteC to go directly to > site C using SSL if site C supports SSL and user B > has personal knowledge of the correct FQDN for the > SSL server of site C -- in this case the MITM attack > fails, even though the MITM is still ITM, when the > MITM is unable to use cryptanalysis to break the SSL > encryption. The MITM is still ITM by virtue of the DNS hijacking. But, the MITM has no choice but to relay SSL packets unmodified to site C if the MITM wants to avoid being detected by user B. Only site C has a copy of the private key that corresponds to site C's encryption certificate (public key and server FQDN signed by CA) therefore only site C can satisfy user B's client and authenticate as site C. The MITM still proxies user B's access to site C, but without the ability to eavesdrop or masquerade so there is no damage done. Aloha & Mahalo, Jason Coombs [EMAIL PROTECTED] -----Original Message----- From: Jason Coombs [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 24, 2002 9:56 AM To: Thad Horak Cc: [EMAIL PROTECTED] Subject: RE: Session Hijacking Aloha, Thad. Yes. One technique is for attacker A to hijack DNS of site C such that the DNS hijacking impacts user B's name resolution of site C's domain. Attacker A is able to direct user B to masquerading server D which then functions as an unauthorized proxy for user B's access to site C. DNSSEC will make it harder to hijack DNS of site C when deployed widely (see http://www.ietf.org/html.charters/dnsext-charter.html) User B can type in https://siteC to go directly to site C using SSL if site C supports SSL and user B has personal knowledge of the correct FQDN for the SSL server of site C -- in this case the MITM attack fails, even though the MITM is still ITM, when the MITM is unable to use cryptanalysis to break the SSL encryption. If, however, user B types in http://siteC and has no personal knowledge of the FQDN of site C's SSL server then attacker A is able to fool user B into clicking on a hyperlink to SSL server D, which obviously uses an FQDN other than site C's but user B sees exactly what they expect to see in the way of a user interface and Web application services because server D makes an SSL connection to the authentic site C and plays the SSL-secured MITM. Good luck. We all need it. Jason Coombs [EMAIL PROTECTED] -----Original Message----- From: Thad Horak [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 23, 2002 1:08 PM To: [EMAIL PROTECTED] Subject: Session Hijacking All, A peer recently told me that the a network topology consisting of internal servers routing traffic through a firewall to the internet was a security hole since the session could either be hijacked or be hacked using a MITM technique. Example: Internal_server --> PIX NAT --> Internet partner I understand the fundamentals behind hijacking and MITM attacks, but it would seem to me that the only way that an attacker could pull of this type of an attack would be to compromise a host on the same switch/hub that the firewall is on. Is this this a correct assumption? Can attacker A in California hijack User B in Ohio shopping on Site C in Florida without compromising some key piece of equipment in between B and C first? My apologies for the long winded question. Thanks in advance for your insight. Thad __________________________________________________ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/
