<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Recent Haxdoor Distribution Breaks SSL via Pharming</title>
	<atom:link href="http://www.mal-aware.org/2006/02/14/recent-haxdoor-distribution-breaks-ssl-via-pharming/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.mal-aware.org/2006/02/14/recent-haxdoor-distribution-breaks-ssl-via-pharming/</link>
	<description>Malicious Activity Awareness and Response</description>
	<pubDate>Thu, 20 Nov 2008 17:55:32 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5</generator>
		<item>
		<title>By: Lance James</title>
		<link>http://www.mal-aware.org/2006/02/14/recent-haxdoor-distribution-breaks-ssl-via-pharming/#comment-10</link>
		<dc:creator>Lance James</dc:creator>
		<pubDate>Sun, 19 Feb 2006 18:27:48 +0000</pubDate>
		<guid isPermaLink="false">http://www.mal-aware.org/2006/02/14/recent-haxdoor-distribution-breaks-ssl-via-pharming/#comment-10</guid>
		<description>I liked the explanation Robert, but there is something that you're under-playing here. The web browser is supposed to do it's job. The issue isn't that there is a trojan that can hook into IE and grab all traffic before it's encrypted, the issue is that it performed a successful man-in-the-middle by using a mixed-certificate technique to bypass the "EDUCATION" of SSL and the authentication. An example of this is here:

http://ip.securescience.net/exploits/ssl_mix.html

This demonstrates 4 frames 2 of which are SSL protected, and 2 which are not. No matter what browser we demonstrate this from, there are no warnings, pop-ups, or anything about non-secure pages, secure pages, and as we all know there is no Lock at the bottom. If you reverse the roll:

https://slam.securescience.com/threats/mixed.html

We see my Cert (which shouldn't alert, some browsers in mozilla still don't like Thawte), and we also have two frames with two separate SSL certs on the page. No warnings, and the SSL lock states that it's what the domain has. This is a problem with cross-user attacks as well as Trojans that Pharm because they easily fake "authentication" which is the intent of SSL for the home user, to authenticate the site and make sure they are there. The education around this for pharming is to use SSL to verify you are at the site. Well - in this report, this proves that not all cases will work.</description>
		<content:encoded><![CDATA[<p>I liked the explanation Robert, but there is something that you&#8217;re under-playing here. The web browser is supposed to do it&#8217;s job. The issue isn&#8217;t that there is a trojan that can hook into IE and grab all traffic before it&#8217;s encrypted, the issue is that it performed a successful man-in-the-middle by using a mixed-certificate technique to bypass the &#8220;EDUCATION&#8221; of SSL and the authentication. An example of this is here:</p>
<p><a href="http://ip.securescience.net/exploits/ssl_mix.html" rel="nofollow">http://ip.securescience.net/exploits/ssl_mix.html</a></p>
<p>This demonstrates 4 frames 2 of which are SSL protected, and 2 which are not. No matter what browser we demonstrate this from, there are no warnings, pop-ups, or anything about non-secure pages, secure pages, and as we all know there is no Lock at the bottom. If you reverse the roll:</p>
<p><a href="https://slam.securescience.com/threats/mixed.html" rel="nofollow">https://slam.securescience.com/threats/mixed.html</a></p>
<p>We see my Cert (which shouldn&#8217;t alert, some browsers in mozilla still don&#8217;t like Thawte), and we also have two frames with two separate SSL certs on the page. No warnings, and the SSL lock states that it&#8217;s what the domain has. This is a problem with cross-user attacks as well as Trojans that Pharm because they easily fake &#8220;authentication&#8221; which is the intent of SSL for the home user, to authenticate the site and make sure they are there. The education around this for pharming is to use SSL to verify you are at the site. Well - in this report, this proves that not all cases will work.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Someone Else</title>
		<link>http://www.mal-aware.org/2006/02/14/recent-haxdoor-distribution-breaks-ssl-via-pharming/#comment-9</link>
		<dc:creator>Someone Else</dc:creator>
		<pubDate>Sun, 19 Feb 2006 15:43:26 +0000</pubDate>
		<guid isPermaLink="false">http://www.mal-aware.org/2006/02/14/recent-haxdoor-distribution-breaks-ssl-via-pharming/#comment-9</guid>
		<description>&lt;strong&gt;Have hackers &#34;Broke&#34; SSL?...&lt;/strong&gt;

Seems that there has been some rumbling that SSL encryption has been broken recently, which is quite......</description>
		<content:encoded><![CDATA[<p><strong>Have hackers &quot;Broke&quot; SSL?&#8230;</strong></p>
<p>Seems that there has been some rumbling that SSL encryption has been broken recently, which is quite&#8230;&#8230;</p>
]]></content:encoded>
	</item>
</channel>
</rss>
