BsidesSF was an amazing event, and I congratulate Mike Dahn for putting together an event that ran super smooth.

All of the presentations at BsidesSF were cutting edge and highly informational. There were two presentations, that in my opinion, clearly stood out.

Gunter Ollman – Your Computer is Worth 30 Cents

Gunter Ollman’s presentation explained how botnets and malware has changed the state of penetration tests.

Penetration tests are sometimes misunderstood and it is important to understand what a “real” penetration test is. Pen tests are supposed to replicate real attacks that an attacker would use to penetrate your network.

Gunter explains how these penetration tests have evolved over time:

In 2000, the easiest way to break into a network was to submit a job application, get the job, plug into the network, own it, and never show up the next day.

In 2005, the easiest way was to hand out USB drives in the parking lot that called home.

Now, the easiest way is to purchase machines inside of the corporation that already belong to a botnet.

I think this was a very eye opening presentation and although we have seen startup companies focused on  protecting your corporate assets from becoming part of these botnets, I think we will begin to see startup companies focused on removing your corporate assets from botnets.

Tim Keanini – Computing Risk without Numbers: A Semantic Approach to Risk Metrics

The other talk that was very ground-breaking was presented by Tim Keanini, CTO of Ncircle. TK presented on identifying risk through the use of semantic language. This is an alternative and interesting approach to risk management, that uses semantic language to rate the risk of assets to a network.

After the presentation most people explained they would need to watch TK’s presentation three or four times to extract all of the information out of it. I completely agree and am thankful that all of the presentations have been archived.

No related posts.

I recently had the opportunity to speak at BsidesSF last week. This was an awesome experience and I highly suggest everyone attend one of the next Bsides coming up at Boston, Austin, or Las Vegas.

I presented, “Security? Who Cares!” This talk focuses on the way the security community views their beliefs and how privacy is dying. Feel free to leave your comments after viewing it. It takes about 25 minutes to watch.

Related posts:

1. OWASP Top 10 Presentation
2. BsidesSF – An Alternative Conference

Photo: jurvetson

While recently using Basecamp, a 37Signals product, I was writing a collaborative document using Writeboard and noticed that I could insert greater than (<) and less than ( > ) tags in the document.

Writeboard uses a simpler form of editing, similar to wiki’s. If you want to make the line bold, you can use *bold* instead of standard HTML, <b>bold</b>. However, Writeboard allows the user to markup the text either way. Well, this was a product that I needed to QA. I quickly inserted a script source tag, saved the Writeboard, and to my surprise, the script src tag fired.

Upon identifying this I then attempted Cross-Site Scripting 101: <script> alert (123) </script>

That also was successful! I was rather blown away that a product who is used by, Adidas, National Geographic, Kellogg, and USA Today, has never tested (or accidental) found this functionality.

I reached out to the security team at 37Signals, and the issue has been fixed and I have been given a nice shout out on the security page.

I initially thought, “This is what happens when start-ups attempt to rush products to market without doing sanity checking on what they are doing.”

However, upon further research, I read the excellent “book” Get Real by Jason Fried the Founder of 37Signals.  These essays explained why this type of vulnerability lived in this system. 37Signals follows a process of quick deployment, development, with fast subsequent revisions. Their concept is get a product out that people can immediately begin using.

Cross-Site Scripting in 37Signals

While I agree, this is a great way to develop SaaS products, it is difficult to see how security can come into play with this type of software delivery model. In one essay, Fried, explains the necessity of getting well rounded individuals (generalists) and avoid hiring specialists. Does this mean more software developers should be interested in security?

This is yet to be seen, and I think it is dependent upon your product. There is something however that other companies can learn from 37Signals.

37 Signals did the following when it came to me finding this bug:

• I initially reached out to Jason Fried on Twitter, and he got back to me in less than an hour.
• They had a simple way for me to contact them.
• After reaching out to them, they immediately acknowledged the receiving of my message.
• They fixed the issue in 4 days.

