Thursday, August 21, 2008

BSQL (Blind SQL) Hacker

This is definitely a tool to checkout....

BSQL (Blind SQL) Hacker is an automated SQL Injection Framework / Tool designed to exploit SQL injection vulnerabilities virtually in any database.

BSQL Hacker aims for experienced users as well as beginners who want to automate SQL Injections (especially Blind SQL Injections). It allows metasploit alike exploit repository to share and update exploits.

http://labs.portcullis.co.uk/application/bsql-hacker/

Tuesday, August 12, 2008

Patience Pays Off for Hackers in Web Security War

The hacker group behind the Coreflood Trojan has learned that patience pays, as it has stolen at least 463,582 user names and passwords while flying under the radar. At Black Hat, SecureWorks Director of Malware Research Joe Stewart discussed his research on the gang and how it has gone undetected.

LAS VEGAS—The creators of the Coreflood Trojan have managed to stick their digital hands into the pockets of victims for years. And they have done it largely under the radar, according to research revealed at the Black Hat conference here Aug. 6.

[ Read Article ]

Friday, August 8, 2008

Clear Program >= "Pathetic"

I must say, I'm completely blown away by what has happened with the Clear Program.  For those of you who do not know what/who Clear is....

Clear® is the fast pass for airport security. Clear members are pre-screened and provided with a high-tech card which allows them to access designated airport security fast lanes nationwide. Clear members pass through airport security faster, with more predictability and less hassle.

Basically, they pre-screen you through TSA and give you a card to carry around so you don't have to wait in line with all of the other yahoos.  So let's take a look at the recent email that just came out. First line of the email ...

We take the protection of your privacy extremely seriously at Clear. 

This isn't giving me a warm feeling.  Next?

Before we could send out that notice, the laptop was recovered. And, we have determined from a preliminary investigation that no one logged into the computer from the time it went missing in the office until the time it was found. Therefore, no unauthorized person has obtained any personal information.

Okay....this isn't getting any better.  Next?

We are sorry that this theft of a computer containing a limited amount of applicant information occurred, and we apologize for the concern that the publicity surrounding our public announcement might have caused. But in an abundance of caution, both we and the Transportation Security Administration treated this unaccounted-for laptop as a serious potential breach. We have learned from this incident, and we have suspended enrollment processes temporarily until all pre-enrollment information is encrypted for further protection. The personal information on the enrollment system was protected by two separate passwords, but Clear is in the process of completing a software fix - and other security enhancements - to encrypt the data, which is what we should have done all along, just the way we encrypt all of the other data submitted by applicants. Clear now expects that the fix will be in place within days. Meantime, all airport Clear lane operations continue as normal.

So .... as a security person, my first question would be -- HOW DID THIS COMPANY GET APPROVED TO OPERATE WITH TSA SENSITIVE DATA WITHOUT THE USE OF ENCRYPTION?  Yet another quote from the privacy policy....

TSA also conducts periodic audits to assure that we comply with their extremely high standards of data security.

Okay...I won't be hiring these idiots to perform my next vulnerability assessment...

We use encryption (a strong data coding process) for all program sensitive data communications. We apply firewalls to guard against outside intruders.

Wow!  Now this is really surprising to me -- yet another group of yahoos who think that a firewall is going to guard your applications from compromise.  Brilliant.

I'm sorry folks, but there are few moments in life when you really do find yourself speechless -- and well.....i guess this is one of them.  I must say - if this is the way these folks plan to do business, you might want to:  (a)  Not enroll or (b) enroll and quickly find yourself a good lawyer.

Ug.




Thursday, August 7, 2008

Cross Site Request Forgery and Same Origin Policy

There has definitely been an increase in the number of conversations around XSS and CSRF.  If you are looking to understand the basics of this attack, this is an excellent article....

Monday, August 4, 2008

OWASP 2008 NYC

The agenda for OWASP 2008 in New York has been posted.

OWASP Agenda

Should be a great show!

PHPCharset Encoder

This tool helps you encoding arbitrary texts to and from 65 kinds of charsets. Also some encoding functions featured by JavaScript are provided.

http://h4k.in/encoding/index.php

Tuesday, July 29, 2008

Microsoft Source Code Analyzer for SQL Injection tool

[RIP]The Microsoft Source Code Analyzer for SQL Injection tool is a static code analysis tool that helps you find SQL injection vulnerabilities in Active Server Pages (ASP) code. This article describes how to use the tool, the warnings that are generated by the tool, and the limitations of the tool. See the tool Readme document for more information.

