Wednesday, November 28, 2007

I was reading Mike Rothman’s warning about the dangerousness of TinyURL, the famous URL shortener. Mike’s right of course. Someone could easily disguise a malicious URL and get you to click on a link that you wouldn’t have otherwise because it would have looked obviously like an XSS attempt by nature of the visible HTML tags. If you did click on the link you’d be redirected (301) to the malicious XSS URL and your sessions cookies to just about any website would have gone bye-bye or worse.

What I think we’re all missing though is that by just deciding not to use TinyURL we’re really not solving the client-side (browser) problem. What about the many other identical services like doiop, notlong, and shorturl? We can’t possibly memorize the names of all of them and remember to not click on their links. The point is if someone really wanted to get you to click on a malicious XSS link they will, no doubt. All they’d have to do is disguise and redirect it off any ol’ unrecognizable domain they control and you’d never get a chance to spot the XSS payload before hand.

So, here’s my feature request for the browser vendors that I don’t expect to be implemented until n + 1 versions from now. n being the version currently in beta. So that roughly means Firefox 4 or Internet Explorer 9. The URL from any 3XX redirect should not be allowed to contain <> characters. Or perhaps something less restrictive, say maybe no HTML tags allowed. Would that break anything? Sure, its not a perfect solution, but we have NOTHING now. Anyone want to try this out first by making a browser add-on?

For many successful attacks there are several ways to tell when something has been owned. When pages on your web server contain malware that’s infecting visitors. Or perhaps when the web servers begin making outbound Internet connections. Databases may see huge CPU spikes and network usage from data going out the door from SQL Injection issue. DB records that should NEVER be accessed (honeytokens) is another good indication. Web users will tell you right away when they’re passwords are changed, money is missing, something of of theirs has been defaced, or perhaps they have a new friend named Samy. The list goes on, but what got me thinking was the SEOwN3d hack that targeted the blog for former U.S. Vice President Al Gore’s Inconvenient Truth movie.

In this case the standard IDS stuff would not have applied. No money or value was lost, user accounts hacked, mysterious outbound connections, or malware payloads present - Only silent defacement containing an HTML link that no one was even expected to see or even click on. The SE0Wn3D hack was used to simply boost the search engine rank for another website - and not even through blog spam that we’re used to dealing with. So my original question stands, how did they find out? And for that matter if your website/blog was hacked in this way, would you notice? How would you notice? Maybe many thousands of blogs are already hacked for this purpose and we don't realize it yet. For all I know this blog has been hacked to boost Andy, ITGuy to his #1 status on Google and the only way to tell would be through viewing source.

Creating a cross-site scripting filter that allows user-submitted HTML/CSS to pass through, but does not allow malicious content through (usually coded in JavaScript), is a lot like writing your own encryption algorithm. It’s not something that you should be building yourself because it’s extremely easy to make mistakes and it takes an army of smart people scrutinizing it before its considered trustworthy. The difference is there hasn’t been an alternative to rolling your own so far. That’s why each Web Mail provider, social network, and blogging platform has their own implementation, which gets broken almost routinely. The MySpace Worm written by Samy is a prime example of how these filters can fail in spectacular fashion, which is where the AntiSamy project comes in.

The OWASP AntiSamy Project, developed by Arshan Dabirsiaghi, is an effort to create an open source (BSD Licensed) API that’ll allow user-submitted HTML/CSS, but severely limit the potential for malicious content (JavaScript) to get through. XML Policy files are created for what a user is allowed to submit which can either extends functionality or limit the attack surface. Samples eBay, MySpace, and Slashdot already created to use as a guide. Arshan was good enough to set up a live demo website of AntiSamy so people can play around with the various filter policies and test if they can be bypassed. Of course Arshan also needs help to make sure the API has enough usability so the average user can do what they need to.

Personally I think this is a fantastic project and something that could really take off usage wise - especially if versions are ported beyond Java to .Net and PHP. A lot of developers, who are aware of the dangers of XSS, are building more and more web applications that expect to take in dynamic user-supplied content (Web 2.0). This will give them an easy option to do so safely and securely. Excellent work Arshan!

Tuesday, November 27, 2007

It’s been six months since I achieved my blog goal of showing up first on Google when searching for “Jeremiah Grossman”. After than I that I figured it was all downhill - that is until someone mentioned to me that my blog shows up on the first search results page for just “Jeremiah”. OMG I thought, according to Google I’m now one of the most popular “Jeremiah’s” in the world! How cool is that!?! Mom will be proud. :)

