Random Thoughts of Adam Ely » Application Security

A How-To Guide To Cloud Computing

Adam — Sat, 06 Dec 2008 06:04:05 +0000

I recently collaborated on a piece for InformationWeek entitled “A How-To Guide To Cloud Computing“. My portion was a tight 700 or so words regarding what security topics to consider when utilizing the cloud for the first time. I would have liked to write a lot more and go indepth, but it was not the purpose of the piece so my objective was to outline a few key action items people could use to get started.

Video: Where Information Security Goes Wrong – Rant

admin — Sun, 12 Oct 2008 01:15:31 +0000

Video blog rant on information security programs. This started as me just playing around with the isight camera and evolved into a full on rant.

I learned that I have no future in media.

Time To Send Out For Security Help?

admin — Sat, 27 Sep 2008 18:55:47 +0000

A recent sidebar piece I wrote for InformationWeek has been posted online.

“Security software as a service is increasing in popularity in tandem with the growth in cloud computing, as emerging providers promise to lower costs while increasing security…[Read More]“

Morphing Web Applications

admin — Sat, 21 Jun 2008 08:32:59 +0000

Over the last week I have been thinking about applications that could morph themselves based on some criteria. Mostly, I have been thinking about this in respect to web applications which could change their layout automatically based on the user’s interaction with certain parts of the application or lack thereof.

Additionally, this week I have been doing a lot of research on web application security. Tonight the two topics merged.

What if an application could change itself in order to protect itself? For instance, what if an application which accepts user input, submits the input via GET, and then displays the information could protect itself from being used in XSS phishing attacks even if it is vulnerable to XSS attacks?

Enter dynamic variables. The code below is a quick POC I put together to decide if this would work. The outcome: Yes, it could work. The code below is vulnerable to XSS attacks, but the attacks would only be valid for 2 seconds because the variable changes and essentially expires.

I fully admit that if someone was going to go through this much trouble, they should just fix the bad code. I wanted to try this just as a POC and for purely research reasons. There may be some value of implementing a more advanced version of this in a WAF, but again may not be worth it since there are other ways to address it.

Anyway, on to the code:

$var = date(dWYHis);

print “

”;

$datechk = date(dWYHis);

foreach ($_GET as $key => $value){
if ($key <= $datechk AND $datechk > $date-2){
echo “$value”;
}
}

The first part reads in the the current date and time and sets this string as the name of a field in a html form.

Next once the form is submitted, the current date and time string is read into $datechk. The variables submitted are extracted and the variable names are compared to the current $datechk value to ensure the variable is not more than 2 seconds old. If the variable is equal to the current datetime string or is no more than 2 seconds old, then the variable is acceptable and the code moves on.

Obviously, the date-time string should not be relied upon alone. It could be used if it is salted in some manner but the key is to have a repeatable process on both ends to ensure the data variable can be recreated and validated.

Sorry about the code formatting, the blog doesn’t do a great job of formatting code.

Ouchie – PCI sticks it to the vendors

Adam — Wed, 23 Apr 2008 16:46:01 +0000

The great folks over at the PCI council have finally done something I agree with. They have provided a clear and concise explanation of PCI 6.6. Typically, their direction is unclear and left to the masses to decipher.

In the new PCI 6.6 supplement, the council has given more direction on how to meet the dreaded 6.6 (should be 6.6.6) before the June 30th deadline. Originally, many thought 6.6 would require full code reviews or a web application firewall. Then, based on comments from Bob Russo, it looked like a mix of reviews and scanning was in order.

Alas, we were all delighted to find out that the options for 6.6 are simple.

Option 1:

Code Review which is subdivided into 4 options:

Manual code review of application source code

Proper use of automated source code analyzer (scanning) tools

Manual web application security vulnerability assessments

Proper use of automated web application security vulnerability assessment (scanning)
tools.

WebApplication Firewall (WAF)

Now with that cleared, here is what I see. All of the source code assessment tool companies and web application firewall companies are in a panic. 6.6 was their pay day, but now it appears we have an eaiser way to achieve this by running a web application scanner such as Webinspect.

While there is defiantly benefit in source code reviews and WAFs have their place, though disputed by many, performing a review with a scanner is much more cost effective. At the end of the day, we are in business to make money and must make compromises between security and business. I think we have found that compromise for 6.6.

Google Code University – Web Security

Adam — Wed, 19 Mar 2008 20:25:59 +0000

This URL was sent over to me by a co-worker. Looks like Google is hosting a few presentations and video related to Web Security. Worth a review.

http://code.google.com/edu/security/index.html

Silly programmers, hackers always win. +1 for corporate hackers.