[ Download

Saturday, July 26, 2008

Chronology of Data Breaches

This is a very interesting site which I feel provides some great information.  [RIP]  The Privacy Rights Clearinghouse (PRC) is a nonprofit consumer organization with a two-part mission -- consumer information and consumer advocacy. It was established in 1992 and is based in San Diego, California. It is primarily grant-supported and serves individuals nationwide.

Friday, July 25, 2008

Coolest thing since sliced cheese

If you're using Outlook, this is a really nice tool.  Finally....a tool that actually helps with email!




Tuesday, July 22, 2008

LifeCycle Security

A friend of mine [and group of renegade badasses] has started a new security conference based around Web Application Security.  If you are going to be at Blackhat next month, be sure to get hooked up for this show.  Also...if you are a member of OWASP, please feel free to use this invitation for free admission.

++++++++++++++++++++++

We would like to make a special offer to you and the people at OWASP as our way of thanking you for your support of our Lifecycle Security (web application security)Conference which we are holding the day after Blackhat-Vegas on August 8-9, 2008 at the Las Vegas Ceasar's Palace.
 
FREE ADMISSION (normal price is $350) for the first 100 people who register by sending an email to freeoffer@LifeCycleSecurity.com with:
 
  • Name:
  • Company:
  • Address:
  • E-mail:
 
We plan to open this up to other lists later in the week, but we want to give OWASP members "first shot" at the free admission.  (There are only 100 free admission tickets.)  Our goal is to create a community where Application Security professionals can share information on an on-going basis.
 
We have Ounce, Proactive, Price Waterhouse, Modsecurity, Microsoft, Safe Channel, OWASP and Verizon involved in our Penetration Testing, Policy/Compliance/Solutions and a Vendor Tracks.
 
Thanks once again for your support.
 
Dennis

Tuesday, June 24, 2008

Introducing HP Scrawlr

Interesting posting from the folks at HP Security Labs. Not sure if this is as capable as other SQL injectors already out there, but worth a look. Interesting note that they are packaging the Intelligent Engines on the backend with this tool.

[rip from HP blog site]

Scrawlr, developed by the HP Web Security Research Group in coordination with the MSRC, is short for SQL Injector and Crawler. Scrawlr will crawl a website while simultaneously analyzing the parameters of each individual web page for SQL Injection vulnerabilities. Scrawlr is lightning fast and uses our intelligent engine technology to dynamically craft SQL Injection attacks on the fly. It can even provide proof positive results by displaying the type of backend database in use and a list of available table names. There is no denying you have SQL Injection when I can show you table names!

  • Technical details for Scrawlr
  • Identify Verbose SQL Injection vulnerabilities in URL parameters
  • Can be configured to use a Proxy to access the web site
  • Will identify the type of SQL server in use
  • Will extract table names (verbose only) to guarantee no false positives
  • Scrawlr does have some limitations versus our professional solutions and our fully functional SQL Injector tool
  • Will only crawls up to 1500 pages
  • Does not support sites requiring authentication
  • Does not perform Blind SQL injection
  • Cannot retrieve database contents
  • Does not support JavaScript or flash parsing
  • Will not test forms for SQL Injection (POST Parameters)

You can download Scrawlr by visiting the following link:

https://download.spidynamics.com/products/scrawlr/

Thursday, May 8, 2008

A Risk Management-Based Approach to Web Application Security

At the end of the day, it all comes down to the Software Development Life Cycle (SDLC).  All vulnerabilities, big or small, can be traced back to a few lines of code written by a Developer who was hoping to achieve a bit of functionality.  According to Gartner, “By 2009, 80 percent of companies will have suffered an application security incident”.  The significance of this statement is astounding, due to the fact that most organizations rely heavily on their web presence for daily e-survival. 

While the majority of organizations have yet to merge their development and security processes, the move towards producing secure Web Applications is absolutely critical.  Unfortunately, most Development, Quality Assurance and Information Security teams operate in isolated communities and are rarely driven by the sentiment that security is fundamental for all parties involved.  Ultimately, the goal for any organization is to exist with a strong, well-defined process to the SDLC; however, development of such a program can be quite overwhelming - even for the most mature organizations.

Risk Management provides a structured process for identifying, assessing and quantifying risk for an environment.  By applying a Risk Management-based approach, your organization will be able to kick-start its program and achieve success through a more palatable set of goals.

Through this approach, several significant variables are quantified in an effort to understand the threat against your Web Application infrastructure.  These variables include:

  1. Asset Value (AV)
  2. Vulnerability Severity (VS)
  3. Likelihood of Threat (TH)
  4. Applied Countermeasures (CM)
  5.  Weighted Value for severity of vulnerabilities (WV)

The end-result of this program is to achieve an overall Risk Score (RS), which will aid in measuring compliance for your security policy and posture.  

Friday, May 2, 2008

Web Security 101

Over the past few weeks, I've read several posts from folks around the industry on how to secure web applications and I've read many interesting viewpoints. In my opinion, there are seven basic ideas that I believe any security professional should carry with them for web applications.

  1. Test Everything!

    The first concept for every security professional is to test everything. There is no amount of testing that can be accomplished -- test and simply keep testing. Just because you ran one scan with some tool and reviewed the results....testing should not end. What was once a very secure application could absolutely be compromised tomorrow.

  2. Secure the foundation

    Web Applications are nothing more than applications running on an Operating System so as such, it is still absolutely critical to secure the environment that they live in.

  3. Encrypt your data

    Use of data encryption may be utilized in a number of areas within your architecture. Whether you are using SSL certificates to data encryption on the database to the file system. I'm not sure I have the ability to recommend the "type" of encryption, but use of encryption is highly recommended.

  4. Input Validation

    With Application Security vulnerabilities, the majority of the vulnerabilites lie with poor input validation. Using input validation with all areas of the application is absolutely critical. If you have the ability to discover tools that will perform Input Analysis on your application prior to going live, I would highly recommend employing them. For those not familiar with Input Analysis techniques, these are solutions that will search for any component of your application where input is taken in (controls, form fields, etc) and assists with the validation of those points.

  5. Strong Authentication

    Authentication is key to applications and the use of strongly authenticated users or sessions is necessary. If strong authentication is not always an option, at the very least, please encourage your users (or security policy) to use strong passwords.

  6. Control Access to the Application

    As discussed in our AJAX post, validation of data is a very difficult aspect of security around your web application. The idea that we are able to validate every single request to your web application is sometimes difficult, however, it's my recommendation to your best with this.

  7. Session Management

    Session Management is yet another very serious aspect of securing your web application. Points of weakness for many web applications is found when developers make some great attempt to start creating their own session management schemes.  Three words that I have for you: 1) Cryptographically Strong, (2) Random, (3) strong protection.

