Information Gathering: A Way to Identify Who Uses Social Sites

Posted by Brett Hardin on 26th May 2009

Reading time: 1 – 2 minutes

Information Gathering: A Way to Identify Who Uses Social Sites

Photo: Pro-Zak

Information gathering on targets is key for attackers. They need to understand their targets to construct more successful attacks.

Recently, I came across http://namechk.com/ I was blown away with the amount of information this site reveals.

The site promotes itself as a way to “check to see if your desired username or vanity url is still available at dozens of popular Social Networking and Social Bookmarking websites.”

Information Gathering: A Way to Identify Who Uses Social Sites

From an attackers standpoint, lets say I want to identify all of the resources that Jeremiah Grossman, the CTO of WhiteHat Security uses. I simply type in his blogspot id, “jeremiahgrossman” and I identify that in addition to blogspot he also posts to delicious and youtube. This is great!

For an attacker, this resource provides a way to identify additional paths of research.

26May

XSS – Understanding Cross Site Scripting

Posted by Brett Hardin on 21st May 2009

Reading time: 4 – 6 minutes

XSS   Understanding Cross Site ScriptingXSS   Understanding Cross Site ScriptingXSS   Understanding Cross Site Scripting

If it hasn’t already, Cross-Site Scripting (XSS) will soon be replacing SQL injection as the new buzzword in the security sector. XSS will continually be a topic on this blog as well as others [1],[2],[3],[4]. Due to this fact, I think a primer would be a good idea for those who don’t know or understand this problem.

Many articles have been written about Cross-Site Scripting and if you want to have a better understanding of the problem, I suggest you read those documents (Links at the bottom of the post).

Basically, There are 3 types of Cross-Site Scripting:

  1. Stored/Non-Reflective/Persistent Cross Site Scripting (User visits the XSS’ed page)
  2. Non-Stored/Reflective/Reflected Cross Sited Scripting (User clicks a link that embeds the script into the loaded page)
  3. DOM Based Cross Site Scripting (please read this article)

All of these names make it confusing for a first timer to understand XSS. There really should be a better web application security standards organization. Here is a breakdown of Persistent XSS and Reflective XSS. These are the big two that most people talk about when they are referring to Cross Site Scripting. If you understand these well, you will be able to participate in 90% of XSS conversations.

Persistent Cross-Site Scripting
Persistent XSS is arguably more dangerous than reflective XSS. This attack embeds the malicious script permanently into the web application. The script will then wait until people access the page it is located on.

Here is an attack using Persistent Cross-Site Scripting:

  1. The victim visits a website they trust, amazon.com.
  2. A script has been inserted by an attacker on a page they happen to visit while on amazon.com.
  3. The script executes in the context of amazon.com.
  4. The victim is then compromised.

Note: Obviously, someone can increase the chances of the victim visiting this page (step 2) through social engineering, phishing, etc.

Reflective Cross-Site Scripting
These are the ones the media usually reports on. [1],[2],[3]. In this attack, some type of social engineering is involved for the attack to be successful.

Here is an attack, using Reflective Cross-Site Scripting:

  1. The victim gets an email/Instant Message that contains a link.
  2. The victim clicks the link. (Requires User Intervention)
  3. A script has been inserted by an attacker on the page they then visit.
  4. The script executes in the context of that site.
  5. The victim is then compromised.

Note: I want to reiterate that this attack requires some type of user intervention (step 2).

Why is Cross-Site Scripting Bad?
Cross-Site Scripting can lead to all sorts of different exploits, including system compromise. For an attacker to do this, they need to break out of the browser’s context. We have seen examples that breaking out of the browser is not that hard to do.

In addition, an attacker can also establish a bi-directional channel using iframes. This creates a man-in-the-middle attack. The attacker can then intercept key strokes, use the victim as an intranet portscanner, and even stealing creditials. The attacker is only limited by their knowledge of scripting.


XSS   Understanding Cross Site Scripting

Example of a bi-directional channel

Hopefully, this gives you a better understanding of Cross-Site Scripting. Feel free to leave comments if you don’t understand something and I will address it in the article.

Additional Resources:
Cross-Site Scripting (XSS) FAQ
OWASP Guide to XSS
XSS tutorial
XSS Video Tutorial (via youtube)
XSS Attack API

21May

5 Key Factors of Complexity

Posted by Brett Hardin on 20th May 2009

Reading time: 2 – 3 minutes

5 Key Factors of Complexity

Brian J. Truskowski, General Manager of Internet Security Systems (ISS), gave a keynote presentation at RSA 2009. His talk touched on an interesting topic that he referred to as the “5 Key Factors of Complexity.”

He identifies that the key cause of compromise is human nature; the ability that humans are susceptible to social engineering. Instead of focusing on securing systems, Mr. Truskowski argues that we should design systems that are “resistant to human frailty.” He goes on to state, that designing these systems (by reducing complexity) is difficult.

According to Mr. Truskowski, the 5 key factors of complexity and the key to designing these systems are:

  1. Threats
  2. Compliance
  3. Technology
  4. Economics
  5. Business Needs

Contrary to security, Businesses have to keep focused on all of these factors or they will be unsuccessful. Vendors however, are according to Mr. Truskowski, only focused on one of these factors… Threats. He argues, If an enterprise doesn’t focus on compliance, they are fined. If a business doesn’t focus on business needs, the business can’t change.

“It’s like building the titanic. The ship’s designers optimized around being able to withstand collisions at the sacrifice of maneuverability. There have been many theories over the years over why the Titanic sank, from Brittle steel to sub-standard rivets. But, in reality, it is obvious why the Titanic sank. It couldn’t get out of the way of the iceberg. The Titanic’s designers focused on size, strength, resilience, and luxury but not on maneuverability.”

I think Mr. Truskowski’s talk was the hidden gem at RSA. It is an interesting idea for security vendors to begin focusing on things other than threats. Of course, if the idea gets legs, it will be 10-15 years before any change occurs. It is great to see people thinking holistically about security.

The video/webcast can be seen here: (5 Factors of Complexity starts at 19:49)

20May