As it stands I am #6, but there are only three different Jeremiah’s ranking higher. Of course the most popular among them is the prophet Jeremiah. That guy is going to be tough to beat. :) But hey I need a new goal and I’m up from the challenge. All it takes is links these days. So in honor of my new found mission, I’ve updated my blog tag line to:

“A page about me to show up first on Google when searching for Jeremiah”

You know website security is getting serious when not even the promotional blog for former U.S. Vice President Al Gore’s Inconvenient Truth flick is safe. According to an article by Robert McMillan of IDG News, “An Inconvenient Truth, has been hacked and is hosting links to Web sites hawking online pharmaceuticals.” Apparently the bad guys (probably better described as black hat SEOs) are attempting to boost their search engine rankings by invisibly linking to their websites entitled "Xanax On Line," "Viagra," and "Buy Valium Online".

One expert said it was probably an unpatched WordPress vulnerability, which is entirely likely, but it’s hard to say for sure. It’s also hard to say if the attack was targeted or if the blog was simply caught in the net of a mass WordPress exploit scan. The other question is if the links were buried invisibly in the source, how’d anyone notice? Anyway, just goes to show that even seeming low value targets could in fact have significant value to someone else.

Very few website owners post how security researchers may contact them with regard to a discovered vulnerability. This seems odd since most experts believe the vast majority of website contain them. Microsoft, Yahoo, Google, and now Paypal have their contact policies posted. The rest of the Alexa 500, if they have a posted policy, is extremely hard to find.

PayPal’s newly posted vulnerability disclosure policy though should be given special attention because they’ve done something unique in that and in my opinion very intelligent security-wise. If the security research follows their stated procedure, which is entirely reasonable, PayPal states plainly that they’ll not engage legal action! This should given the researcher confidence that nothing bad is going to happen to them as a result. I think this is first, and if not, I’ve never seen it.

“To encourage responsible disclosure, we commit that – if we conclude that a disclosure respects and meets all the guidelines outlined below - we will not bring a private action or refer a matter for public inquiry.”

This indicates that PayPal understands that security researchers are the good guys, but they are wary of disclosing website vulnerabilities to them for fear of legal issues. As a result researchers may choose to either not disclosure AT ALL or anonymously post it to a public forum like has been done so many times on sla.ckers.org. This way they are personally protected, but the problem is that this puts PayPal and their customers in a bad position.

PayPal either doesn’t get the vulnerability data they need at all, waiting for a bad guy to find the exact same thing and exploit it – or they have to do fire drill once it’s made public. And they might not see it published right away causing a time lag. PayPal would much prefer the opportunity to handle the issue in a timely fashion and has no interest in pursuing the matter further because there is really no benefit to it. Legal entanglements only prevent the good guys from being responsible and don’t deter the real bad guys one bit. And PayPal would know given the nature of the business.

PayPal sets a good example, hopefully other website owners will take notice and do the same.

Normally I don’t post WhiteHat Security job listings here, but enough people ask me directly anyway so I figured why not. We’re constantly growing and have very specific hiring needs, specifically in our operations department where a lot of the magic happens. Arian Evans, Director of Operations, put together the content below describing the type of people we’re looking for and what the role entails. If it’s appealing to you, email us at wh-jobs _ at _whitehatsec.com with your resume and let us know.

Why Work For White Hat Security?

WhiteHat Security needs a few good people.

Do you want to become an expert at web application security?

Do you want to learn the ins and outs of general software security?

Do you want to become legitimate hacker?

Would you like the challenge of testing your skills and your mettle and hack some of the most important and famous software on the planet?

Would you like to see how some of the largest websites in the world actually work, and rethink your assumptions about the Internet?

If your answer to any of these is yes, then you want to work for WhiteHat Security, and we just may have a place for you.

What do you need to work for White Hat Security?

Ideally we look for some combination of the following:

Web software programming experience

Any software programming experience

Math skills

Strong reasoning & logic skills

Customer service and process management skills

You do not need a background in web application security, information security, or any kind of security to work at WhiteHat Security. That is what we do and if you are smart, we will teach you all of that quickly. All you need to bring to the table is the right aptitude, eagerness to learn, and willingness to fit in with and strongly support a team-oriented environment.

What do you get working for White Hat Security?

1. Sex Appeal -- Gain essential, in-demand software security skills

Application Security is one of the hottest new fields, full of potential for career & income growth, and flexibility. Combining application security knowledge with existing skills of software development, quality assurance, or networking/network security enables an individual to pursue either a specialized career in security, or a general career path in development or QA armed with a security toolkit that will set one apart from other peers. The long and short is that recruiters will be beating down your doors in a matter of years if you excel.