Again, these are only a few thoughts that I'm throwing around here ....there are a thousand other things that could be considered so please don't consider this the almighty list [no flames, please].

Saturday, April 5, 2008

TRISC Conference

For those of you living around Texas, you might be interested in this conference. TRISC 2008 will be held April 21-23 with a theme of "Back to Basics: People, Processes & Products". It's being held at the Omni San Antonio Hotel at the ColonNade. Check out the website at:

http://www.trisc.org/

Mark your calendars for TRISC 2008!

Properties of Secure Hash Functions

A very interesting article on Properties of Secure Hash Functions

Enjoy!

Friday, March 28, 2008

Microsoft asks web developers to 'bet on us'

Okay...so *usually*, i try not to feed too much off of simple articles on the web, but as I am flipping through the news journals, I have run across (yet) another interesting post. Before reading on ...yes...let's put this into perspective. Yes...Microsoft is the whipping boy, yes...they are the biggest...yes...they have the most to deal with (ok....so i made that last part up). Read on ....

[ Article ]

Apple's Leopard lasts '30 seconds' in hack contest

Apple's Leopard has been hacked within 30 seconds using a flaw in Safari, with rival operating systems Ubuntu and Windows Vista so far remaining impenetrable in the CanSecWest PWN to Own competition. Security firm Independent Security Evaluators (ISE) — the same company that discovered the first iPhone bug last year — has successfully compromised a fully patched Apple MacBook Air at the CanSecWest competition, winning $10,000 (£5,000;) as a result. Although the competition recorded the hack taking eight minutes, Charlie Miller, a principal analyst with ISE, told ZDNet.com.au that it took just 30 seconds and was achieved using a previously unknown flaw in Apple's Safari web browser.

[ Article ]

wep cracking 101

