Don't Click That Link!

Why did you just click that link? Most likely you have came to this site by clicking a link from another site. Why did you do that? Did you trust the person who sent you the link? Did you click a link from twitter, facebook, or an email someone sent you?

When you click a link, you are telling your browser, "I trust this person." However, this is not the way we use the internet. We click on links all the time. We click on links from "untrusted" sources. We click links from people we don't know and we even click on URL's that have been modified. On Twitter, a person is much more inclined to click the shortened link http://bit.ly/5hXRW then they are to click http://somewherebank.com/transfer.jsp?amount=1000&to_account=56777564. Even though the shortened link could redirect to the somwherebank.com site.

But, why would someone trick you into clicking a cleverly disguised link? The site that you are redirected to may seem harmless. It could also be extremely malicious.

What happens if this page, (the one you are currently viewing), was filled with Cross-Site Request Forgery (CSRF) links? This web page could be setup with all types of malicious intent. However, you didn't know that when clicking the link. Now, it is too late.

If this site did have Cross-Site Requests, I could do things such as:

• Change the password on your facebook account
• Transfer the money from your online bank account to another account
• Enact trades from a financial institution such as E*Trade

The sites that I exploit would have to be vulnerable to CSRF. But researchers, such as Mike Bailey and Russ McRee, are constantly finding CSRF vulnerabilities in web applications.

An example of how clicking links from untrusted sources is never good was demonstrated in Billy Rios and Nitesh Dhanjani, Bad Sushi talk. In their presentation they described sending phishers a word document stating their account numbers were inside. They sent this email to 25 known phishers. 10 of the phishers opened the word document and were presented with this. In additon, there was another link that said, "Actually, my account information is here." 3 of the 10 clicked on that link. Even the phishers click links they shouldn't.

What should be done? Who knows. It is human nature to trust people and we can't get things done if everytime someone sends us a link we open up a VMware image to view a link. So continue using the Internet the way you have been and remember, "These aren't the droids your looking for."

Buzzword: FUD - Fear, Unccertainty, and Doubt

FUD is becoming a very common acronym to hear in security circles. The acronym FUD has been popping up on Blog postings, emails, tweets, and at security conferences.

FUD is an acronym that stands for Fear, Uncertainty, and Doubt. The phrase describes marketing schemes that are focused on using Fear, Uncertainty, and Doubt to sell a product. Good example of FUD are sensational headlines such as, "Conficker Now Instructed to Steal" or more famously, "Hackers Can Turn your Home Computer into a Bomb!"

With FUD campaigns the marketer is attempting to use FUD to sell something. This marketed item could be a "security" product or FUD can be used to create a buzz around the "item at hand."

One quick way to identify FUD is spotting a headline or article that is greatly sensationalized, has a lot of speculation, or makes gross generalizations. The other critical factor in FUD is there is a lack of information in the article. FUD articles clearly point out the problem, but fail to point out how the author arrived at this conclusion.

Fear, Uncertainty, and Doubt pray on human emotions and marketing campaigns that exploit this will not be going away any time soon.

Graph Theory: Analyzing Social Networks

Social networking applications are among the most popular websites that are used on the Internet. Facebook.com and myspace.com are both in the top 20 most visited pages on the internet. According to Alexa, 17% of global internet users visit facebook.com on a daily basis.

How can attackers use the abundant amounts of information that is available on these websites to aid in their attacks?

One method is by analyzing a victims social network using network analysis.

Network analysis is a way to infer information from the social connections that someone makes. An attacker could use a social applications data set to:

• identify positive and negative relationships
• identify their victims mood
• identify individuals that are most influential in a group

By assigning people and organizations to nodes and linking nodes based on relationships, attackers can begin to infer information from these social graphs.

Who is the Most Influential?
It is beneficial for an attacker to know who is the most influential person in their victim's social network. Constructing a malicious instant message or email that requires user intervention (think Reflective Cross-Site Scripting) will have a higher success rate, if it is sent from the victim's most influential friend.

In order to analyze the victim's social network from an influential perspective, the attacker begins by constructing a graph with the victim in the center and each of the victim's friends as node off of the victim.

In this example, Sam is the attacker's target. Sam has five friends, Alice, Bart, Charlie, Dave, and Ed. This would create a star graph that would look like this.

The next step is for the attacker to analyze the connections between Sam's friends. The attacker identifies that Alice communicates with Bart on a regular basis, so a link is made between Alice and Bart.

