RE: SSL MITM not on port 443

["Shenk, Jerry A" <jshenk () decommunications com>]

Have you ever done what you're trying to do on a "normal" SSL web
server?  My recommendation would be to set up a web server in your lab
with ssl set up.  Then make sure you can get your exploit working on
that.  If you can, then move the server to some port other than 443 and
see if you can still make your exploit work.  As I understand ettercap,
it does it's MITM by presenting its own certificate to the client in
hopes that the client will accept that certificate.  Then ettercap
establishes a connection to the end server just like Paros does.

You've also talked about using a "false certificate" - does this
application have a certificate on the client side?  Most SSL encrypted
sessions only have a certificate on the server side.

-----Original Message-----
From: listbounce () securityfocus com [mailto:listbounce () securityfocus com]
On Behalf Of christopher.riley () r-it at
Sent: Thursday, August 28, 2008 2:21 AM
To: rgill () arubanetworks com
Cc: pen-test () securityfocus com
Subject: RE: SSL MITM not on port 443

Unfortunately i've already tried to use Paros as a MITM proxy for the
connection. The application does complain about the certificate, as
you'd
expect. However I need to replace the normal Paros certificate with one
that is faked especially for the application (such as the ones created
by
Ettercap or Cain), however Paros or Burp suite refuse to use these
certificates for some reason. Webmitm accepts the certificate but
doesn't
seem to function for the connection, and Ettercap seems to ignore the
connection as it's not on port 443. I need to make sure that the
certificate authentication can't be fooled by a certificate with almost
the same information as the original. I guess a source code review is
the
only way to make sure.

Thanks for the feedback.





rgill () arubanetworks com@inet
27.08.2008 19:24

An
christopher.riley () r-it at, pen-test () securityfocus com
Kopie

Thema
RE: SSL MITM not on port 443







Try pointing the application to a MITM proxy like Paros
(http://www.parosproxy.org/index.shtml) or WebScarab
(http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project). Such
a proxy sits in the middle of the client application and the server and
presents its own certificate to both sides so it can MITM the connection
between the client and the server. You should be able to see all
communication clear text in the proxy. A security savvy client
application will throw a warning to indicate that it is being presented
with a ssl cert, it doesn't trust or recognize.

If the application accepts the MITM ssl cert presented by the proxy
without any warnings etc., it is vulnerable.


-Robbie


-----Original Message-----
From: listbounce () securityfocus com [mailto:listbounce () securityfocus com]
On Behalf Of christopher.riley () r-it at
Sent: Wednesday, August 27, 2008 4:33 AM
To: pen-test () securityfocus com
Subject: SSL MITM not on port 443

I've come across a problem in a pentest that I'm working on right now
that
I thought the members of the list might be able to assist me with.

I'm working with a propriatary software (written in C++) that
communicates
on a high port number using HTTPS. I'm trying to test to see if the
software can be fooled into accepting a false certificate and then
traffic
decoded into clear text.

So far I've tried Ettercap, webmitm and CAIN without much luck. The
closest I can get is Ettercap capturing the communication, however it
doesn't offer a forged certificate and all captured traffic is still
encrypted using the normal server certificate. Not  much of a MITM
attack.
I've confirmed that Ettercap works as advertised against a couple of
sites
in Internet Explorer and all seems to work normally.

Does anybody know of a way to force Ettercap to perform an SSL mitm even

though the port isn't associated with HTTPS ? or maybe you can suggest a

better tool for the job ? I can control where the application looks for
the server, so I can divert it through some kind of forwarding proxy if
needed ?

Thanks,

Chris Riley

----------------------------------------
Raiffeisen Informatik GmbH, Firmenbuchnr. 88239p, Handelsgericht Wien,
DVR 0486809, UID ATU 16351908

Der Austausch von Nachrichten mit oben angefuehrtem Absender via E-Mail
dient ausschliesslich Informationszwecken. Rechtsgeschaeftliche
Erklaerungen duerfen ueber dieses Medium nicht ausgetauscht werden.
Correspondence with above mentioned sender via e-mail is only for
information purposes. This medium may not be used for exchange of
legally-binding communications.
----------------------------------------


------------------------------------------------------------------------
This list is sponsored by: Cenzic

Top 5 Common Mistakes in
Securing Web Applications
Get 45 Min Video and PPT Slides

www.cenzic.com/landing/securityfocus/hackinar
------------------------------------------------------------------------




----------------------------------------
Raiffeisen Informatik GmbH, Firmenbuchnr. 88239p, Handelsgericht Wien,
DVR 0486809, UID ATU 16351908

Der Austausch von Nachrichten mit oben angefuehrtem Absender via E-Mail
dient ausschliesslich Informationszwecken. Rechtsgeschaeftliche
Erklaerungen duerfen ueber dieses Medium nicht ausgetauscht werden.
Correspondence with above mentioned sender via e-mail is only for
information purposes. This medium may not be used for exchange of
legally-binding communications.
----------------------------------------


------------------------------------------------------------------------
This list is sponsored by: Cenzic

Top 5 Common Mistakes in
Securing Web Applications
Get 45 Min Video and PPT Slides

www.cenzic.com/landing/securityfocus/hackinar
------------------------------------------------------------------------


**DISCLAIMER
This e-mail message and any files transmitted with it are intended for the use of the individual or entity to which 
they are addressed and may contain information that is privileged, proprietary and confidential. If you are not the 
intended recipient, you may not use, copy or disclose to anyone the message or any information contained in the 
message. If you have received this communication in error, please notify the sender and delete this e-mail message. The 
contents do not represent the opinion of D&E except to the extent that it relates to their official business.

------------------------------------------------------------------------
This list is sponsored by: Cenzic

Top 5 Common Mistakes in
Securing Web Applications
Get 45 Min Video and PPT Slides

www.cenzic.com/landing/securityfocus/hackinar
------------------------------------------------------------------------