WEP was intended to provide confidentiality comparable to that of a traditional wired network. Several serious weaknesses were identified by cryptanalysts; a WEP connection can be cracked with readily available software within minutes. WEP was superseded by Wi-Fi Protected access (WPA) in 2003, followed by the full IEEE 802.11i standard (also known as WPA2) in 2004. Despite its weaknesses, WEP provides a level of security that may deter casual snooping. ( Source, Wikipedia )

Trust me when I say that this is not the most comprehensive posting on WEP cracking, but I received a request from a friend of mine to provide the "short and sweet" on WEP cracking ... so I thought i would share this very short tutorial. The sample I am going to provide has several limitations (ex. I am only demonstrating an attack using ARP replay attack (there are several other methods of attack)), but we are simply giving a brief overview.
Video sample of instructions

There are four basic steps (well...at least in this example) to cracking a WEP key. The broad overview is as follows:

  1. Setup network interface card to monitor mode with airmon-ng (madwifi drivers for packet injection)

  2. Execute airodump-ng for sniffing wireless traffic and creation of "cap" file (to be used later with aircrack-ng)

  3. Execute aireplay-ng to create traffic for the generation and capture of IV's (we will be using an ARP-Replay attack (-3))

  4. Execute aircrack-ng against the generated cap file


Step One: Setting up your NIC with airmon-ng

  • The first step (and often daunting for the experienced administrator) in our quest for cracking a WEP key is to setup the network interface card on your system. For our example, we are utilizing the Netgear 108 Wireless PC Card (WG511T) which is based on the atheros chipset for packet injection. To setup your NIC to monitor mode, we must first execute a couple of commands in order initialize our card. The first two commands you will execute are:

    # rmmod ath_pci
    # modprobe ath_pci

Once you have executed these two commands, your interface will be ready to use with the airmon-ng script for setting your card into monitor mode with use with the madwifi drivers for packet injection.

  • The second step in setting up your NIC card is to engage the madwifi-ng drivers. Because the madwifi-ng drivers allow for multiple virual access points to be run, personally, I like to destroy and the create a new VAP on each session ... simply to make sure I understand what I have setup on the system. To do this, you will execute the following command:

    # airmon-ng stop ath0
    # airmon-ng start wifi0 1
    # macchanger -m 00:12:23:34:45:56 ath0

    This command(s) will destroy the current VAP and create a new parent VAP as well as, enable monitor mode on ath0 interface. You should now be able to execute the "iwconfig" command to verify that your ath0 interface is in monitor mode for sniffing wireless traffic.


Step Two: Discovering a target with airodump-ng

  • The first step taken with airodump-ng is to initate a session so that you can obtain information regarding a target access point. You will launch airodump-ng with the following command:

    # airodump-ng ath0 (ath1,ath2,...)

    Once you have determined the target access point for your capture, you will perform the following setup.

    # airodump-ng -w FileToCrack -c targetAP_ChannelNumber ath0

    Once this process is started...move to step 3.


Step Three: Initiate aireplay-ng

  • One purpose of aireplay-ng is to move the process of capturing IV's for cracking. This step will submit traffic to the access point so that it stimulates the AP into responding with initialization vectors in the ARP response. We are able to accomplish this with two simple steps. Keep in mind that we are ONLY demonstrating one single method of attack here (but it is (probably) the most popular method).For our example, we will assume that the target AP name is "tdurden" running on channel 6.

    # aireplay-ng -1 0 -e tdurden -a target_ap_mac -h our_mac_addr ath0

    Once this process successfully completes, initiate the following command.

    # aireplay-ng -3 -b target_ap_mac -h our_cards_mac_address ath0

    This will start the initiation of ARP requests to the access point. Once you have captured enough ARP requests, you may the use aircrack-ng to crack the WEP key based on the traffic capture of the .CAP file.


Step Four: Cracking our WEP key with aircrack-ng

  • The final step is to initiate the aircrack-ng script against your .CAP file (generated by airodump-ng). Simply issue the following command:# aircrack-ng FileToCrack.cap

    If you have captured a sufficient number of IV's from the ARP-replay attack then you should have a successful decryption of the WEP key.


Video sample of instructions

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!

AJAX [in]Security

First of all, let's get this out of the way.....AJAX itself does not introduce any new vulnerabilities to your applications....period.

The problem with AJAX is the way an AJAX application is implemented-- the same [old] mistakes are being made -- AJAX itself brings nothing new to the table. Quite honestly, if you review the common components of AJAX, you will see that there are really no new technologies being introduced with the framework ... developers are simply making the same errors in developing the application. Let's face it ....there is a pretty buzz around AJAX right now and folks are flocking to the solution like Bill Gates is flocking to the iPhone (you know he's going to buy one).