It is also easier for the attacker to understand who is the most influential by assigning a value to each vertice. Alice and Bart's vertice would change from 0 to 1, since they know one of Sam's friends. In this example, we have made the vertice larger and assigned it a number. Once the social network is analyzed the attacker will have a graph similiar to this.

Since Ed knows 3 of Sam's friends, it can be infered that Ed is the most influential in Sam's network. If an attacker wanted to send a malicious instant message or email to Sam, the attacker would have the highest rate of success if the malicious message was from Ed.

This is a simple example. In reality, social networks are vastly more complicated. However, with the use of certain API's an attacker could use network analysis to his benefit.

Quantifying XSS - Why Merchants Won't Fix Their Cross-Site Scripting Vulnerabilities

From previous articles, you should be aware that Cross-Site Scripting (XSS) is an issue that is not going away any time soon.

Unlike it's buzzword predecessor, SQL injection, Cross-Site Scripting is a difficult vulnerability to quantify. What is the risk of not remediating a Cross-Site Scripting vulnerability in your web application?

If you have recently gone through a web application assessment, the report most likely indicates the risk factor of having XSS is high. But, what evidence does the report writer have to support this statement?

Basic security teaches us that risk can be quantified as:

Risk = (Probability of the event occurring) x (The impact if the event occurs)

To support the consultants statement, we would need to identify the probability of an attacker using a Cross-Site Scripting vulnerability as an attack vector and what the impact is, if the user is exploited.

Impact
It is important to realize that XSS is a means, not an end. XSS is simply a transportation mechanism. It is used to facilitate the actual attack which could be system compromise or stealing a users session. The only limitation on XSS is that it operates in a browser enviroment.

Do to the numerous things an attacker can do with XSS, it is hard to quantify an impact for all XSS vulnerabilities. Since XSS has different severities in regards to impact, an orginization should always choose the impact that is most severe. In other words, the worst-case-scenario.

If a user is exploited through an XSS attack, an orginzation can assume the attacker is doing the most damaging thing imaginable. Therefore, if a user is compromised from XSS, the impact is high.

Probability of the Attack Occuring
We have now identified that the impact of Cross-Site Scripting is high. But, what about the probability of it actually occuring?

It is difficult to find evidence of people using Cross-Site Scripting as an an attack vector? There are cases where XSS was used, in conjunction with SQL injection, to insert an offsite iframe into a web page in order to attempt a traditional overflow. Should these attacks be included into the equation for probability of it happening? Since it can be argued that these attacks used SQL injection, and not XSS for propigation, these attacks need to be excluded.

The only evidence I can find is Verizon's 2009 Data Breach Investigation Report. That docuement however, doesn't go into much detail about the specifics of the XSS attack.

Due to the lack of overwhelming evidence, XSS currently is not a common attack method. The probability of a Cross-Site Scripting attack occuring is low.

Cost-Benefit Justification of Fixing Cross-Site Scripting
Since it is difficult to quantify the cost of having an XSS, it is just as difficult to do a cost-benefit analysis on fixing XSS vulnerabilities.

Why should merchants spend money on remediating their XSS vulnerabilities when there is no supporting evidence of attacks occuring?

Until more web applications are compromised through XSS vectors and there is more evidence to support this happening, not much security budget will go towards remediating Cross-Site Scripting vulnerabilities.

Top Five Web Application Security Blogs

Today, I thought I would post great resources for information. If you want to be good at security, it means you need to be well read.

Here are the top five web application security blogs in no particular order.

• Jeremiah Grossman - Probably the most read web application security blogger. Jeremiah reads all of the material so you don't have too.
  
• Rsnake / Robert Hansen - The other most read web application security blogger. Interesting Note: Graduated my alma mater.
  
• Holistic InfoSec - Russ McRee's blog. Russ puts people on the stove. He posts are controversial and exciting. According to ISS, Russ was one of the Top Vulnerability Discoverers in 2008. Keep an eye on him, it is interesting to see what he will do next.
• Billy Rios - Also known as the XS-Sniper! Billy is behind some of the most innovative research as of late. He is the man behind Gifars and URI overflows. He is also known to smuggle olives on occasion.
• Nitesh Dhanjani - Although he covers a wide range of topics outside of web application security, Nitesh continually blogs about topics that are thought-provoking.