There is something very big going on in the security world. It is rare to see things pushed forward quite this fast. I'm talking about the latest advances in web application security. I'm calling it Web Hacking 2.0 (gettit?).

ITWeb will be holding their 2007 Security Summit. The keynotes are Bruce Schneier and Phil Zimmerman. The best part is, three of our abstracts were accepted. Nithen, Yusuf and Johann will be presenting.

I sat up one night trying to figure out what I would say to Schneier. He is one of the reasons I got into security as a job. I remember having just finished my honours degree (our first postgrad degree before a Masters) and reading Secret's and Lies. It made me realise I could turn my hobby into a job. How does one meet a 'celebrity' and not come across as a gushing teen ready to part with her bra? I don't know, but I am going to try hard to take him out to dinner.

So, if you will be near SA, or are prepared to fly here, come to the ITWeb Security Summit to watch us present :)

This week I was reviewing a security product and discovered a rather serious XSS in their web console. When I highlighted this to the product's technical team, they claimed it was a vulnerability in IIS and not their product. It was rather silly of them to claim that outputting javascript was the fault of the web server. However, it did highlight two interesting facts about XSS' to me: An alert box displaying 'XSS' or unintelligible session details means very little to many people who should know better. You need to have a canned, high-level, explanation about what the dangers of an XSS really are.

A quick an easy demo, which I put here mostly for my own memory, is to just change the window location to point to a machine where you have set up a netcat listener with the session details and url appended to the request. If you want to be stealthy, you can use a hidden iframe.

RSnake has put up a really great write-up entitled, Death by a 1000 cuts. It describes how a series of minor security issues can be combined to form a very serious attack.

I spent most of my time dealing with security operational issues, where sometimes these sorts of minor issues are where I have to make concessions to get the big stuff done. I think this is a really great example that we security people need to take to developers and it operational staff to show them why defense-in-depth is necessary.

Yesterday I reported two vulnerabilities in a large web proxy product, 15 minutes later I got a call from a guy in Texas. It was 10pm there. Now that's dedication. What your fastest response?

Here are some URL's that can be used to demonstrate the Adobe Acrobat XSS vulnerability to people, and hopefully get them to patch.

• Short - http://tinyurl.com/yjeeoc
• Long - /docs/pdf_check.pdf#blah=javascript:alert('Please go to http://www.adobe.com/products/acrobat/readstep2.html and update your copy of Acrobat reader, you are vulnerable to a rather serious exploit.');location.href='http://www.adobe.com/products/acrobat/readstep2.html'

As an interesting aside, it seems Google has added the following HTTP header to requests for PDFs from their servers:

Content-Disposition: attachment;

This forces PDFs to be opened outside of the browser. Nice work Google.

VMWare will run on an openMosix node, but instances cannot be migrated across nodes, nor will VMWare be aware of the other nodes. I mention this so that you do not waste your time, as I have, based on information in the openMosix wiki which states the exact opposite:

If you intend to run VMWare under openMosix so that openMosix would load-balance several instances of that (yes, that works).

Just to be clear, the above is untrue, as confirmed both by my testing and Moshe Bar's comments. Moshe being the founder of openMosix:

On Thu, 12 Jan 2006, Moshe Bar wrote:
I would think it's next to impossible to migrate vmware instances simply because of Vmware's architecture. Vmware scans the exucutable [sic] VM pages of the virtual machine ahead of execution and replaces call to ring 0 of the CPU with system calls and pointers to it's own software. I doubt if a Vmware machine would be able to run on the remote node after migration.

Oh wow, I am in privacy nut heaven. Check out the following Firefox extensions for avoiding 'the man':

• Scroogle search plugin. Scroogle is a Google screen scraper without the cookies, javascript redirection, no search records.
• NoScript. I have been using this for a while. Given the recent developments in JavaScript attacks (see my summary as an example), you want to block Javascript on sites you don't trust.
• Cookiesafe. For those of you that want to relieve the tedium of cookie whitelists. Like Noscript, but for cookies.
• KeyScrambler. This looks promising but I have yet to test it. It encrypts keystrokes going to and from your keyboard driver to thwarte keyloggers. It won't work against Javascript or XUL keyloggers though.
• SafeCache and SafeHistory. These plugins segment your cache and history to prevent browser history attacks.
• Temporary Inbox. Disposable e-mail addresses for one-shot registrations integrated into your browser.
• Bug Me Not. No need to register for those sites that don't need it. There used to be a plugin, but drag this link I put together: "Bug Me Not" to your toolbar and click on it when a site asks you to register.
• Vidalia. This will set up The Onion Router (TOR) and Privoxy to allow near fully anonymised browsing. I find it slow and a bit of an overkill.
• Multiple Firefox profiles. Create a separate Firefox profile for those 'invasive' services like Google's GMail, Calendar, Groups etc. Profiles can be managed by starting firefox with the "-p" switch. Use the below script to run multiple instances simultaneously:

@echo off
set MOZ_NO_REMOTE=1
start "" "C:\Program Files\Mozilla Firefox\firefox.exe" -p
set MOZ_NO_REMOTE=0

This is a copy of an e-mail I was forwarded by iCommons (the international arm of Creative Commons) by Teresa Hackett of Electronic Information for Libraries. It very neatly lays out the problems with the TRIPS+ FTA Australia caved in to and America is trying to push on the rest of the world (South Africa only narrowly avoided it in our negotiations earlier this year). Even though it applies to libraries, it is well worth a read if you don't know what TRIPS+ is or why it is the devil.

Kevin Liston at the ISC has an entry up about predicting when Microsoft will release an out of cycle patch and when they will release it on patch Tuesday. His conclusions are:

• Microsoft will release an out-of-band patch only if a third party has released an unofficial patch, and that patch involves a change more involved than a kill-bit.

• Microsoft will release a patch on the next release date if the fix involves only a kill-bit.

This is an interesting bit on analysis, although I think you can take his analysis one step deeper. When I wrote my paper on optimal vendor patch release cycles I spent time analysing exactly this point: What criteria should be used when deciding to release a patch in or out of cycle to minimise risk to the people applying patches? Microsoft's current practise as pointed out by Kevin is highly flawed, but you don't need to research this to know that. However, I believe Kevin misses the root of what Microsoft's actual decision making criteria is. It is the same logic that applied in the case of their DRM being cracked; they released a patch out of band before anyone even asked; that of the impact on Microsoft directly.

Johannes Ullrich at the ISC, just demonstrated a very nice way to reduce the amount of automated comment SPAM they recieve. What I really like about this is the principle behind it:

Increase the work required to use something for attackers

http://isc.sans.org/diary.php?storyid=1836&isc=81b10e50ac18524a6834977e74c9325e