2. Work for the Industry Thought Leader in Application Security

Did you ever want to work for the "best" at something?

Even better -- do you want to work *with* the best at something?

Would like a chance to become *one of* the best at something?

In the realm of scalable black box testing of web applications -- WhiteHat Security is #1. Many competitors have great ideas, cool flashy products, or some smart consultants, but WhiteHat Security is the only company on the planet assessing over 600 of the world's largest websites in production on a weekly basis.

3. WhiteHat Security is Customer Service

At WhiteHat, servicing our customers is number one. That is *what* we do. Did you ever work for a company that takes its customers for granted? Makes fun of them behind closed doors? Exhibits internal arrogance? That is the exact opposite of what we do at WhiteHat.

Would you like to work with really smart and appreciative clients at some of the largest companies in the world, and help them identify, understand, and solve some of their most challenging & difficult problems in the world? That is what we do on a daily basis. If you want to help us succeed in our mission -- come work for us.

4. WhiteHat Security is a Team.

WhiteHat Security has a fun, team-focused environment. All management speak aside -- it is a great place to work closely with smart people that you can depend on, and who will need to be able to depend on you.

OK, this is no way security related, unless you count that Jordan Wiens has Dell boxes stacked to the ceiling behind him while using on a Mac as information leakage. Anyway, Jordan and I got to video chat yesterday and he was testing driving Leopard's new iChat customized background functionality. Really funny stuff.

Monday, November 19, 2007

Jordan Wiens posted a funny example on Apple website on how sometimes security solutions hinder normal use. For example, when searching for “applescript” on search.apple.com the “script” part of the string is removed and a search for “apple” is performed instead. It’s hard to tell what type of intermediary device this is or what exactly its trying to do, but whatever it is it doesn’t like the word script. This makes it impossible to search for applescript on their website.

Following Larry Suto’s analysis of NTOSpider, IBM’s AppScan, and HP’s WebInspect, where he compared code coverage to links crawled and vulnerabilities found, some questioned the accuracy of his results. Personally I didn’t get the criticism because with only two published reviews this year, we should be grateful to see data of any kind related to web application vulnerability scanners. I chalked the comments up as the standard scanner vendor or product reseller defense mechanism. Besides, Larry Suto is a professional source code reviewer and if he can’t figure it out, what chance does anyone else have? Well, expect for the vendor themselves, and this is where it gets interesting.

HP/SPI felt the issue important enough to research and respond to directly. Jeff Forristal (HP Security Labs) set up an environment to redo Larry’s work and measure WebInspect v7.7 and v7.5 for two of the three websites. While everyone is encouraged to read the report and judge for themselves, a couple of things really stood out to me in the data charts (see below) - specifically false-positives and “vulnerability duplicates”. I’ve only talked about the problem of vulnerability duplicates briefly in the past when describing how customers eventually mature to a Quality phase where less equals more. Obviously perople prefer not to see identical vulnerabilities reported dozens/hundreds of times.

If you look at the chart columns “Total # Findings”, “Raw False Positive”, and “Accurate # of Instances” - these compare what the scanner reported, to what was false, to what vulnerabilities were valid and unique. The two scanners reported nearly identical validated issues, 5 on the Roller website and 113/110 on OpenCMS. In the false-positive dept, WebInspect v7.7 did fairly well only having between 0% and 16% on the two websites, while v7.5 performed a little worse at 2% and 36%. But what you have to look closely at is the ratio of Total # of Findings to Accurate # of Instances (minus the falses) as this will measure the level of vulnerability duplicates.

In the Roller website v7.7 reported 40 unvalidated issues, with v7.5 displaying 55, all of which boiled down to 5 unique vulnerabilities. That means only 12% of v7.7 results are meaningful! v7.5 was 9%! On OpenCMS, of 1,258 unvalidated issues reported by v7.7 (3,756 for v7.5), came down to 113 unique vulnerabilities. Once again only 9% and 3% of the results were necessary. Shall we call this a Vulnerability Duplicate Rate? That’s a lot of data to distill down and must take a lot of time. For those that use these scanners, is this typical in your experience and expected behavior?

I know Ory is reading this… :), so can you give us an indication of what the accuracy rating might have been for AppScan?

Garrett Gee took by far my most favorite picture of OWASP & WASC AppSec 2007. :) Thats myself, Samy Kamkar (Samy Worm), and Robert "RSnake" Hansen just after Samy's speech. Wayne Huang (Armorize) also took some fantastic snaps and in both rolls you see the faces of many familiar names from our industry. An event to be remembered.