Adam — Fri, 07 Mar 2008 23:01:36 +0000

Today I was investigating how a 3rd party site was streaming content from another site. The silly people tried to hide their JavaScript and HTML magic by “encrypting” the source using Encrypt HTML Pro – they also put a fake error in the source to deter me (Error 505: Source Code Unavailable).

With some JavaScript of my own, their code was reversed to human readable in no time. I figured how they were getting the stream and now that is being stopped.

The run down:

Encrypt HTML Pro basically creates two parts inside your document. First, a JavaScript block that is a hex encoded. This holds the function which performs the “decryption” so your browser can read the rest of the page.

Next, you have blocks (as many as you define when encrypting the code) of JavaScript code that is not readable. What tipped me off when looking at the obfuscated document was the fact that each block was JavaScript and calling the same function.

When I decoded the first block, I found the function the subsequent blocks were calling. I realized that the subsequent blocks were just pushing the obfuscated code through this function which then returned something the browser can read.

So I did the same thing. I had the function to decode everything so I just ran the subsequent blocks through the function and printed them to a local file.

I then found a few blocks of code that the author (or software) tried to use to hide more details. The author used the JavaScript function “String.fromCharCode” to encode strings they wanted to further hide. Using the JavaScript function “eval” and again printing to a text file, I got what I needed from those.

At the end, I figured out how they were getting the stream and I even thought of a better way to grab the stream and fully hide how it was being done. Oh well, luckily I work for the media company.

Silly programmers, hackers always win. +1 for corporate hackers.

P.S. Maybe now Billy Hoffman will give me some respect

Apache Tomcat CIS Benchmark

Adam — Fri, 01 Feb 2008 17:00:20 +0000

The Center for Internet Security announced this morning that they will be launching an Apache Tomcat benchmark project, along with Xen and SUSE.

I am pleased to announce that I will be heading up the Tomcat project for CIS. If you are interested, or know anyone who might be, please subscribe to the mailing list and help the project. We are still getting ramped up so not much movement yet but defiantly looking to get started soon.

Follow up: Larry Suto’s Testing Proven Faulty – Again

Adam — Thu, 06 Dec 2007 20:47:37 +0000

Via the SPI Dynamics blog ,I saw that Ory Segal of IBM/Watchfire released an analysis of Larry Suto’s scanner comparison. If you recall, Jeff Foristal of SPI released his own a few weeks back. I will let you compare and make up your mind, but I will note that both are much more open and unbiased in my opinion than Suto’s.

What I find most intersting is the side commentary around this issue. Larry released test results without releasing the methodology. We were not able to review the results for oursevles and thus many of us did not trust the results. It is truly puzzling to me why people would accept results without questioning them. There has been a lot of discussion around this point and well, the verdict is in: Shame on us as an industry.

Mr. Hoffman weighs in on this topic today thus refocusing my attention to the entire issue. Aren’t we in the business of questions the known and seeking the unknown? Who is Larry Suto, or anyone for that matter, to provide us with something to be accepted at face value and never questioned?

Maybe it is the conspiracy theorist in me, but I am wondering why Suto took such a strong stance towards NTOSpider and did not release his testing method. Was it that he truly believes code coverage is the way to go and was blinded by this thought? Maybe he wanted some press and this was an easy way to do it (cause I surely did not know who he was). I do not want to question the ethics of Suto, but I am curious what his decision was and why his testing was flawed.

As I was just reminded by a co-worker, “don’t assume it is conspiracy when incompetence is a most likely reason”.

PCI PA-DSS

Adam — Mon, 19 Nov 2007 17:22:18 +0000

Recently I posted about PCI’s new payment application mandate coming out. Today I was lucky enough to receive a draft version, a comment sheet, and the associated NDA (thus why I have not posted the documents here).

A quick review basically outlines what we expected. PCI is taking Visa’s PABP program, transitioning it into PCI standards and putting the screws to the application vendors via the merchants.

A quick run down:

The new requirements apply to 3rd party developed applications that store, process, or transmit cardholder data as part of the authorization or settlement.
Merchants can only use third party payment applications which are pre-approved or able to pass certain criteria. This basically means, use what is pre-approved and save yourself time. Note: Internally developed payment applications which are not sold or licensed to a third party are not in scope.
For those applications not on a pre-approved list, the QSA must have a lab to test the application against the PA-DSS standards. PCI outlines new guidelines around testing and the lab requirements.
The merchants are liable, thus they will affect the vendors compliance through purchasing decisions directed by PCI.

I applauded PCI for sending this out and providing a comment sheet so that the standards can be improved before going live. Over all most of what I have seen so far I expected, let’s just wait to see what the final release looks like.