So....let's start from the beginning.

AJAX, shorthand for "Asynchronous JavaScript + XML," is a web development technique for creating interactive web applications. The intent is/was to make web pages feel more responsive (answer to the common latency issue of standard web apps) by exchanging small amounts of data with the server behind the scenes, so that the entire web page does not have to be reloaded each time the user requests a change. There are five (5) basic components of AJAX which are:

  1. User Interface -- Presentation using XHTML and CSS
  2. Document Rendering-- Dynamic display and interaction using the DOM
  3. Transport of Data -- Data interchange and manipulation using XML
  4. Messaging Handling -- Asynchronous data retrieval using XMLHttpRequest
  5. Javascript -- JavaScript is the Glue that holds it together

One of the key differences (and there are many) between a standard web application and an AJAX-based application is the method that data is exchanged between the client and the server. With a standard application, the client browser will make one large request to the server with everything it needs....an example HTTP Request would be:

-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
GET /index.html HTTP/1.1
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0
Host: hostname.com
=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Once this request is submitted, the browser will flash, objects will spin, the planets will align and all this neat stuff happens in the background. On the other side of the fence, we do not "see" most of what is happening with an AJAX application due to the use of XMLHttpRequest object which is the technology that really performs much of the magic.

Introducing AJAX

So how does AJAX differ from these standard applications? The answer my friend, is javascript. In an attempt to create this "latent free" environment, much of once what was server side application logic has been extracted from the server and placed in a logic layer on the client. If we were to examine a standard web architecture we might see something like....

[client_browser]
+
[fw]
+
[server side logic]
+
[architecture]

By removing some of the logic from the server/application environment, we end up with ....

[client_browser]
+
[
javascript_logic_layer]
+
[firewall]
+
[server side logic]
+
[architecture]

You can see that much of the logic is now exposed to the client. With much of the logic now exposed, you can imagine that the surface area of the application is now represented to the end user.....these points of attack are a very common gateway for an attacker to now get in to the application.

Are we leaking information?

One concern for applying more logic to the endpoint is now much of your application is now mapped out for the end user. A few items to note would be that:

  • Function and Variable Names
  • Inputs and Validators
  • Parameters, Data Types and Return Types
  • etc.

Using solutions such as a localhost proxy, firebug or many other inspection tools might allow an attacker the ability to modify the code as it's being submitted and received in the connection.

Firebug

If you haven't been exposed to firebug, I would absolutely recommend you seek it out. Firebug is an add-on which inserts itself directly into the Firefox browser. Keep in mind that Firebug is NOT a tool for security testing your web applications, but is simply (in my opinion) a debugging tool. After you have installed firebug, you can generate traffic and it provides you with a nice little tool for object inspection.....it really gives you a great visual on exactly what the XMLHttpRequests are doing in the background.

Sprajax

If you are interested (on the other hand) in assessing your AJAX applications, there is a very nice little tool provided by the folks over at The Denim Group in San Antonio called Sprajax. To quote the OWASP site...."Sprajax is an open source black box security scanner used to assess the security of AJAX-enabled applications. By detecting the specific AJAX frameworks in use, Sprajax is able to better formulate test requests and identify potential vulnerabilities."

pastey.net

A very interesting site that I was introduced to today is a site called pastey.net. Basically, it appears to work off of the same concept as tinyurl; however, pastey basically works with strings of text.

Let me give you an example....

Let's assume that you have found some piece of code on one computer system and you need to move it over to a different system. Pastey allows for you to paste this code into a form-field and auto-magically....it generates a semi-random URL where you are able to grab your contents.

Flaw in system?

Well...unfortunately, i'm sure that there are 100 different reasons why you should use this system, however, there is one area of concern. Do not send sensitive data through the portal. There is a method for securing the data (not sure how that works...i'll look at that in the next day or so), but by running a simple fuzzer, were were able to view 1000's of other responses and uploads to the server (and you would be amazed at what we found). So....great idea, but unfortunately....the execution appears to be a bit too simple; however, perhaps that's exactly what they were going for....?

You have been warned.

Gmail Drive

Now this is creative.

// text stolen from site