I commend 37Signals for fixing the issue as fast as they did. Typically, when these issues are reported to companies, they are typically forwarded to the trash.

Related posts:

1. XSS – Understanding Cross Site Scripting
2. Quantifying XSS – Why Merchants Won't Fix Their Cross-Site Scripting Vulnerabilities
3. Cross-Site Request Forgery (CSRF)

Photo: malik ml williams

This is the last-part in a ten-part-series describing the OWASP Top 10. (See the entire OWASP Top 10)

What is the problem with Failing to Restrict URL Access

A common problem in web applications, failing to restrict URL access typically happens when a page doesn’t have the correct access control policy in place. Unauthorized users are able to view content that they shouldn’t have the ability to view.

Having these vulnerabilities in your application exposes privileged functionality to unauthorized users. It can also create a problem with your record trails. If users can access records without being authenticated the chain of custody is completely broken, preventing good auditing from taking place.

Failing to restrict URL access can also lead to problems with bypassing session management, another of the OWASP Top 10.

An Example of Failing to Restrict URL Access

Developers attempting to hide functionality from a user by creating “hidden” pages can create a failure to restrict URL access situation.

Hidden pages are defined as pages that don’t have a link pointing to them, preventing web crawlers, such as Google, from indexing them. Some developers believe that these pages will never be found by anyone who doesn’t know the exact URL. However, attackers typically find these pages through forceful browsing and the access controls on these pages tend to not be restrictive.

Another example of a page that can have this type of vulnerability is one where all of the privileges are checked client side but not server side. Attackers using personal proxies can bypass these client-side privileges and access functionality not intended for them to access.

How Do You Restrict URL Access

Most of these problems arise from a change in policy happening on paper, but not being implemented thoroughly across the application.

Restricting URL access correctly takes careful planning by the developer and the supporting organization. Organizations can follow some simple rules that will help them in preventing this vulnerability.

• Developers should never assume users will be unaware of hidden functionality.
• Administrators should block access to all file types that the application doesn’t serve.
• Architects should develop an access control matrix, helping them to prevent unauthorized users from accessing authorized content. This should be done for every URL and business function of the application.

Related posts:

1. Broken Authentication and Session Management
2. Cross-Site Request Forgery (CSRF)
3. Insecure Direct Object Reference

Photo: Rionda

While attending OWASP AppSec DC this week, I was able to see the preliminary release of the OWASP top 10 for 2010. This is the first release candidate and the 2010 top 10 are now available for public comment. We will soon see what the security community thinks of it, but OWASP is hoping for an finalized release in the early first quarter of 2010.

For regular readers, you will not see much new on the OWASP top 10 2010. The main change is the order, or rather priority, of vulnerabilities has been changed. While the OWASP Top 10 – 2007 list focused on the top 10 vulnerabilities in web applications. The 2010 top 10 have been re-clarified to reflect the Top 10 Application security risks to an organization.

The 2007 list also focused on the frequency of the occurrences of the vulnerabilities in the web application. However, the OWASP Top Ten 2010 list is prioritized based on an estimated risk to the organization.

Risks Added to the OWASP 2010 Top 10

The new vulnerabilities are Security Misconfiguration (A6) and Unvalidated Redirects and Forwards (A8). I will address these two risks in future articles.

Vulnerabilities Removed from the OWASP 2010 Top 10

Since two risks were added, the OWASP had to replace vulnerabilities that were already on the list. These vulnerabilities are Malicious File Execution and Information Leakage and Improper Error Handling.

Malicious File Execution has been removed due to the reduction of how prevalent this vulnerability is now compared to 2007. OWASP also states that PHP is being shipped with more default security built-in. This is why it has been removed from the list.

Information Leakage and Improper Error Handling has been removed from the typical low impact of disclosing stack traces and error messages to the user. (Personally, I disagree with this.)

OWASP Top 10 2010 RC1

