Category Archives: disclosure

When vulnerability disclosure fails

Many security researchers try their best to disclose vulnerabilities in professional and responsible manner. When the receiving party does not respond or does not implement fixes – or in the worst case responds, but does not implement fixes, researchers do not have good options.

Full-disclosure is one option. I will try to limit full-disclosure realizing it cannot be fully avoided. This post covers some of the recent failures regarding reflected Cross-site Scripting (XSS) vulnerabilities.

It is just Cross-site Scripting – why should I care?

Here is one good article on How To Exploit an XSS (Detectify blog 7-Nov-2012). Session hi-jacking, all kinds of phishing or spreading malware are just some examples. Attacks do happen. In majority of the cases site users are the victims – attacks are not targeted directly against vulnerable sites. Attacker spreads innocent looking, but malicious links in social media, blogs, e-mails and discussion forums hoping someone will fall into the trap. Someone usually does.

Below is a screen-shot of a Proof-of-Concept XSS phishing attack against a real, vulnerable WordPress powered blog. That case is covered on my other blog.

Note that all HTML content comes from an external script. URL is long enough to hide the XSS payload possibly also from web-server logs.

I still don’t care, your silly PoC shows a blog post!

A blog can be actually a very attractive XSS target depending on various things like popularity and domain name (==trust), but how about a company like Air France?

Notice the login form in the middle? That is a fake, a Proof-of-Concept

This case falls into the category: “communication succeeded, fixes did not”. First communication attempts were made on August. CERT-IST helped me to find a contact point within few days. Almost three months have passed and this issue has not been fixed. It was supposed to be fixed during September. Alexa traffic rank of the vulnerable site in France is 264.

SouthWest Airlines had a similar issue, which was fixed after my blog post. I have not received a single response. I tried to contact SouthWest multiple times between August-October using e-mail, online forms and Twitter.

Other recent examples XSS XSS XSS

Often there is no time to create a Proof-of-Concept, just some basic test cases and screen-shots. Perhaps that is not enough for some recipients.

Enough whining already: what can we do?

Responsible vulnerability disclosure should be a short, but a clear dialogue. Domain owners, web-masters and coders – please consider opening a channel for security researchers. E-mail is preferred. Open security@yourdomain, security-alert@yourdomain, secure@yourdomain or similar email address and monitor it. This is fairly easy and cheap solution. The normal contact addresses like info@yourdomain often do not work with vulnerability reports. Contact forms are bad for reporting security vulnerabilities.

There are plenty of good examples such as eBay, Microsoft, PayPal, Google and Facebook just to name a few.

A word of caution to all users: Be careful when clicking links pointing to XSS vulnerable web-sites. Some of them might be malicious.

Tagged , ,