Re: Checkpoint smart defance as IPS

[Shreyas Zare <shreyas () secfence com>]

Hi Craig,

I dont know whats missing, may be the issue is not clear. I will write
the claim you made in below paragraph:

You claim that its possible to Man In The Middle (MITM) attack on
*any* SSL/TLS communication without tampering anything on the client
side and that SSL/TLS is, and can, be intercepted for *any* possible
website a client visits on-the-fly.

Now, I will create a scenario which will make things clear:

1. I, with my personal laptop will connect to any VPN that you provide.

2. I would use my default web browser (Firefox v3.6.3 with no-script
addon) and would visit *any* HTTPS website I wish and login with my
credentials.

3. This VPN that I would dial, can/will be in your control; you can
route the traffic anyway to the internet (this part is quite easy to
achieve) and sniff the data and do whatever you can do to intercept
and "decrypt" the traffic.

4. I will use the DNS server which the VPN connection provided.

5. I would visit only one website, login then disconnect the VPN.
There will be only one attempt for me to login to that website. I
would myself capture the traffic that went through VPN with wireshark
for comparison and post it.

6. You would then use whatever means possible to get my credentials
and you can freely post it publicly on the list or on any other forum.

7. And since, as you claim, this will happen on-the-fly, you will have
to post the credentials within 24hrs on the list (24hrs is too
generous anyways).


This exercise would clear up things that you claim and surely the
entire mailing list would like to know how this thing is really
technically possible and how you achieved it.

Regards,


Shreyas Zare

Sr. Information Security Researcher
Secfence Technologies
www.secfence.com




