<?xml version="1.0" encoding="UTF-8"?>
<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/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Veracode Security Blog: Application security research, security trends and opinions &#187; 2009 &#187; October</title>
	<atom:link href="http://www.veracode.com/blog/2009/10/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.veracode.com/blog</link>
	<description>Application security testing, analysis, and metrics</description>
	<lastBuildDate>Fri, 18 May 2012 16:17:21 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>White Box Better Than Black Box</title>
		<link>http://www.veracode.com/blog/2009/10/white-box-better-than-black-box/</link>
		<comments>http://www.veracode.com/blog/2009/10/white-box-better-than-black-box/#comments</comments>
		<pubDate>Wed, 21 Oct 2009 16:06:23 +0000</pubDate>
		<dc:creator>Chris Wysopal</dc:creator>
				<category><![CDATA[Application Security]]></category>
		<category><![CDATA[RESEARCH]]></category>

		<guid isPermaLink="false">http://www.veracode.com/blog/?p=964</guid>
		<description><![CDATA[The WASS Project which Veracode contributed data to shows some nice benefits to White box (static) over Black box (dynamic) for many serious vulnerability categories. White box overall detects a higher prevalence of many categories which we can extrapolate to having lower FN rates. Now the sample set of apps is not the same so [...]]]></description>
			<content:encoded><![CDATA[<p>The <a href="http://projects.webappsec.org/Web-Application-Security-Statistics">WASS</a> Project which Veracode contributed data to shows some nice benefits to White box (static) over Black box (dynamic) for many serious vulnerability categories.  White box overall detects a higher prevalence of many categories which we can extrapolate to having lower FN rates.  Now the sample set of apps is not the same so this can only be used as a trend.  Static is better than dynamic in 5 out of 7 categories: credential/session prediction, SQL Injection, Path Traversal, Insufficient Authorization, OS Commandeering.  In one category, insufficient authorization, dynamic is better and in one category, brute force attack, my gut feel is this is within the margin of error given the different app samples.</p>
<p>I consider credential/session prediction flaws detected by white box to be typically hard to exploit even though it is a real flaw.  White box (static) analysis reports this whenever non-cryptographically strong random number generators are used to generate session identifiers or resource IDs.  Usually this means standard rand() is used.  The SQL injection, path traversal, and OS commandeering are probably found better by static because these are a good sweet spot for static with its 100% code coverage.  All that is required is good data flow modeling from web request to tainted function.  In this case, database query, file I/O, or system/process calls. Black box not finding as much is likely do to much less coverage of code paths in the application.</p>
<blockquote><p><strong>Percent of vulnerabilities out of total number of vulnerabilities (% Vulns BlackBox &#038; WhiteBox)</strong></p>
<p>If we consider the prevalence of high risk level vulnerabilities in detailed web application analysis (P. 9) we’ll see that the most widespread is Credential/Session Prediction errors. SQL Injection, Path Traversal and implementation and configuration errors in authentication and authorization systems are also widespread.</p>
<p><img alt="" src="http://projects.webappsec.org/f/1255633838/image9.png" title="White box vs. Black box" class="alignnone" width="580" height="369" />
</p></blockquote>
<h5>Veracode Security Solutions</h5>
<div style="margin-left:15px;">
<a href="http://www.veracode.com/security/application-testing-tool">Application Testing Tool</a><br />
<a href="http://www.veracode.com/security/static-analysis-tool">Static Analysis</a><br />
<a href="http://www.veracode.com/security/penetration-testing">Penetration Testing</a><br />
<a href="http://www.veracode.com/security/static-code-analysis">Static Code Analysis</a><br />
<a href="http://www.veracode.com/security/vulnerability-scanning">Vulnerability Scanning Tools</a><br />
<a href="http://www.veracode.com/security/web-application-security-testing">Web Application Security</a><br />
<a href="http://www.veracode.com/security/software-testing-tools">Software Testing Tools</a><br />
<a href="http://www.veracode.com/security/source-code-security-analyzer">Source Code Security Analyzer</a><br />
<a href="http://www.veracode.com/security/code-security">Software Code Security</a><br />
<a href="http://www.veracode.com/security/code-analysis">Source Code Analysis</a><br />
<a href="http://www.veracode.com/security/code-review">Code Review</a></div>
<h5>Veracode Security Threat Guides</h5>
<div style="margin-left:15px;">
<a href="http://www.veracode.com/security/sql-injection">SQL Injection Vulnerabilities</a><br />
<a href="http://www.veracode.com/security/xss">Cross Site Scripting</a><br />
<a href="http://www.veracode.com/security/csrf">Cross Site Request Forgery</a><br />
<a href="http://www.veracode.com/security/ldap-injection">LDAP Injection</a><br />
<a href="http://www.veracode.com/security/mobile-code-security">Mobile Code Security</a></div>
]]></content:encoded>
			<wfw:commentRss>http://www.veracode.com/blog/2009/10/white-box-better-than-black-box/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
		<item>
		<title>From the 10 Years Ago Today Department</title>
		<link>http://www.veracode.com/blog/2009/10/from-the-10-years-ago-today-department/</link>
		<comments>http://www.veracode.com/blog/2009/10/from-the-10-years-ago-today-department/#comments</comments>
		<pubDate>Fri, 02 Oct 2009 14:25:17 +0000</pubDate>
		<dc:creator>Chris Wysopal</dc:creator>
				<category><![CDATA[Application Security]]></category>
		<category><![CDATA[RESEARCH]]></category>

		<guid isPermaLink="false">http://www.veracode.com/blog/?p=947</guid>
		<description><![CDATA[From the L0pht Archives: Weld Pond and Cult of the Dead Cow to be Featured on Dateline NBC 9.30.1999 The lack of client side security for internet transactions poses a huge security risk that online banks and others just seem to ignore. Tools such as BO2K and even simpler keystroke loggers can cut through the [...]]]></description>
			<content:encoded><![CDATA[<p>From the <a href="http://web.archive.org/web/20000229093418/www.l0pht.com/index.html">L0pht Archives</a>:</p>
<blockquote><p>
<B>Weld Pond and Cult of the Dead Cow to be Featured on Dateline NBC</B><BR><br />
<B> 9.30.1999 </B><br />
The lack of client side security for internet transactions poses a huge<br />
security risk that online banks and others just seem to ignore. Tools such<br />
as BO2K and even simpler keystroke loggers can cut through the<br />
authentication used for &#8220;secure&#8221; web transactions to allow an attacker to<br />
authenticate as the hapless consumer. </p>
<p>Dateline explores this problem on Sunday October 3rd at 7pm EST. Watch<br />
Cult of the Dead Cow demonstrate the attack and Weld Pond from the<br />
L0pht talk about whatis really going on.</p>
<p><object width="445" height="364"><param name="movie" value="http://www.youtube-nocookie.com/v/ErWcY13L0pY&#038;hl=en&#038;fs=1&#038;rel=0&#038;color1=0x006699&#038;color2=0x54abd6&#038;border=1"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube-nocookie.com/v/ErWcY13L0pY&#038;hl=en&#038;fs=1&#038;rel=0&#038;color1=0x006699&#038;color2=0x54abd6&#038;border=1" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="445" height="364"></embed></object></p></blockquote>
<p>It is shocking how little has fundementally changed in the way consumers perform high value banking transactions over the web. Looking back with 10 years hindsight I have a slightly different way of describing the situation.  Banks assume the network is compromised so they use end to end encryption.  Banks don&#8217;t assume the endpoint is compromised so there is no security protection.  In 2009 what is more likely, that your upstream is compromised or the endpoint is compromised?  I would say for the average internet user the endpoint is more likely to be compromised.</p>
<p>Has the endpoint water slowly come to a boil and we are happy frogs slowly getting cooked?</p>
<h5>Veracode Security Solutions</h5>
<div style="margin-left:15px;">
<a href="http://www.veracode.com/security/vulnerability-assessment-software">Vulnerability Assessment</a><br />
<a href="http://www.veracode.com/security/web-security">Website Security</a><br />
<a href="http://www.veracode.com/security/application-testing-tool">Application Analysis</a><br />
<a href="http://www.veracode.com/security/dynamic-analysis">Dynamic Analysis</a><br />
<a href="http://www.veracode.com/security/internet-security">Internet Security</a><br />
<a href="http://www.veracode.com/security/malicious-code">Malicious Code</a></div>
<p></p>
<h5>Security Alternatives</h5>
<div style="margin-left:15px;">
<a href="http://www.veracode.com/security/hp-fortify-alternative">HP Fortify</a><br />
<a href="http://www.veracode.com/security/whitehat-security-alternative">Whitehat Security</a><br />
<a href="http://www.veracode.com/security/rational-appscan-alternative">IBM Rational AppScan</a></div>
<p></p>
<h5>Security Threat Guides</h5>
<div style="margin-left:15px;">
<a href="http://www.veracode.com/security/csrf">CSRF</a><br />
<a href="http://www.veracode.com/security/ldap-injection">LDAP Security</a><br />
<a href="http://www.veracode.com/security/mobile-code-security">Mobile Security</a><br />
<a href="http://www.veracode.com/security/sql-injection">SQL Injection</a><br />
<a href="http://www.veracode.com/security/xss">What is Cross Site Scripting?</a></div>
]]></content:encoded>
			<wfw:commentRss>http://www.veracode.com/blog/2009/10/from-the-10-years-ago-today-department/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Stealing PII is So 2007 &#8212; They Want Your Endpoint</title>
		<link>http://www.veracode.com/blog/2009/10/stealing-pii-is-so-2007-they-want-your-endpoint/</link>
		<comments>http://www.veracode.com/blog/2009/10/stealing-pii-is-so-2007-they-want-your-endpoint/#comments</comments>
		<pubDate>Thu, 01 Oct 2009 16:35:24 +0000</pubDate>
		<dc:creator>Chris Wysopal</dc:creator>
				<category><![CDATA[Application Security]]></category>
		<category><![CDATA[RESEARCH]]></category>

		<guid isPermaLink="false">http://www.veracode.com/blog/?p=940</guid>
		<description><![CDATA[Attackers are not going to be satisfied with a simple PII breach any more. The market is becoming saturated with PII. Look at the stats. In 2007, credit card records sold for an average of $10 per cardholder record; in 2009 the same records sell for an average of 50 cents per record. Attackers want [...]]]></description>
			<content:encoded><![CDATA[<p>Attackers are not going to be satisfied with a simple PII breach any more.  The market is becoming saturated with PII.  Look at the stats.  In 2007, credit card records sold for an average of $10 per cardholder record; in 2009 the same records sell for an average of 50 cents per record. Attackers want higher value than this.  They want to control the endpoint.  They want access to your online financial accounts.  They are succeeding.</p>
<p>Controlling the endpoint within a business can net an attacker $100,000+.  In <a href="http://www.technologyreview.com/computing/23488/">&#8220;Real-Time Hackers Foil Two-Factor Security&#8221;</a>, Rob Lemos reports that an attacker was able to hitchhike on the computer of an employee of a construction company and issue transactions worth $447,000 in a matter of minutes.  This sounds a lot better than 50 cents per record for cardholder data.  Getting malicious remote access software installed on the computers of employees that conduct online banking then is a good plan of attack.  That is exactly what just happened at PayChoice, an online payroll company.</p>
<p>The Washington Post <a href="http://voices.washingtonpost.com/securityfix/2009/09/hackers_breach_payroll_giant_t.html">reports</a> that last week attackers stole email, usernames, and partial password information from PayChoice.  They then used that information to target PayChoice&#8217;s customers.  PayChoice&#8217;s customers recieved a phishing attack that was personalized with their PayChoice information.  The phishing email contained browser and other client side exploits and also directed them to install a malicious plugin.  The hybrid attack was designed to maximize the chances of owning the phished endpoint with the TrojanDownloader:Win32/Bredolab.X trojan.  To add insult to injury. Customers who thought they were protected by endpoint security most likely weren&#8217;t.  Only 5 of 41 AV scanners on VirusTotal.com detected the malware.</p>
<p>PayChoice&#8217;s customers are the ideal target for this type of multistage attack.  The user that logs into an online payroll service is likely to be the user that logs into a business online banking account since payroll and banking go together in many companies.  We can expect to see more attacks like this in the future. </p>
<p>Companies should put restrictions on the endpoints used to conduct online business.</p>
<ul>
<li>A known set of software required for business should be running.</li>
<li>The machine should not be used for email.</li>
<li>An up to date browser should be used with no plugins.</li>
<li>JavaScript should be limited to a white list of trusted sites that require it.</li>
<li>The machine should only be able to connect to a known set of web sites.</li>
</ul>
<p>Two factor authentication and up to date anti-virus software is not enough.  Limiting the functionality of the endpoint is the only way to be secure. Be on the lookout for anti-malware companies offering a quick fix for this problem. Remember that only 5 out of 41 AV scanners found the PayChoice phishing malware and the percentage of malware detected by AV is decreasing over time.</p>
<p></br></p>
<h3>Veracode Security Guides</h3>
<div style="margin-left:15px;">
<a href="http://www.veracode.com/security/csrf">CSRF</a><br />
<a href="http://www.veracode.com/security/xss">XSS</a><br />
<a href="http://www.veracode.com/security/sql-injection">SQL Injection</a></div>
<h3>Data Security Resources</h3>
<div style="margin-left:15px;">
<a href="http://www.veracode.com/security/data-security">Data Privacy</a><br />
<a href="http://www.veracode.com/security/data-loss-prevention">Data Loss Prevention</a><br />
<a href="http://www.veracode.com/security/data-breach">Data Breach</a></div>
]]></content:encoded>
			<wfw:commentRss>http://www.veracode.com/blog/2009/10/stealing-pii-is-so-2007-they-want-your-endpoint/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