A1 – Injection
A2 – Cross-Site Scripting (XSS)
A3 – Broken Authentication and Session Management
A4 – Insecure Direct Object References
A5 – Cross Site Request Forgery (CSRF)
A6 – Security Misconfiguration
A7 – Failure to Restrict URL Access
A8 – Unvalidated Redirects and Forwards
A9 – Insecure Cryptographic Storage
A10 – Insecure Communications

We shall see in the next few months what the community thinks of these changes.

Related posts:

1. OWASP Top 10 2007
2. Information Leakage and Improper Error Handling
3. OWASP Top 10 Presentation

Photo: jaeming

Being security aware and security conscious often boils down to understanding three key concepts that are common to risk management

These security concepts have been around since the inception of information security. Although, these are high-level generalizations, they are important for everyone to know about.

This article is focused on understanding how each of these apply to information systems.

Confidentiality

Confidentiality loss happens when information can be viewed (read) by individuals who shouldn’t access it.

Loss of confidentiality can happen physically or electronically.

Electronic confidentiality loss can happen when the clients and servers aren’t encrypting their communications. This allows malicious entities to view private communications.

Physical confidential loss can happen through social engineering or through theft. This typically means having laptops stolen.

Integrity

Integrity loss happens when information is modified without the modification being authorized. This doesn’t mean that an unauthorized party has to cause the integrity loss to happen. The integrity loss due to an authorized party doing something they shouldn’t. An example would be a system administrator deleting an account record they weren’t authorized to delete.

Integrity Loss can happen either accidentally or through malicious intent. Malicious integrity loss can happen when a user purposely adds, deletes, or modifies database records. This can occur either through an authorized party (someone who has the access to actually modify the record) or by an unauthorized party when the user has access that they shouldn’t have.

Accidental integrity loss happens when a system modifies or deletes records that it shouldn’t. This can happen when a virus infects a system or when a user does something that he didn’t intend to do. This is often why systems will verify that you want a file deleted, before it actually does so.

Availability

Availability is the simple idea that when a user or system attempts to access something, it is available to be accessed. This is extremely important for mission critical systems. Availability for these systems are so critical that most companies have business continuity plans (BCP’s) in order for there systems to have redundancy.

Just like confidentiality and integrity loss, availability loss can happen by accident, a car crashing into a fiber pole disabling access to a system, or through malicious intent, such as a Denial-of-Service attack.

Related posts:

1. Insecure Communications

Photo: Tim Caynes

In the book, Hacking: The Next Generation, I cover a topic referred to as DNS cache snooping. Cache snooping is not a new attack and has been around for quite a while [PDF]. However, I couldn’t find a good piece of code that would interrogate DNS servers, so I created code to do it.

I put it in Appendix B in the book, but figured it would be nice to have some place to copy & paste it.

Let me know if you have any questions or comments. Have Fun!

Cache_Snoop.pl

#!/usr/bin/perl
# cache_snoop.pl
# Developed by: Brett Hardin
$version = “1.0″;
use Getopt::Long;

my $options = GetOptions (
“help” => \$help,
“save” => \$save,
“dns=s” => \$dns_server,
“ttl” => \$ttl_option,
“queries=s” => \$queries
);

if($help ne “”) { &Help; }
if($dns_server eq “”) { die “Usage: cache_snoop.pl -dns -queries \n”; }
open(FILE, $queries) or die “Usage: cache_snoop.pl -dns -queries \n”;

@sites;

#FIRST RUN IS FOR FINDING OUT DEFUALT TTL
if($ttl_option ne “”) {
print “Finding Default TTL’s…\n”;
&default_TTL;
}