Friday, November 16, 2007

RSnake introduced me to this blogging thing about a year and a half ago. At first I hated him for it because after trying it out it felt like another job taking up too much time - something else I had to keep up with and I wasn’t very good (writing) at it anyway. Not wanting to quit I decided to shift the goal to show up #1 on Google for “Jeremiah Grossman” (mission accomplished). I also decided to view this blog as an outlet for whatever personal and Web application security issues that happened to be on my mind. Whether or not anyone actually read it was just something I forgot all about.

Then something changed. Traffic grew exponentially to (10-20K uniques per mo.), slashdotted a couple of times, RSS subscribers went WAY up, and the media began to publish articles based upon the content. At the same time I started receiving a lot of extremely positive feedback via email, comments, and even face-to-face. People were coming up to me at conferences all over the world, whom I didn’t previously know, but knew of me from my blog. People were actually interested in what I posted! The blog became influential. Wow! So then I focused the content towards areas I thought most important and that people wanted to learn about.

Some 300 posts later, present day, what I’m most interested in is the thoughts and everyday experiences of you all - the readers. My surveys and live online roundtables are a reflection of that. The fact is “experts” have a hard time adding value and being timely if we don’t understand the challenges and the problems in the field. That’s why I personally spend as much time as I can conversing with people in the enterprise who’s job it is to protect websites. These are the people whom I want to help and make their lives better and easier. This is where we improve web application security overall.

So here’s my request for all over year:

If you know of a topic that I’m glossing over, haven’t talked about, or want me to dig in deeper into – please comment below or email me. For example, at the AppSec 2007 conference, someone in the education industry wanted to know how they might comply with PCI-DSS by changing the way they do business and not having to collect credit card data. This solution would be an alternative to spending a lot of money protecting the data.

AppSec 2007 was a blast. 200+ people filled eBay’s Town Hall enjoying nothing but web application security for two solid days (and nights). Can’t get that any place else and we even got somegreat press! If you weren’t able to attend, sorry you missed out. Don’t worry though - the conference slides will be posted on the websites shortly and within a couple of weeks the video will be made available too! This is fantastic because with just the slides a lot of the speaker’s insights are lost.

I personally got to meet and hang out with a lot of new people from Microsoft, Google, Cisco, eBay, PayPal, Oracle, Symantec, and even the U.S. Secret Service. Much of the time the hallway and after-party conversations are just as valuable to me as the conference content. Building relationships and learning more about people’s everyday webappsec challenges are my take away because these are the things I go home and try to later solve.

A lot of great pictures were taken, especially by Garrett Gee and Wayne Huang. I expect them to pop online up over the next week. When anyone posts their pics, please comment here or let me know so we can link to them. Pravir Chandra, Dave Wichers (and staff), Gunnar Peterson, Anurag Agarwal, Brian Bertacini, and the rest of the volunteers did a stellar job organizing the event, parties, and exhibits. As a result of their hard work everyone who attended had a really good time and learned a lot.

Friday, November 09, 2007

WhiteHat Security wanted to try something different from the ordinary slide-ware Webinar. So yesterday we hosted a live and un-scripted online Rountable discussion complete with audience participation. Robert “RSnake” Hansen, CEO of SecTheory, Chris Paggen, senior manager, application delivery and network security business unit at Cisco, and Jordan Wiens, Security Beat Editor at Network Computing, joined in and offered their personal insights on the topics of vulnerability assessment, web application firewalls, and the payment card industry data security standard. But things were made even more interesting and entertaining when we learned that WebEx allowed us draw on each others pictures :)

Wednesday, November 07, 2007

First there was the QVC and OpenSocial incidents that I blogged about, but there are others, many others. And a lot of the references can via WASC's Web Hacking Incidents Database (WHID). While the industry won't have it own form of blaster or slammer to wake people up to the problem, maybe like the old saying goes, we'll make up for it in numbers.

2) Funny enough, Oracle is suing SAP for hacking their customer portal. According to the story, “Oracle accuses SAP of attaining the log-in information of recent or current Oracle customers and using it to download software and support materials from the Web site for the PeopleSoft and J.D. Edwards product lines. The materials allow SAP to tell Oracle customers that it can support their PeopleSoft and J.D. Edwards products while they transition to SAP products, Oracle said.”