On Thu, Jun 3, 2010 at 1:08 PM, Craig S. Wright
<craig.wright () information-defense com> wrote:
> "DNSSEC is not related to SSL/TLS security"
> SSL security is based on DNS. DNSSEC is security for DNS.
>
> " Again I would say my point: you *cannot* do MITM on a website if you don't
> have private key for the certificate on that website."
> Really? I have devices doing this at clients right now.
>
> " If you are NSA, you can crack the encryption with brute force and that too
> will take quite some time."
> BS
>
> "Again for god sake, this is social engineering! there is no way this
> can be used to MITM an existing SSL website. Well, if you can get a
> cert from any of the 264+ CA for citibank, that would be fault of the
> CA and not SSL/TLS or PKI, plus that would involve legalities. This
> compromise is in theory possible, but again you need access to a CA
> and SSL/TLS protocol is still not broken (its working as designed)"
>
> No it is not, the certs are already in the browser. I can get a .com cert
> from several CAs.
>
> " not possible for any guy to obtain the same "
> Really? I have setup a number of RAs.
>
> " Lastly, why on earth would people use electronic banking if what you
> claim is true and so easy to carry out?"
>
> As the issue is not one people care about. The banks have the risk. DNS and
> routing are the weak points. Perception.
>
> Well the simple thing here is I do this for clients from time to time. I am
> happy to know I am doing the impossible.
>
> Encrypted is NOT secure. It is private. These are not the same thing. If you
> actually believe that SSL is security, then I feel sorry for your clients.
>
> Regards,
> ...
> Dr. Craig S Wright GSE-Malware, GSE-Compliance, LLM, & ...
> Information Defense Pty Ltd
>
>
>
> -----Original Message-----
> From: Shreyas Zare [mailto:shreyas () secfence com]
> Sent: Thursday, 3 June 2010 4:56 PM
> To: craig.wright () information-defense com
> Cc: security-basics () securityfocus com
> Subject: Re: Checkpoint smart defance as IPS
>
> Hi Craig,
>
> I disagree with you my friend. And the points you are using to defend
> your previous claim are totally different and thus not valid for the
> argument.
>
> Firstly, you claim that SSL/TLS can be intercepted and MITM is
> possible (and effectively protocol is broken). And now you defend it
> citing bad implementation of SSL/TLS in browsers and social
> engineering. Most of your points (like phishing, fake domains etc) are
> social engineering and not MITM or interception for that matter.
>
> SSL/TLS is not to protect user from his/her stupidity. SSL/TLS do
> provide a secure channel to a site and you cannot just sniff the
> traffic and decrypt it (as you suggest).
>
> DNSSEC is not related to SSL/TLS security. Clients just blindly trust
> their ISP DNS server. DNSSEC is to make faking/spoofing a DNS reply
> really difficult and it will be done using digital signatures. And
> surely, you can attack DNSSEC too with social engineering or making
> the client machine trust a fake CA that you control then sign a fake
> reply with your private key.
>
> Again I would say my point: you *cannot* do MITM on a website if you
> don't have private key for the certificate on that website. However,
> you can be a CA and fake a certificate on the fly on your gateway,
> that too only when the client trusts the CA in the first place. If you
> are NSA, you can crack the encryption with brute force and that too
> will take quite some time.
>
> And ...
>
> On Thu, Jun 3, 2010 at 4:45 AM, Craig S. Wright
> <craig.wright () information-defense com> wrote:
> > Hello,
> > I suggest that you learn to reference more than simply Wiki.
>
> I suggested you wiki to get the basics. and wikipedia for that matter
> is really good. You claimed that browser only checks for domain name
> and totally didn't know about the handshake which involves private key
> of the website.
>
>
>
> > "If it was possible as you claimed, the protocol will be totally broken
> and
> > it will be front page news article."
> > I suggest you keep up. This is why TLS was introduced (which also has
> flaws)
> > - which is still not used correctly either. But read on for something that
> > matters.
> http://blog.washingtonpost.com/securityfix/2006/02/the_new_face_of_phishing_
> > 1.html
>
> Phishing is not MITM, its social engineering.
>
>
>
> > PS. A complete compromise of the CAs and DNS would not likely make a front
> > page article. Most people do not care and it is not something that sells
> > papers.
>
> A persons net-banking account can be intercepted while he and his bank
> wont care? great!
>
>
>
> > This is also why DNS and routing are important. What do you think DNSSEC
> is
> > really about?
>
> DNSSEC and SSL/TLS are different things. SSL/TLS use certificates to
> match domain that's true but, the handshake is done as client sends a
> random number encrypted with public key and the server which has the
> private key can *only* decrypt it.
>
>
>
>
> > SSL is about privacy, NOT security. It was NEVER about security.
>
> this is simply great!
>
>
>
>
> > How about I give you some real reading, something more than the online
> > golden book encyclopaedia that is Wikipedia...
>
> Thanks, I have done much more reading already.
>
>
>
>
> > Let's take a quote from Kurt Seifried:
> > "Even ignoring all these problems the simple fact is that SSL certificates
> > only identify the server to the user, they do not authenticate it. This is
> a
> > subtle but incredibly important difference. My online bank is at
> tdbank.ca,
> > td.ca on the other hand is owned by someone else and banktd.ca is still
> > free. I know for example that www.openssl.org is the "official" site for
> > OpenSSL, but what about www.openssl.de? Shouldn't that be the official
> site
> > for OpenSSL translated into German? Well it turns out that it isn't. Do
> you
> > trust every single root certificate in your webbrowser software? Have you
> > even heard of "IPS SERVIDORES" (ips.es), "Saunalahden Serveri CA"
> > (saunalahti.fi) or "SERVICIOS DE CERTIFICACION - A.N.C." (correo.com.uy)?
> I
> > sure as heck haven't."
> >
> > REMEMBER - ALL CERTIFICATE AUTHORITIES ARE EQUALLY TRUSTED!!!!!!!!!!!!!!!!
> >
> > I have to state this again...
> >
> > ALL CERTIFICATE AUTHORITIES ARE EQUALLY TRUSTED!!!!!!!!!!!!!!!!
> >
> > Do you think your users go and check the CA and ensure it is really the
> one
> > that the real site has used? If you think users do this, you have some
> > learning to do.
> >
> > If you actually believe that you cannot obtain a signed (from a CA in IE's
> > list) certificate for a MiTM device, you have not looked too hard.
> >
> > If you do not think this is a known issue, try reading some RFC's:
> > "[Browser vendors] and users must be careful when deciding which
> certificate
> > and certificate authorities are acceptable; a dishonest certificate
> > authority can do tremendous damage."
> > RFC 2246, The TLS Protocol 1.0
> >
> > The 264+ root CAs trusted by Microsoft, the 166 root CAs trusted by Apple,
> > and the 144 root CAs trusted by Firefox are capable of issuing
> certificates
> > for any website, in any country or top level domain.
> > See Ed Felten. "Web Certification Fail: Bad Assumptions Lead to Bad
> > Technology". Freedom To Tinker, February 23 2010.
> www.freedom-to-tinker.com/blog/felten/web-certification-fail-bad-assumptions
> > -lead-bad-technology.
>
>
> Again for god sake, this is social engineering! there is no way this
> can be used to MITM an existing SSL website. Well, if you can get a
> cert from any of the 264+ CA for citibank, that would be fault of the
> CA and not SSL/TLS or PKI, plus that would involve legalities. This
> compromise is in theory possible, but again you need access to a CA
> and SSL/TLS protocol is still not broken (its working as designed)
>
>
>
>
> > Next, "'Packet Forensics' devices are designed to be inserted-into and
> > removed-from busy networks without causing any noticeable interruption [.
> .
> > . ] This allows you to conditionally intercept web, e-mail, VoIP and other
> > traffic at-will, even while it remains protected inside an encrypted
> tunnel
> > on the wire. Using `man-in-the-middle' to intercept TLS or SSL is
> > essentially an attack against the underlying Diffie-Hellman cryptographic
> > key agreement protocol [. . . ]".
> > Packet Forensics. Export and Re-Export Requirements, 2009.
> > www.packetforensics.com/export.safe.
> >
> > So - the question is... have you removed all but the "trusted" CA's from
> > your users browsers? I doubt it. If you have, you also need to do this
> EACH
> > and EVERY time that IE updates.
>
> Again you need access to a CA, which a government like US can do for
> sure. And its again not possible for any guy to obtain the same.
>
>
>
>
> > Next, have a read of more than this forum. Try the TLS list from the IETF:
> > http://www.ietf.org/mail-archive/web/tls/current/msg03928.html
>
> From the link:
> "The problem:  when Microsoft IIS is configured to request a client
> certificate after having received the request, then it WILL perform
> an unauthenticated request!  Sending the reply back only to the
> authenticated client is a poor excuse for acting on an unauthenticated
> request."
>
> That is bad implementation of SSL, isn't it? and that too specific to
> a particular server. And in normal HTTPS scenario, client don't send a
> cert to server.
>
>
>
>
> > Even not paying for a certificate (which is the option for the scenario
> this
> > derived from), you can still attack SSL/TLS:
> > "...inject a chosen plaintext prefix into the encrypted data stream, often
> > without detection by either end of the connection. This is possible
> because
> > an "authentication gap" exists during the renegotiation process at which
> the
> > MitM may splice together disparate TLS connections in a completely
> > standards-compliant way."
> > See
> http://extendedsubset.com/wp-uploads/2009/11/renegotiating_tls_20091104_pub.
> > zip
> >
> > Finally, have you ever thought of a zero bit negotiated key. SSL with
> 0-bit
> > encryption. This can be done using a 128 bit certificate. The client to
> the
> > IPS is clear text, but looks to the browser as being encrypted.
>
>
> Again an example of bad implementation in application.
>
>
>
>
> > Research means more than wiki. If you use a title of researcher, it is
> > something that you should try to do.
>
> Thanks for the tip. But, one really needs to read basics first not
> matter from wiki or some another source.
>
>
>
> > Regards,
> > ...
> > Dr. Craig S Wright GSE-Malware, GSE-Compliance, LLM, & ...
> > Information Defense Pty Ltd
>
>
>
> Lastly, why on earth would people use electronic banking if what you
> claim is true and so easy to carry out? While there are many attacks
> possible in theory, implementing them practically is very difficult
> indeed. And such attack will depend on bad implementation issues or
> social engineering. Still, doing a attack based on social engineering
> is quite viable option but, the success rate of such attack would vary
> with the target population.
>
>
> Regards,
>
> Shreyas Zare
>
> Sr. Information Security Researcher
> Secfence Technologies
> www.secfence.com

------------------------------------------------------------------------
Securing Apache Web Server with thawte Digital Certificate
In this guide we examine the importance of Apache-SSL and who needs an SSL certificate.  We look at how SSL works, how 
it benefits your company and how your customers can tell if a site is secure. You will find out how to test, purchase, 
install and use a thawte Digital Certificate on your Apache web server. Throughout, best practices for set-up are 
highlighted to help you ensure efficient ongoing management of your encryption keys and digital certificates.

http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d1
------------------------------------------------------------------------