<?xml version="1.0" encoding="ISO-8859-1"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>

<channel>
	<title>ha.ckers.org web application security lab</title>
	<link>http://ha.ckers.org/blog</link>
	<description>Web Application Security Blog</description>
        <image>
           <link>http://ha.ckers.org/blog</link>
           <url>http://ha.ckers.org/images/hackers_rss.jpg</url> 
	</image>
	<pubDate>Sun, 14 Mar 2010 17:30:06 +0000</pubDate>
 
	<language>en</language>
		      <item>
		<title>Conversations With a Blackhat</title>
		<link>http://ha.ckers.org/blog/20100314/conversations-with-a-blackhat/</link>
		<comments>http://ha.ckers.org/blog/20100314/conversations-with-a-blackhat/#comments</comments>
		<pubDate>Sun, 14 Mar 2010 17:25:09 +0000</pubDate>
		<dc:creator>RSnake</dc:creator>
		
		<category><![CDATA[Webappsec]]></category>

		<category><![CDATA[spam]]></category>

		<category><![CDATA[Anti-Virus]]></category>

		<guid isPermaLink="false">http://ha.ckers.org/blog/20100314/conversations-with-a-blackhat/</guid>
		<description><![CDATA[I&#8217;ve been spending more and more time talking to blackhats lately.  Frankly, I think they&#8217;re fascinating people, and have a lot to teach the rest of us.  With the solemn promise that I won&#8217;t try to put them in jail, we can have free flowing conversations which aid us all in thinking about [...]]]></description>
			<content:encoded><![CDATA[<p>I&#8217;ve been spending more and more time talking to blackhats lately.  Frankly, I think they&#8217;re fascinating people, and have a lot to teach the rest of us.  With the solemn promise that I won&#8217;t try to put them in jail, we can have free flowing conversations which aid us all in thinking about the problem space.  I&#8217;ve certainly learned a lot.  Anyway, I got into a conversation with one of them about how he believes that a lot of the security put in place is actually doing a pretty good job.</p>
<p>The basic premise of the problem, from his perspective, is that hacking directly just isn&#8217;t as easy as it used to be, if you are like him.  He&#8217;s not the type to hack randomly, he&#8217;s only interested in targeted attacks with big payouts.  Sure, if you really work at it for days or weeks you&#8217;ll get in, almost always, but it&#8217;s not like it used to be where you&#8217;d just run a handful of basic tests and you were guaranteed to break in.  The risk is that now when he sends his mules to go cash out, there&#8217;s a chance they&#8217;ll get nailed.  Well, the more I thought about it the more I thought that this is a very solvable problem for bad guys.  There are already other types of bad guys who do things like spam, steal credentials and DDoS.  For that to work they need a botnet with thousands or millions of machines.  The chances of a million machine botnet having compromised at least one machine within a target of interest is relatively high.</p>
<p>So let&#8217;s say I&#8217;m badguy1 who wants to break into one or more companies of interest.  Sure, I could work for days or weeks and maybe get into one or both of them, but at the risk of tipping my hand to the companies and there&#8217;s always a chance I&#8217;ll fail entirely.  Or I could work with badguy2 who has a botnet.  I could simply give a list of IPs, domains or email addresses of known targets to the bot herder and say that instead of paying a few cents to rent some arbitrary machine for a day, I&#8217;ll pay thousands of dollars to get a bot within the company I&#8217;m actually interested in.</p>
<p>This tactic reminds me a little of the movie Wall Street.  You have a failing company (in this case a botnet that will probably only last a year or two).  If the company continues on it&#8217;s course it&#8217;ll make a pretty good amount of money, but nowhere near as much as if the owners break up the company into pieces and sell them off one by one to the interested parties.  Kind of an interesting/scary thought, but it could easily be used to avoid the cost and danger of individual exploitation against a company for a hacker interested in target attacks.  Rather, a brokerage for commodities (bots that come from interesting IPs/domains) could be created and used to sell off the individual nodes.  Using the existing backdoor into the company greatly reduces the risks involved for badguy1, because it&#8217;s guaranteed to be successful, without all the noise of a targeted attack.</p>
<p>If you were a blackhat, how much would you pay to have access to a machine inside of an organization that will lead to the big payout?</p>
<!--Tue, 16 March 2010 23:03:45 +000-->]]></content:encoded>
			<wfw:commentRss>http://ha.ckers.org/blog/20100314/conversations-with-a-blackhat/feed/</wfw:commentRss>
		</item>
	      <item>
		<title>Using Parameter Pollution and Clickjacking to Aid Anti-CSRF Bypass</title>
		<link>http://ha.ckers.org/blog/20100311/using-parameter-pollution-and-clickjacking-to-aid-anti-csrf-bypass/</link>
		<comments>http://ha.ckers.org/blog/20100311/using-parameter-pollution-and-clickjacking-to-aid-anti-csrf-bypass/#comments</comments>
		<pubDate>Thu, 11 Mar 2010 17:06:22 +0000</pubDate>
		<dc:creator>RSnake</dc:creator>
		
		<category><![CDATA[Webappsec]]></category>

		<guid isPermaLink="false">http://ha.ckers.org/blog/20100311/using-parameter-pollution-and-clickjacking-to-aid-anti-csrf-bypass/</guid>
		<description><![CDATA[It&#8217;s been a while since I&#8217;ve talked about Clickjacking, with only a few exceptions here and there.  Mostly because I haven&#8217;t seen it much in the wild - at least not yet.  But there&#8217;s still a lot of research out there to be done.  I got an interesting email the other day [...]]]></description>
			<content:encoded><![CDATA[<p>It&#8217;s been a while since I&#8217;ve talked about <a href="http://www.sectheory.com/clickjacking.htm">Clickjacking</a>, with only a few exceptions here and there.  Mostly because I haven&#8217;t seen it much in the wild - at least not yet.  But there&#8217;s still a lot of research out there to be done.  I got an interesting email the other day that talked about a way to use parameter pollution (or a mix of URL parameters and POST) to create a condition where you can defeat CSRF tokens:</p>
<p>The technique, <a href="http://blog.andlabs.org/2010/03/bypassing-csrf-protections-with.html">found by Lava Kuppan</a> describes a scenario where a mix of CSRF, parameter pollution and Clickjacking can defeat CSRF tokens in JSP and (sometimes) in ASP.NET.  It&#8217;s worth a read.  I did briefly mention using CSRF to pre-populate fields that may be necessary to create a Clickjacking scenario during Jeremiah and my brief talk at the world OWASP in New York.  But this takes it to a new level, where you can pre-load information in such a way that it will actually defeat the application logic in the process.  Anyway, cool stuff by Lava.</p>
<!--Tue, 16 March 2010 23:03:45 +000-->]]></content:encoded>
			<wfw:commentRss>http://ha.ckers.org/blog/20100311/using-parameter-pollution-and-clickjacking-to-aid-anti-csrf-bypass/feed/</wfw:commentRss>
		</item>
	      <item>
		<title>RSA Conference Wrapup</title>
		<link>http://ha.ckers.org/blog/20100308/rsa-conference-wrapup/</link>
		<comments>http://ha.ckers.org/blog/20100308/rsa-conference-wrapup/#comments</comments>
		<pubDate>Mon, 08 Mar 2010 16:45:27 +0000</pubDate>
		<dc:creator>RSnake</dc:creator>
		
		<category><![CDATA[General News]]></category>

		<category><![CDATA[Webappsec]]></category>

		<category><![CDATA[Random Security]]></category>

		<guid isPermaLink="false">http://ha.ckers.org/blog/20100308/rsa-conference-wrapup/</guid>
		<description><![CDATA[Well another RSA Conference has come and gone.  Lots of vendor noise about their product being the only secure one on the market, and other nonsense, as is to be expected.  Although I did notice a bit of realism this year.  It did seem like everyone had eaten a big helping of [...]]]></description>
			<content:encoded><![CDATA[<p>Well another RSA Conference has come and gone.  Lots of vendor noise about their product being the only secure one on the market, and other nonsense, as is to be expected.  Although I did notice a bit of realism this year.  It did seem like everyone had eaten a big helping of humble pie, which was refreshing.  Even the sales guys weren&#8217;t making as hard as a pitch as I&#8217;m accustomed to.  So all in all, it was a good time.  Lots of drinking, lots of good conversation, and I even managed to sneak in and see Jeremiah&#8217;s presentation on the top 10 new webappsec vulns from 2009 (how he managed to fit that all into 50 minutes still boggles the mind).  I didn&#8217;t make it to as many parties as I would have liked to this year - maybe I&#8217;m getting old, or maybe I started drinking too early.  Either way&#8230;</p>
<p>One notable quote was from Howard Schmidt who said, &#8220;<a href="http://www.wired.com/threatlevel/2010/03/schmidt-cyberwar/">There is no cyberwar,</a>&#8221; but I don&#8217;t think he ever defined what a cyberwar would look like - so I don&#8217;t know how we&#8217;ve decided we aren&#8217;t in the midst of one.  Maybe he&#8217;s absolutely right and we aren&#8217;t in the middle of anything like a war (just the low rumble of espionage), but I&#8217;d like to hear his definition one way or another so that I can know when I should start being outraged.</p>
<p>
<div align="center"><a href="http://ha.ckers.org/images/rsa-conference.png"><img src="http://ha.ckers.org/images/rsa-conference.png" width="389" height="243"><br />Click to enlarge</a></div>
</p>
<p>But I wanted to do a quick writeup on the RSA Conference registration computers themselves, while I was thinking about it.  For some reason, my entire life, I have just assumed programmers think the same way I do.  Then I am always annoyed to find out they don&#8217;t.  Physical security is tough, don&#8217;t get me wrong, but kiosks are one of those things you really need to be careful to protect from physical tampering and logical attacks.  Anyway, I was sitting there waiting for one of the pages to load, and it was taking forever.  Because there was no onscreen indicator that it was waiting, I started wondering if the form was even working at all, or if there was some dumb JS error or something else that would cause the page to never load.  So I clicked on one of the links at the top in the navigation and it gave me a &#8220;Diagnose Connection Problems&#8221; error and worse yet, it popped out of the Kiosk mode.  Never a good sign.  It looks like they&#8217;re protecting the application from most classes of attacks simply by disallowing outbound network access.  Let&#8217;s assume there were no way around that for a second (and I&#8217;m not convinced of that, incidentally).</p>
<p>Most people would probably say that security is good enough.  Any attack I could mount would be useless because I couldn&#8217;t exfiltrate the data off of that machine.  Oh, but it&#8217;s not that simple.  For that application to work it must be able to contact the site in question (the registration portal).  That portal has access to a database.  As such, the database itself is essentially dual-homed (on the Internet and on this Kiosk intranet).  So all I should need is some JavaScript malware to steal people&#8217;s information as it pretends to register them, and instead log the data into my database fields.  I can be somewhere else and check the records in the database for my account, and poof - I have access to whatever data I wanted to log.  I can get JavaScript execution by simply typing it into the URL bar and just like magic, I have a way to steal conference registrant&#8217;s information.  And there&#8217;s the cookies and any other tampering I might be able to do in the config options in IE.  It&#8217;s definitely NOT a huge deal, but rather just another example of how it&#8217;s incredibly complex to build a truly secure browser based kiosk system that can defend against determined attackers.  No identities were stolen in the making of this post.  Now, back to work!</p>
<!--Tue, 16 March 2010 23:03:45 +000-->]]></content:encoded>
			<wfw:commentRss>http://ha.ckers.org/blog/20100308/rsa-conference-wrapup/feed/</wfw:commentRss>
		</item>
	      <item>
		<title>Facebook Patents Social Feeds and I Patent XSS</title>
		<link>http://ha.ckers.org/blog/20100226/facebook-patents-social-feeds-and-i-patent-xss/</link>
		<comments>http://ha.ckers.org/blog/20100226/facebook-patents-social-feeds-and-i-patent-xss/#comments</comments>
		<pubDate>Fri, 26 Feb 2010 21:10:29 +0000</pubDate>
		<dc:creator>RSnake</dc:creator>
		
		<category><![CDATA[XSS]]></category>

		<category><![CDATA[Webappsec]]></category>

		<guid isPermaLink="false">http://ha.ckers.org/blog/20100226/facebooks-patents-social-feeds-and-i-patent-xss/</guid>
		<description><![CDATA[In honor of the USPO&#8217;s decision to allow Facebook&#8217;s patent for social feeds I decided to patent XSS.  Please pay up.  You know who you are.  Thank you.
]]></description>
			<content:encoded><![CDATA[<p>In honor of the USPO&#8217;s decision to allow Facebook&#8217;s <a href="http://mashable.com/2010/02/25/facebook-news-feed-patent/">patent for social feeds</a> I decided to patent <a href="http://patft.uspto.gov/netacgi/nph-Parser?TERM1=%3Cscript%3Ealert%28%22XSS%22%29%3C/script%3E&#038;Sect1=PTO1&#038;Sect2=HITOFF&#038;d=PALL&#038;p=1&#038;u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&#038;r=0&#038;f=S&#038;l=50">XSS</a>.  Please pay up.  You know who you are.  Thank you.</p>
<!--Tue, 16 March 2010 23:03:45 +000-->]]></content:encoded>
			<wfw:commentRss>http://ha.ckers.org/blog/20100226/facebook-patents-social-feeds-and-i-patent-xss/feed/</wfw:commentRss>
		</item>
	      <item>
		<title>Banks, Businesses, Viruses and the UCC</title>
		<link>http://ha.ckers.org/blog/20100224/banks-businesses-viruses-and-the-ucc/</link>
		<comments>http://ha.ckers.org/blog/20100224/banks-businesses-viruses-and-the-ucc/#comments</comments>
		<pubDate>Wed, 24 Feb 2010 18:19:40 +0000</pubDate>
		<dc:creator>RSnake</dc:creator>
		
		<category><![CDATA[General News]]></category>

		<category><![CDATA[Anti-Virus]]></category>

		<category><![CDATA[Random Security]]></category>

		<guid isPermaLink="false">http://ha.ckers.org/blog/20100224/banks-businesses-viruses-and-the-ucc/</guid>
		<description><![CDATA[There&#8217;s an interesting post over at Krebs On Security talking about some poor company that is going bankrupt because TD Bank allegedly will not give them their money back after it was stolen out of their account.  Now, I wish I could say this concept is totally foreign to me, but unfortunately this isn&#8217;t [...]]]></description>
			<content:encoded><![CDATA[<p>There&#8217;s an interesting post over at <a href="http://www.krebsonsecurity.com/2010/02/n-y-firm-faces-bankruptcy-from-164000-e-banking-loss/">Krebs On Security</a> talking about some poor company that is going bankrupt because <a href="http://www.tdbank.com">TD Bank</a> allegedly will not give them their money back after it was stolen out of their account.  Now, I wish I could say this concept is totally foreign to me, but unfortunately this isn&#8217;t the first time I&#8217;ve heard this story.  I&#8217;m under NDAs not to describe the people involved, or the bank involved, but the important details are nearly identical to this story.  Why is this happening?</p>
<p>There is a little known code call the UCC (<a href="http://en.wikipedia.org/wiki/Uniform_Commercial_Code">Uniform Commercial Code</a>) that essentially says that if you are a business and you want to do wire transfers you are essentially to be treated as a bank.  You are probably wincing right now, because it&#8217;s just as stupid as it sounds.  Note that this is not true for consumers - but even if your business consists of even one person, you still are treated as a bank.  As such, if your company has money wired out of it&#8217;s account, the bank isn&#8217;t to be held liable - or at least that&#8217;s been their argument. This is happening all the time, so why aren&#8217;t we hearing about it all the time?  Well that leads me to the worst part of this story.</p>
<p>The banks have essentially two options if a company takes them to court.  They can win the case, or they can lose the case.  If they win, that leaves the company in question free to say and do whatever they want (as is the case with TD Bank above).  If they lose the case, it essentially creates precedence and can open the bank to class action lawsuits to overturn the UCC.  Either way, it&#8217;s a bad day for the bank.  So they opt for the third choice which is to delay the inevitable.  They make these poor businesses wait for sometimes years before they will begrudgingly settle for somewhere shy of the full amount.  Sometimes companies just give up, and sometimes they take the money and sign the NDAs.  Either way, that&#8217;s a much better outcome than letting something get litigated.  So yes, those poor companies are getting the run around, and we don&#8217;t get to hear about it because at the end of the day they are all signing NDAs.</p>
<p>So, if you run a company, be prepared for the worst when it comes to how the bank is going to treat you if someone steals your money.  There don&#8217;t appear to be any safeguards other than individual contracts you might be able to get your bank to sign and agree to.  However, if anyone happens to work for a bank, and can guarantee that money held there will be treated just like physical cash (and reimbursed just like if it is stolen out of the vault), I&#8217;m sure companies would flock to you - I know a lot of small businesses that would like to know that their money is safe, and right now, it just isn&#8217;t with TD Bank and their ilk.  In the meantime, I sort of hope some lawyer is salivating at the prospect of a class action suit.</p>
<!--Tue, 16 March 2010 23:03:45 +000-->]]></content:encoded>
			<wfw:commentRss>http://ha.ckers.org/blog/20100224/banks-businesses-viruses-and-the-ucc/feed/</wfw:commentRss>
		</item>
	      <item>
		<title>Google Buzz Security Flaw</title>
		<link>http://ha.ckers.org/blog/20100216/google-buzz-security-flaw/</link>
		<comments>http://ha.ckers.org/blog/20100216/google-buzz-security-flaw/#comments</comments>
		<pubDate>Tue, 16 Feb 2010 19:17:34 +0000</pubDate>
		<dc:creator>RSnake</dc:creator>
		
		<category><![CDATA[XSS]]></category>

		<category><![CDATA[Webappsec]]></category>

		<guid isPermaLink="false">http://ha.ckers.org/blog/20100216/google-buzz-security-flaw/</guid>
		<description><![CDATA[&#8230; Speaking of Google, I got an email from TrainReq (the same fellow who allegedly hacked Miley Cyrus for those who don&#8217;t keep up to date on your tween idols).  The email was regarding an exploit against Google Buzz.  It&#8217;s yet another example of bad input validation/output encoding by your favorite advertising overlords [...]]]></description>
			<content:encoded><![CDATA[<p>&#8230; <a href="http://ha.ckers.org/blog/20100215/nevermind-i-was-wrong-google-is-evil/">Speaking of Google</a>, I got an email from <a href="http://www.digitalgangster.com/">TrainReq</a> (the same fellow who allegedly hacked Miley Cyrus for those who don&#8217;t keep up to date on your tween idols).  The email was regarding an exploit against Google Buzz.  It&#8217;s yet another example of bad input validation/output encoding by your favorite advertising overlords at Google.  As you can see, nothing up my sleeves:</p>
<p>
<div align="center"><a href="http://ha.ckers.org/images/google-buzz-xss.png"><img src="http://ha.ckers.org/images/google-buzz-xss.png" width="330" height="123"><br />Click here to enlarge.</a></div>
</p>
<p>There&#8217;s four things of note here.  Firstly it&#8217;s on Google&#8217;s domain, not some other domain like Google Gadgets or something.  So yes, it&#8217;s bad for phishing and for cookies.  Secondly, it&#8217;s over SSL/TLS (so no one should be able to see what&#8217;s going on, right?).  Third, it could be used to hijack Google Buzz - as if anyone is using that product (or at least you shouldn&#8217;t be).  And lastly isn&#8217;t it ironic that Google is asking to know where I am on the very same page that&#8217;s being compromised?  Why on earth does Google think its systems are secure enough to trust them with that kind of sensitive information?  Yes, bad guys can figure out where you&#8217;re located if you allow that function.  Chinese dissidents beware!  But if you have something to hide, <a href="http://blogs.computerworld.com/15234/google_ceo_if_you_want_privacy_do_you_have_something_to_hide">you must be a bad guy</a>, right, Eric?</p>
<!--Tue, 16 March 2010 23:03:45 +000-->]]></content:encoded>
			<wfw:commentRss>http://ha.ckers.org/blog/20100216/google-buzz-security-flaw/feed/</wfw:commentRss>
		</item>
	      <item>
		<title>Nevermind, I Was Wrong, Google Is Evil</title>
		<link>http://ha.ckers.org/blog/20100215/nevermind-i-was-wrong-google-is-evil/</link>
		<comments>http://ha.ckers.org/blog/20100215/nevermind-i-was-wrong-google-is-evil/#comments</comments>
		<pubDate>Mon, 15 Feb 2010 22:07:20 +0000</pubDate>
		<dc:creator>RSnake</dc:creator>
		
		<category><![CDATA[Webappsec]]></category>

		<guid isPermaLink="false">http://ha.ckers.org/blog/20100215/nevermind-i-was-wrong-google-is-evil/</guid>
		<description><![CDATA[I&#8217;ve been waiting a while to do this post - several weeks actually since my original post.  In that post, I applauded Google&#8217;s apparent interest in reigning censorship as &#8220;the first really truly non-evil thing I have seen Google do in years&#8221;.  Since then, I thought it appropriate to give them some time [...]]]></description>
			<content:encoded><![CDATA[<p>I&#8217;ve been waiting a while to do this post - several weeks actually since my <a href="http://ha.ckers.org/blog/20100112/wait-google-i-thought-you-were-evil/">original post</a>.  In that post, I applauded Google&#8217;s apparent interest in reigning censorship as &#8220;the first really truly non-evil thing I have seen Google do in years&#8221;.  Since then, I thought it appropriate to give them some time to sift through the nuances of <a href="http://googleblog.blogspot.com/2010/01/new-approach-to-china.html">their blog post</a> - you know, to give them the benefit of the doubt - of which I had many.  I&#8217;m sure you remember just one month ago when Google was waxing on about how they were going to stop censoring:</p>
<p>
<blockquote>We have decided <b>we are no longer willing to continue censoring our results on Google.cn</b>, and so over the next few weeks we will be discussing with the Chinese government the basis on which we could operate an unfiltered search engine within the law, if at all.</p></blockquote>
<p>Well, according to <a href="http://www.theregister.co.uk/2010/02/10/google_china/">The Register</a>:</p>
<p>
<blockquote>Google Chief Legal Officer David Drummond never said his company would stop censoring hot-button issues such as the Tiananmen Square massacre of 1989.</p></blockquote>
<p>If that theory is true Google is essentially saying, &#8220;You were too stupid to read our post properly because clearly, our post means that we aren&#8217;t able to do so legally, so we&#8217;re still going to censor.&#8221;  If that&#8217;s true why would Google wait to clarify such an extremely well publicized fauxpas in their own wording?  Maybe they missed <a href="http://blogs.wsj.com/chinarealtime/2010/01/13/flowers-for-google-in-china/tab/article/">all those flowers at the Chinese office</a>.  No, I don&#8217;t believe that The Register&#8217;s theory is true - I think Google sincerely intended to pull out or get more support from the Chinese.  However, I believe that Google is being stonewalled by the Chinese government - and for good reason.  Google&#8217;s demands are impossible to comply with.  But we all know that Google and China have been talking for weeks and we haven&#8217;t seen any movement other than China&#8217;s response to Hillary Clinton saying that <a href="http://news.bbc.co.uk/2/hi/asia-pacific/8474011.stm">they don&#8217;t censor</a> (and if anyone still needs proof, email me and I&#8217;ll give you instructions on how to see it in action).</p>
<p>Google hasn&#8217;t stopped censoring anything, and they haven&#8217;t pulled out of China.  They asked for a &#8220;few weeks&#8221; to have those talks, and it has been a few.  So now we have to ask the question - does Google actually care about the Chinese people, or is it all about making money for the shareholders.  We know that Google censors elsewhere in the world, <a href="http://advocacy.globalvoicesonline.org/2010/01/24/google-for-good%E2%80%A6or-just-for-money/">it&#8217;s not just China</a>, yet they&#8217;ve not even made mention of those citizens of the other nations.  So we have to make the logical connection that Google is just acting in their own self interest and this whole China thing is a distraction from several other major issues, and has nothing to do with the best interest of people who are being censored.  So now the real question is did Google do what it sent out to do?</p>
<p>And, so yes bravo, Google.  Well done.  You snowballed everyone as you stall for time trying to figure out what you want to do with your failing Chinese division.  You spanked the Chinese government for hacking into your systems while you drew fire away from your crappy security around your warrant-less wiretapping system that you built into Gmail.  So yes, I would have to assess Google&#8217;s incredibly calculated decision as a success, but not for the people of China or other censored peoples around the world.  It&#8217;s back to business as usual at the Googleplex.  And so yes, Google, you can keep slinging your ads well into the future.  But I have to ask - at what cost?</p>
<!--Tue, 16 March 2010 23:03:45 +000-->]]></content:encoded>
			<wfw:commentRss>http://ha.ckers.org/blog/20100215/nevermind-i-was-wrong-google-is-evil/feed/</wfw:commentRss>
		</item>
	      <item>
		<title>Phishing With Google Wave</title>
		<link>http://ha.ckers.org/blog/20100210/phishing-with-google-wave/</link>
		<comments>http://ha.ckers.org/blog/20100210/phishing-with-google-wave/#comments</comments>
		<pubDate>Thu, 11 Feb 2010 00:20:23 +0000</pubDate>
		<dc:creator>RSnake</dc:creator>
		
		<category><![CDATA[Webappsec]]></category>

		<category><![CDATA[Phishing]]></category>

		<guid isPermaLink="false">http://ha.ckers.org/blog/20100210/phishing-with-google-wave/</guid>
		<description><![CDATA[Hat tip to cyberlocksmith for this post.  He pointed me to a good article on how to phish Google Wave users using malicious gadgets.  This is precisely what Tom Stracener and I were talking about in our presentation at DefCon and Blackhat a few years back - except this is for Wave instead [...]]]></description>
			<content:encoded><![CDATA[<p>Hat tip to <a href="http://twitter.com/cyberlocksmith/statuses/8911258494">cyberlocksmith</a> for this post.  He pointed me to <a href="http://blog.nparashuram.com/2010/02/phishing-with-google-wave.html">a good article on how to phish Google Wave users</a> using malicious gadgets.  This is precisely what Tom Stracener and I were talking about in our presentation at DefCon and Blackhat a few years back - except this is for Wave instead of iGoogle.  Either way the point is the same - when you let other people control content that is embedded in your site, you are at the mercy of whatever they chose to do within that gadget.  In this case, they can pop the user out of the iframe and present them with a duplicate of the sign-in page.  The vast majority of users would fall for this kind of attack too.</p>
<p>I really don&#8217;t mean to harp too much on Google specifically for this stuff (in as much as I have countless times in the past held them accountable for their crappy security).  There are lots of other companies and websites that are moving to user supplied gadgets in an iframe as if that makes them safe.  Maybe some variant of HTML5 + some trickery can solve these problems, but there&#8217;s a lot of legacy users who won&#8217;t be able to support those standards for a good long while.  In the mean-time, we just continue to see more vulnerable code being outputted by Google and their peers and the only saving grace is that no one has yet decided to take advantage of their security flaws.  Scary.  But I&#8217;m sure a blacklist will solve their problems if and when they do get attacked, right?  Right?</p>
<!--Tue, 16 March 2010 23:03:45 +000-->]]></content:encoded>
			<wfw:commentRss>http://ha.ckers.org/blog/20100210/phishing-with-google-wave/feed/</wfw:commentRss>
		</item>
	      <item>
		<title>Releases.mozilla.org SSL and Manual Update Fail</title>
		<link>http://ha.ckers.org/blog/20100204/releasesmozillaorg-ssl-and-update-fail/</link>
		<comments>http://ha.ckers.org/blog/20100204/releasesmozillaorg-ssl-and-update-fail/#comments</comments>
		<pubDate>Thu, 04 Feb 2010 15:37:21 +0000</pubDate>
		<dc:creator>RSnake</dc:creator>
		
		<category><![CDATA[Webappsec]]></category>

		<guid isPermaLink="false">http://ha.ckers.org/blog/20100204/releasesmozillaorg-ssl-and-update-fail/</guid>
		<description><![CDATA[I did a presentation at the DefCon Comedy Jam about how users manually validate updates for Firefox was just a total mess from a security perspective.  It had a lot to do with the fact that they are using round robin DNS and relying on the good will of a lot of dispirit sites [...]]]></description>
			<content:encoded><![CDATA[<p>I did a presentation at the DefCon Comedy Jam about how users manually validate updates for Firefox was just a total mess from a security perspective.  It had a lot to do with the fact that they are using round robin DNS and relying on the good will of a lot of dispirit sites to do their hosting for them.  Well, I&#8217;ve been wondering more and more about how I may or may not be able to download these releases and verify them manually in a secure way.  So I did a few checks and here&#8217;s the IP space I found and the status of what their SSL/TLS ports were when checked yesterday:</p>
<p>
<blockquote>63.245.208.152 (live but with SSL/TLS mismatch)<br />
128.61.111.9 (connection refused)<br />
129.101.198.59 (connection refused)<br />
131.188.12.212 (connection refused)<br />
149.20.20.5 (connection refused)<br />
156.56.247.196 (connection refused)<br />
202.177.202.154 (connection refused)<br />
204.152.184.196 (connection refused)<br />
204.246.0.136 (connection refused)<br />
216.165.129.141 (connection refused)<br />
64.50.236.214 (connection refused)<br />
64.50.236.52 (connection refused)<br />
129.101.198.59 (operation timed out)<br />
155.98.64.83 (operation timed out)</p></blockquote>
<p>So only 1 out of 14 even have SSL enabled.  Okay&#8230;  well today, I took a little spin on SSLLabs and I found that the one site that does have SSL enabled (<a href="https://www.ssllabs.com/ssldb/analyze.html?d=releases.mozilla.org&#038;s=63.245.208.152">63.245.208.152</a>) has a SSL/TLS mismatch error for videos.mozilla.org.  I mean&#8230; seriously! If your browser goes to https://releases.mozilla.org this is sort of what&#8217;s happening under the hood:</p>
<p>
<blockquote>$ telnet releases.mozilla.org 443<br />
Trying 202.177.202.154&#8230;<br />
telnet: connect to address 202.177.202.154: Connection refused<br />
Trying 204.152.184.196&#8230;<br />
telnet: connect to address 204.152.184.196: Connection refused<br />
Trying 204.246.0.136&#8230;<br />
telnet: connect to address 204.246.0.136: Connection refused<br />
Trying 216.165.129.141&#8230;<br />
telnet: connect to address 216.165.129.141: Connection refused<br />
Trying 64.50.236.214&#8230;<br />
telnet: connect to address 64.50.236.214: Connection refused<br />
Trying 128.61.111.9&#8230;<br />
telnet: connect to address 128.61.111.9: Connection refused<br />
Trying 129.101.198.59&#8230;<br />
telnet: connect to address 129.101.198.59: Connection refused<br />
Trying 131.188.12.212&#8230;<br />
telnet: connect to address 131.188.12.212: Connection refused<br />
Trying 149.20.20.5&#8230;<br />
telnet: connect to address 149.20.20.5: Connection refused<br />
Trying 155.98.64.83&#8230;<br />
telnet: connect to address 155.98.64.83: Operation timed out<br />
Trying 156.56.247.196&#8230;<br />
telnet: connect to address 156.56.247.196: Connection refused<br />
Trying 63.245.208.152&#8230;<br />
Connected to releases.geo.mozilla.com.<br />
Escape character is &#8216;^]&#8217;.<br />
^]<br />
telnet> quit</p></blockquote>
<p>Yes, after a minute of trying your browser will eventually find the one HTTPS server - or it won&#8217;t (sometimes it just gives up).  So then in poking around within my Mozilla config I saw a reference to http://en-US.www.mozilla.com/en-US/firefox/3.5.7/releasenotes/.  So I switched to SSL/TLS with <a href="https://en-US.www.mozilla.com/en-US/firefox/3.5.7/releasenotes/">this link</A>, because I like being secure, and I get a SSL/TLS warning as well.   These are the kinds of things that make Firefox incredibly unsafe to manually download and verify the binaries if you are in a hostile environment.  And I&#8217;m just scratching the surface compared to my presentation.  How many of those 3rd party sites do you think can be exploited?</p>
<!--Tue, 16 March 2010 23:03:45 +000-->]]></content:encoded>
			<wfw:commentRss>http://ha.ckers.org/blog/20100204/releasesmozillaorg-ssl-and-update-fail/feed/</wfw:commentRss>
		</item>
	      <item>
		<title>Accuracy and Time Costs of Web Application Security Scanner Report</title>
		<link>http://ha.ckers.org/blog/20100203/accuracy-and-time-costs-of-web-application-security-scanner-report/</link>
		<comments>http://ha.ckers.org/blog/20100203/accuracy-and-time-costs-of-web-application-security-scanner-report/#comments</comments>
		<pubDate>Wed, 03 Feb 2010 20:26:11 +0000</pubDate>
		<dc:creator>RSnake</dc:creator>
		
		<category><![CDATA[Webappsec]]></category>

		<guid isPermaLink="false">http://ha.ckers.org/blog/20100203/accuracy-and-time-costs-of-web-application-security-scanner-report/</guid>
		<description><![CDATA[Larry Suto is back with another report outlining the differences between some of the top web application scanners on the market.  Before you get all uptight and start flaming me, I in NO WAY sponsored, encouraged or had anything to do with this test in any way.  In fact, I only found out [...]]]></description>
			<content:encoded><![CDATA[<p>Larry Suto is back with another report outlining the differences between some of the top web application scanners on the market.  Before you get all uptight and start flaming me, I in NO WAY sponsored, encouraged or had anything to do with this test in any way.  In fact, I only found out about it a few days ago.  Not that I think that&#8217;ll stop the flame wars, but just direct your ire appropriately, please!  Anyway, he took a different approach this time, and instead of running the scanners against something he had devised up to be used only in his own lab, he turned all the scanners on each other&#8217;s public test sites.  You might think they should all fair fairly well since they&#8217;re all public and there&#8217;s nothing stopping them from testing to their heart&#8217;s content.  But that&#8217;s anything but what he found.  You can <a href="http://ha.ckers.org/files/Accuracy_and_Time_Costs_of_Web_App_Scanners.pdf">download Larry&#8217;s report here</a>.</p>
<p>Some of the more interesting findings were that Burp Suite Pro (an extremely cheap product built by Portswigger - and a damned fine manual testing tool, I might add) fared better than Qualys or WebInspect when trained.  I always loved Burp Suite!  Larry&#8217;s commentary is particularly amusing as you go through it, with choice quotes, like:</p>
<p>
<blockquote>Accuntix missed 31% of the vulnerabilities after training and 37% without training. This is a significant cause for concern as they should be aware of the links vulnerabilities on their own site and be able to crawl and attack them.</p></blockquote>
<p>And&#8230;</p>
<p>
<blockquote>WebInspect missed 66% of the vulnerabilities, even after being trained to know all of the pages. They missed 42% of the vulnerabilities on their own test site after being trained and 55% before training.</p></blockquote>
<p><a href="http://www.ntobjectives.com">NTOSpider by NT Objectives</a> came out in the lead with the best overall score of the application scanners tested (which included <a href="http://www.acunetix.com/">Acunetix</a>, <a href="http://www.watchfire.com/products/appscan/default.aspx">Appscan</ap>, <a href="http://www.portswigger.net">Burp Suite Pro</a>, <a href="http://www.cenzic.com/products/cenzic-hailstormPro">Hailstorm</a>, <a href="https://h10078.www1.hp.com/cda/hpms/display/main/hpms_content.jsp?zn=bto&#038;cp=1-11-201_4000_100__">WebInspect</a>, and <a href="http://www.ntobjectives.com">NTOSpider</a>).  He also measured things like how long the various scanners take to configure, support and so on - all important things for companies about to make the big investment.  This isn&#8217;t all scanners everywhere (notably <a href="http://www.whitehatsec.com/home/index.html">WhiteHat</a> is missing as is the newest player to the field, <a href="http://netsparker.com/">NetSparker</a> who incidentally <a href="http://www.mavitunasecurity.com/blog/netsparker-accuracy-and-time-costs-of-web-application-security-scanner-report/">took it upon themselves to add themselves into the report after the fact</a>, and other free web assessment tools, like <a href="http://www.cirt.net/nikto2">Nikto</a> etc&#8230;), but it&#8217;s a great start to a long future of heavily debated research, I&#8217;m sure.  Love him, or hate him, Larry&#8217;s always got interesting research to share!</p>
<!--Tue, 16 March 2010 23:03:45 +000-->]]></content:encoded>
			<wfw:commentRss>http://ha.ckers.org/blog/20100203/accuracy-and-time-costs-of-web-application-security-scanner-report/feed/</wfw:commentRss>
		</item>
	</channel>
</rss>