3) Scarborough & Tweed recently disclosed that the personal data (name, address, telephone #, CC#, acct #) of 570 of their U.S. customers may have been compromised through the use of SQL Injection.

4) A couple of hackers that RSnake knew, Sirdarckcat and Kuza55, attempted to compromise him and his site in a prank gone wrong. They were not successful, but RSnake was right to be angry with them for trying. RSnake being the chill and understanding guy that he is and the hackers taking full responsibility for their actions and expressing remorse were able to resolve matter peacfully. All has been forgiven. Its really good to see how these guys were able to work things out without unnecessary escalation.

Sunday, November 04, 2007

Top blogger Michael Arrington posted about how a hacker was able to modify his personal Plaxo account profile as well as that of Plaxo’s VP Marketing John McCrea. The hacker, calling himself “theharmonyguy” and describes himself as “just an amateur”, appears to have spotted a handful of clever insufficient authorization issues which allowed him to perform horizontal privilege escalation on fellow users.

Fortunately what theharmonyguy did was only a harmless prank and sought only to bring attention to the flaw. It there’s people out there who are curious and looking for these types of issues. And if you read back to an earlier post, I directed people to a story in Insecure Magazine #13 called "Social engineering, social networking services: a LinkedIn example". According to the content, social network websites can be incredibly valuable targets for conducting personal reconnaissance and carrying out identity theft.

My guess is Moore-Perry, who has since plead guilty to wire fraud, was no “hacker” and found the issue by mistake. She probably legitimately ordered something at first, then for whatever reason canceled it, and the products arrived in the mail anyway. Instead of calling customer support she probably saw an opportunity to make a little cash.

According to TheRegister article, QVC only learned of the incident when an eBay buyer tipped them off. They became suspicious because the QVC packaging wasn’t removed. Lazy crooks. The also incident begs the question, how many QVC customers (if any) have found the same issue and have just gone unnoticed? Out come the auditors. I’m sure this issue isn’t unique among eRetailers.

As I’ve been articulating over the last couple of months, business logic flaws like these can be incredibly damaging, are painfully common, and very difficult to identify. Obviously vulnerability scanners are not going to find these (unless they can check the mail too), IDS won’t spot them, and WAFs won’t block them. Basically this is because every part of the attack contains completely valid HTTP requests and responses. No crazy looking meta-characters like in XSS or SQLi and even the flow of the requests is natural.

At the same time, these types of issue can also be difficult for even a pen-tester to spot unless they know what to look for. Normally a pen-testers scope of work stops short of “ordering” something on the website. That’s also why I’ve been asking for and documenting as many of these real world examples as possible because it helps raise awareness. The more we have to go on the better everyone’s system design and vulnerability assessment processes will become.

Thursday, November 01, 2007

We figured we'd try something different from the usual slide-ware presentations that everyone is used to with ordinary Webinars. With this roundtable there will be no slides, we'll have more speakers (4 of them), a whole lot more interesting dialog, and most importantly a way for the audience to ask questions so they can participate more interactively. Check out the formal announcement below for more details. And if you want to attend, make sure you register ASAP because there is a 120 person cap that is expected to fill quick.

"WhiteHat Security is hosting its first ever online roundtable discussion on website security. Jeremiah Grossman, WhiteHat Security founder and CTO, Robert “RSnake” Hansen, CEO of SecTheory, Chris Paggen, senior manager, application delivery and network security business unit at Cisco, and Jordan Wiens, Security Beat Editor at Network Computing, will take on today’s hot button issue of website security in a unscripted one-hour event. Please join us on Thursday, November 8th at 1:00 PM PST (4:00 PM EST) for this entertaining and educational event.

There will be very few prepared questions. The event will be audience interactive. Your questions or comments, will drive the conversation. Hear website security experts discuss:"

Its time for another WASC Meet-Up. As usual this will be an informal gathering. No agenda, slide-ware, or sponsors. Just some like minded people from the security industry getting together to share their stories over beer. Everyone is welcome and it should be a really fun time!

Please RSVP by email ASAP, if you haven't done so already, so we can make the proper reservations: anurag dot agarwal at yahoo dot com

About Me

Jeremiah Grossman's career spans nearly 20 years and has lived a literal lifetime in computer security to become one of the industry's biggest names. He has received a number of industry awards, been publicly thanked by Microsoft, Mozilla, Google, Facebook, and many others for his security research. Jeremiah has written hundreds of articles and white papers. As an industry veteran, he has been featured in hundreds of media outlets around the world. Jeremiah has been a guest speaker on six continents at hundreds of events including many top universities. All of this was after Jeremiah served as an information security officer at Yahoo!