GMail Drive is a Shell Namespace Extension that creates a virtual filesystem around your Google Gmail account, allowing you to use Gmail as a storage medium. GMail Drive creates a virtual filesystem on top of your Google Gmail account and enables you to save and retrieve files stored on your Gmail account directly from inside Windows Explorer. GMail Drive literally adds a new drive to your computer under the My Computer folder, where you can create new folders, copy and drag'n'drop files to.

http://www.viksoe.dk/code/gmail.htm
+++++EOF+++++

selectively deaf?

I'm not going to make it a habit to post lame rants ... I'm actually going to make an attempt to not be that boring; however, I really had an interesting Friday and wanted to throw this up out.

While meeting with a client, we had a long, boring discussion about their companies general readiness, approach, road-map and general web application security posture. Keep in mind that this company (which you have heard of) puts more money into sticky notes every year than your company (probably) grosses annually.

So....I was meeting with a person from their Information Security team and we starting chatting about the general dismissive nature of their developers when it comes to remediation of web application vulnerabilities. The person I met with is one of the companies ethical hackers and he mentioned that while performing penetration tests across multiple applications, they continued to find the same vulnerabilities over and over again (XSSSQL Injection, administrative problems, etc). Remediation information had been presented to these developers multiple times (along with the ramifications of the exploits) and the development teams continued to make no charge towards any secure development path.

Enter Rant...

What is it going to take to make companies really start to pay attention to what is going on out there? With groups like GartnerSymantec and a ton of others barking that 70-ish% of all vulnerabilities are now in the web application layer -- when are CEO's, CIO's and all of the other C-men (heh) going to wake up and start paying attention? What is it that makes "network security" so much more sexy. Seriously...I was building infrastructures with that defense-in-depth crap back in the late 90's and 00's ... i think it's about time we start paying attention to the real war. So seriously, folks....what's it really going to take? I'll throw in my own thought of why this is the way it is -- take it for what it's worth....but as long as companies continue to operate with "functionality before security" ... we are never going to get rid of this dirty imposition. Honestly? From my seat...it's pathetically sad and while it does appear to be getting a bit better (IBM picking up WatchfireHPpicking up SPI Dynamics) -- it does appear that we are starting to make a move towards the positive side of things.

Who knows. I'll climb down off of my box now ....

+++++EOF+++++

magic Pixy Dust

Over the weekend I was looking at a bit of PHP code on a mambo site and discovered this little tool for download. While I would absolutely agree with myself that I'm not the best PHP coder you will run across, I was interested to discover this little solution. It is definitely true that languages such as PHP are more difficult to assess based on the fact that they do require more manual intervention. Anyway .... introducing pixy.

[Blatant Rip] Pixy is a Java program that performs automatic scans of PHP 4 source code, aimed at the detection of XSS and SQL injection vulnerabilities. Pixy takes a PHP program as input, and creates a report that lists possible vulnerable points in the program, together with additional information for understanding the vulnerability.

http://pixybox.seclab.tuwien.ac.at/pixy/

+++++EOF+++++

Conversion Attacks with SQL Injection

With any discussion of SQL Injection, folks commonly tend to migrate towards two basic types of SQL Injection:

  • Verbose SQL Injection
  • Blind SQL Injection

If you were to sit down and compare the variations of SQL Injection, these two would probably cover the 80/20 rule for the majority of attacks. For those of you who might be unfamiliar with the differences.