for $site (@sites) {
chomp($site);
$default_TTL = $TTL_list{$site};

if($site =~ /^\#/) { print $site . “\n”; next; }
if($site =~ /^$/) { print “\n”; next;}

$results = `dig \@$dns_server $site A +norecurse`;

if ($results =~ /ANSWER: 0,/) {
print “[NO] ” . $site . ” not visited\n”;
}
else {
@edited_result = split(/\n/, $results);
@greped_result = grep(/^$site\./, @edited_result);
@A_Broke = split(/\s+/, $greped_result[0]);
$TTL = $A_Broke[1];

print “[YES] ” . $site . ” ($TTL”;
if($ttl_option ne “”) {
&timeLeft;
print “/$default_TTL) – Initial Request was made: $LAST_VISITED\n”;
}
else { print ” TTL)\n”; }

if($save ne “”) {
print $results; die;
open(OUTPUT, “>$site.DNS.txt”);
print OUTPUT $results;
close(OUTPUT);
}
}
}

sub timeLeft{
$seconds = ($default_TTL – $TTL);
@parts = gmtime($seconds);
$LAST_VISITED = “$parts[7]d $parts[2]h $parts[1]m $parts[0]s”;
}

sub default_TTL {
# This function returns the default TTL
# To do this, you need to find the DNS server from the root DNS server
# then query that DNS server for the site you are looking for, it will return the default TTL
%DNS_list = ();
%TTL_list = ();

# Find the NS for the site
for $site (@sites) {
if($site =~ /^\#/) { next; }
if($site =~ /^$/) { next;}

chomp($site);

#QUERY the TLD domain
$query_result_1 = `dig \@a.gtld-servers.net $site`;
@edited_query_1 = split(/\n/, $query_result_1);
$found = 0;

# Find the DNS server
for $each (@edited_query_1) {
if ($found == 1) {
@A_Broke = split(/\s+/, $each);
$root_DNS = $A_Broke[0];
last;
}
if($each =~ /ADDITIONAL SECTION:/) { $found = 1; }
}
$DNS_list{$site} = $root_DNS;
}
print “Done with Name Server lookup…\n”;;

# Find the TTL from the default NS server.
foreach $site (sort keys %DNS_list) {
#print “$site: $DNS_list{$site}\n”;
$DNS_SERVER = $DNS_list{$site};

#QUERY the TLD domain
$query_result_2 = `dig \@$DNS_SERVER $site`;

@edited_query_2 = split(/\n/, $query_result_2);
$found = 0;

# Find the DNS server
for $each (@edited_query_2) {
if ($found == 1) {
@A_Broke = split(/\s+/, $each);
$default_TTL = $A_Broke[1];
last;
}
if($each =~ /ANSWER SECTION:/) { $found = 1; }
}
#print $site . ” default TTL: $default_TTL\n”;
$TTL_list{$site} = $default_TTL;
}
print “Done with TTL lookups…\n”;

foreach $site (sort keys %TTL_list) {
print “$site – $TTL_list{$site}\n”;
}
}

sub Help {
print “\n”;
print “#################################\n”;
print “# #\n”;
print “# cache_snoop.pl v$version #\n”;
print “# #\n”;
print “#################################\n\n”;
print “usage: $0 -dns -queries \n”;
print “\n”;
print “purpose: Exploit a DNS server that allows 3rd party queries to determine what sites\n”;
print ” the DNS servers users have been going to.\n”;
print “\n”;
print ” Options:\n\n”;
print ” -help What your looking at.\n”;
print ” -dns [required] DNS server susceptible to 3rd party queries\n”;
print ” -queries file with the queries you would like to make [Default: queries.txt]\n”;
print ” -save Save the DNS responses that are received to individual text files.\n”;
print ” -ttl Will lookup the default TTL’s and comparing them with what the server has.\n”;
print “\n”;
print “Sample Output:\n”;
print “[NO] fidelity.com not visited\n”;
print “[YES] finance.google.com (165020) visited\n”;
print “[Visited] site (TTL)\n”;
print “\n\n”;
exit;
}

No related posts.

I recently did a presentation on the OWASP Top 10 for SecurityStreams. Nitesh Dhanjani of SecurityStreams was nice enough to allow me to embed the videos of the presentations on this site.

If you are new to the OWASP Top 10, I highly suggest to watch this presentation, it is about 45 minutes and should give you a high level understanding of all the OWASP Top 10.

If you are an executive or don’t have time to watch the full presentation, then I suggest watching the 10 minute executive presentation.

Make sure to watch them in HD (Upper right hand corner of the videos). Let me know your thoughts and comments.

OWASP Top 10 – Full Presentation

OWASP Top 10 – Executive Presentation

Related posts:

1. OWASP Top 10 2007
2. Insecure Direct Object Reference
3. XSS – Understanding Cross Site Scripting

Photo: Jason Arends

This is the ninth-part in a ten-part-series describing the OWASP Top 10. (See all the OWASP Top 10)

What are Insecure Communications

Insecure communications is when a client and server communicate over a n0n-secure (non-encrypted) channel. By doing this, the developer is ensuring that their communication channel can be viewed by eyes they didn’t intend.

Failing to securely communicate server-to-server and server-to-client helps attackers to intercept sensitive transactions. Attackers do this by using man-in-the-middle attacks, a post for another time. Not communicating securely breaks down confidentiality and integrity.

Developers fall into communicating insecurely when they:

• Don’t secure their client-to-server connections.
• Don’t secure their server-to-database connections.
• Don’t secure other back end connections that pass sensitive data.

An Example of Insecure Communications

Assume a developer has written an application that takes input from a user and stores it in a database that is located on another network segment.

If the developer fails to use SSL between the web server and the user, then he has an insecure communications channel between the user and the web server. (Client-to-server connection)

If the developer fails to forget to encrypt the connection between his web server and the database, then he is failing to secure the server-to-database connection.

How Do You Prevent Insecure Communications from Occurring in your Web Application

To prevent insecure communications from occurring, the first step is to make sure the security architect has formulated secure methods of communication between the clients and servers. The security architect can limit the connections they need to look at by only reviewing which servers and clients pass sensitive data.

Keep in mind, most of these architectures will fail to forget to encrypt data on back-end connections, such as database connections. Just because the data is now behind a firewall doesn’t mean it should be passed in clear-text.

To verify insecure communications won’t happen on your network:

• Make sure all client-to-server connections are encrypted with SSL.
• Verify that server-to-database connections are encrypted.
• Verify that any other areas in the design where sensitive data is passed is done so in a secure way.
• Keep developers in a security mindset. Developers should never assume their application is sending their information securely. Developers should always assume that any communications that are being made are done insecurely.

Related posts:

1. Insecure Cryptographic Storage
2. Insecure Direct Object Reference
3. Broken Authentication and Session Management

Photo: Brajeshwar

If you are a developer, I guarantee that you have written insecure code. Universities train people to write code, but very little time is taken to help them focus on writing secure code.

As with anything, being able to identify security vulnerabilities and writing code securely takes practice. But how does a developer, who is already overburdened with enough work, find the time or resources to help him identify security vulnerabilities?

This is where spot spotthevuln.com comes in.

The purpose of the project is two fold, help developers write better code by enabling them to identify insecure code and hopefully work the project into teaching curriculum’s at colleges and universities in order to help new developers write more secure code.

Here is how the site works. On Monday at 8:00am PST, a piece of vulnerable code is posted. An business week is given to people in order to attempt to identify the vulnerability in the code. On Friday at 8:00am PST, the code fix is shown with a description of what was wrong with the code. All of the vulnerabilities are taken out of open source projects in order to show developers “real-life” scenarios. The fixes are the fixes that were actually deployed.

The whole point of spotthevuln.com is to help developers identify poor development choices when programming. What are your thoughts? Do you think this will help developers? If you are an instructor and would like to work spotthevuln.com into your curriculum, I suggest for you to reach out to spotthevuln.com.

The more developers know about security, the better off we all are.

No related posts.