Verbose SQL Injection is loosly based around the idea that you are reading from error messages which the application is providing to your malformed requests. Blind SQL injection is a bit different in that you are basically "flying blind" with your attacks. In other words, there are no error messages being returned to you (however, there may be other indications which we won't go into here), but rather, you are forced to play 20 questions with the server. The basics behind this attack is you are asking the server yes-no, true-false, binary, etc. questions in an attempt to weed your way through a possible injection. (For more information on Blind SQL Injection, I would recommend this whitepaper from SPI Dynamics)

Convert Attacks

Conversion attacks are absolutely nothing new, but I wanted to push out a post (sounds like a bathroom break) here because quite often, folks are unfamiliar with this attack technique.

Conversion attacks are really quite simple whereas you might use the "convert" or "cast" functionality in a database to gather additional information. For example, you might use the attack string in a particular form field:

xxx-xx-xxxx '

to initiate the litmus test for SQL Injection. By the returned results, you might try something like....

xxx-xx-xxxx ' union select name from sysobjects - -

If we are provided good data, we might then try to convert 'name' in the request. We are assuming much at this point (please remember, i'm only trying to pass along the idea here), but if we were given data which met our needs, we might try to convert 'name' in our query with...

xxx-xx-xxxx' union select convert(int,(name)) from sysobjects - -

When using functionality such as convert, you will quite often receive (barring this is verbose SQL Injection) an error message which resembles:

-=-=-=-=-=-=-=-
Conversion failed when converting the nvarchar value of 'Table_Name' to data type int.
-=-=-=-=-=-=-=-

While the conversion does fail, the attack (actually, the error message) generates a table name in the error message itself.

Cast Attacks

Casting a variable is also a nice option with Injections. A cast specifies how to perform a conversion between two data types. A simple example might be:

someError=cast((select name from sysobjects) as int) - -

Again, what I am describing here is nothing new; however, it's a very handy solution that might be of great assistance in digging around for data.

Additional Information

If I were going to recommend a couple of resources for additional information on SQL Injection, you might check out:

+++++EOF+++++

OWASP Live CD Project

I was scoping out the OWASP site this morning a ran across a nice idea that appears to have been born at OWASP. Apparently, they are going to jump into the live cd game with their knoppix-based cd project titled "OWASP Live CD Project". While I absolutely agree with the idea, I wouldn't run out and start the 800 meg download. The applications included are very limited in number -- you might find more bang for your buck with taking a copy of Backtrack v2.0 and simply install the 3-4 solutions below (not included on the current backtrack release).

The current tools (I'm finding) for the install are:

  • WebGoat v4
  • WebScarab
  • Paros
  • JBroFuZZ
  • Cal9000
  • Nmap
  • TcpDump
  • WireShark

OWASP Download

If you are interested in the download, you will find the information at OWASP or you can access thedirect link here.

+++++EOF+++++

Fuzzers

Fuzz testing or fuzzing is a software testing technique that provides random data ("fuzz") to the inputs of a program. If the program fails (for example, by crashing, or by failing built-in code assertions), the defects can be noted. [ From Wikipedia, the free encyclopedia ]

+++++EOF+++++

SQL Injectors

SQL injection is a technique that exploits a security vulnerability occurring in the database layer of an application. The vulnerability is present when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and thereby unexpectedly executed. It is in fact an instance of a more general class of vulnerabilities that can occur whenever one programming or scripting language is embedded inside another. [ From Wikipedia, the free encyclopedia ]

+++++EOF+++++

Web Application Scanners

The following is a list of tools which we highly recommend you seek out.  If you have any of your own recommendations, please send updates and suggestions info@atrysk.com and we will add them to our list. 

Commercial Scanners

Open Source Tools

++++++++++

Security ISO's

The following is a list of tools which we highly recommend you seek out.  If you have any of your own recommendations, please send updates and suggestions info@atrysk.com and we will add them to our list. 

+++++EOF+++++

App Scanners vs. App Firewalls

If you’ve been around the Application Security world for any amount of time, you have probably listened to or participated in lengthy discussions on this topic.

The big question ... "Do I scan my application and fix my code or do I install an Application Firewall and block attacks?" It’s always interesting to hear different viewpoints from folks on what they would do given a particular situation so I thought, why not throw down a few thoughts.

I hold the belief that both solutions provide a valid option (given a particular situation). I must admit, I have deployed Application Firewalls and have purchased scanners ... both provided the necessary solution at the time of need. Here are a few of the things that I found.

Application Vulnerability Scanners

Positive:

  • Cost Effective (much cheaper than application firewalls)
  • Ability to assist in remediation of the actual problem
  • Easy to implement... no infrastructure changes needed
  • Very easy to use

Negative:

  • Most perform either blackbox OR whitebox testing
  • Difficult to get developers to adjust their code once issues are discovered (most reports go into the magic cylinder next to their desks)
  • False positives can be difficult to validate
  • Scanning can sometimes be performed after an attack and do not offer a real secure solution for those who do not implement code changes correctly (but...i must admit... the solutions offered for remediation in these tools has become so simple that a cave-person could do it ....(avoiding trademark issues)

Application Layer Firewalls

Positive:

  • Provide proactive protection strategy and allow for actual attacks to be blocked or filtered
  • Developers can go back to functionality as a strategy
  • Security team can pretty much go back to sleep and take on a less annoying roll

Negative:

  • Expensive!
  • Infrastructure Changes
  • Administration and Configuration: Not as easy to configure and maintain as some folks would lead you to believe.

Ok....so we have thrown out a list of goods and bads ....what the answer? Personally speaking ...fix your damn code. Period. Why put a band-aid on a open wound and allow it to bleed...pretty soon, you need to apply some pressure.

If you are seeking out a few solutions, you might begin with a couple of the market leaders:

Scanning Solutions:

Application Firewalls:

+++++EOF+++++

Web Service Attack Vectors

I have noticed over the last several months that more companies are beginning the migration to web services. What's a bit disturbing about this move is not the fact that companies are adding web services to their infrastructure, but the sheer volume of folks who have not yet realized that web services require the same type[s] of web application assessments that standard web applications require.

Ready? Aim? Attack?

A few notes for your nightly reading material. Keep in mind that this list is not the end-all, be-all of lists, but yes...please write this down in your Big Chief Notepad...

  • Web Services are subject to the same types of attacks as traditional web applications
  • Policies are blurred by integration and decoupling
  • Firewalls and SSL (not able to handle multi-hop transmissions) still don’t help much
  • Lack of end-to-end visibility
  • Poor design, Design Assumptions

Web Service Attacks

Unfortunately, WS's are still required assessment material for your developers, auditors or Information Security Team. For those who are unfamiliar with the attack types, here are a few:

  • XML Poisoning
  • Parameter Tampering
  • SQL Injection with SOAP Manipulation
  • XPATH Injection
  • LDAP Injection with SOAP
  • Directory Traversal and File System Access through SOAP
  • OS Command Execution
  • SOAP Message Brute Forcing
  • SOAP Parameter Manipulation with Buffer Overflow Attacks
  • Session Hijacking

I'm fairly certain that i'm probably missing several techniques here, but as soon as you master the list above, you can scream at me.

Policies are blurred...along with my vision of world peace

One common issue with WS (and SOA) architectures is the idea that the coupling of architectures might present a problem with security assessments and this is absolutely correct. As you might imagine, WS and SOA architectures do offer up a few challenges when it comes to assessments. Typically with WS architectures, the assessments begin with an exposed file known as the WSDL ("wiz-dell" (yes....I would love to take a wiz on my dell)). The WSDL file is essentially an XML-based file which defines the methods which are exposed for client connections. A common assessment would be to parse the XML file, understand its contents and perform a number of manipulation techniques against the file.

Firewalls and SSL

As with any conversation around web applications.... yes ....firewalls perform very little benefit to securing the web application. I do realize that this little blurb is focused more (or less) on WS architecture, however, it's worth noting this with regards to SOA. SSL offers up a particular challenge with SOA where it provides no true, end-to-end encryption solution for SOA. Each SSL certificate installed to the infrastructure must be terminated at it's next hop so these certificates will only provide a client-to-server encryption solution. Therefore, at each point in the architecture, a new certificate must be installed -- no one certificate can cover a multihop architecture. Additionally, this also adds to the idea that assessing an architecture where you have very poor (or complete lack of) end-to-end visibility increases the difficulty for web assessments.

Open up my raincoat? Yes, please.

If you had read through our little blurb on AJAX [In]Security, you will recognize that WS's also offer a particular amount of exposure to your application. Here is a sample file from Google's WS directive -- I'm hoping we are safe in inserting it here since it is publically availabe (google, if you want me to take it down....just write).

-=-=-=-=-=-=-=-=-=-=-=

< name="doGoogleSearch">
< name="key" type="">xsd:string"/ >
< name="q" type="">xsd:string"/ >
< name="start" type="">xsd:int"/ >
< name="maxResults" type="">xsd:int"/ >
< name="filter" type="">xsd:boolean"/ >
< name="restrict" type="">xsd:string"/ >
< name="safeSearch" type="">xsd:boolean"/ >
< name="lr" type="">xsd:string"/ >
< name="ie" type="">xsd:string"/ >
< name="oe" type="">xsd:string"/ >
< /message>
.........
< name="GoogleSearchService">
< name="GoogleSearchPort" binding="typens:GoogleSearchBinding">
< location="http://api.google.com/search/beta2">
< /port >
< /service>

-=-=-=-=-=-=-=-=-=-=-=

The exposure to many of these applications (while they may appear harmless) is the identification to what variables and types are being presented by the application. In our google sample above, you will will notice that most of the variable types (string, int, boolean, etc).

So folks, please keep WS applications in mind when you begin your conversations around your assessment criteria....the web service you save may be your own.
+++++
EOF+++++