Cenzic 232 Patent
Paid Advertising
web application security lab

Portscanning Without JavaScript Part 2

Today Ilia Alshanetsky proved the theory to be correct you can portscan from an HTML page without JavaScript enabled. Really when I say port scanning I mean ping sweeping in this case, because as Jeremiah and others have noted the difference between a server that’s alive showing an open port verses a closed port in time difference is negligible. This finally puts to rest the notion that surfing without JavaScript enabled is a safe way to surf the Internet. Hallelujah! I always felt like that was incorrect - even if you get rid of CSRF as an issue.

Ilia’s example shows the basic premise and he even gives code snippets, but he solves one interesting problem. There are some timeout issues that Jeremiah encountered which can be bypassed by using multipart/x-mixed-replace in the Gecko rendering engine and Safari/Opera. Very interesting. That allows the page to be re-rendered without the use of JavaScript or Meta refreshing etc… Very clever solution, however it appears to be limited to the non-IE crowd, which makes it’s actual effectiveness around 20-30% of the user population. Of course you can do browser detection to not even start scanning until you get a user who is using a compatible browser since browser detection can be done on the server side.

I think we’ve proven a our point. JavaScript isn’t the root of the problem here. Sure it enables bad stuff, but HTML and the client technologies alone can obviate the necessity for JavaScript alone. Do I think anyone is going to use this technique in reality? Probably not when JavaScript is so prevalent and cross browser compatible. But it is nice to know you can call people out when they claim they are safe because they turn off JavaScript.

11 Responses to “Portscanning Without JavaScript Part 2”

  1. Kyran Says:

    It seems as you and Jeremiah have been saying for the past while, html http and the DOM security model are all fairly flawed in reality. While javascript adds to the problem, it is not the cause. All web technologies contribute and to be frank, I’m getting to the point where I’m scared to even be submitting this comment.

  2. RSnake Says:

    Hahah… little old ha.ckers.org isn’t going to do much to you. But yes, point taken, there’s no way for you to know. And if we got hacked there’s nothing stopping an attacker from doing something malicious to anyone who reads our pages. The internet is just very fragile.

  3. Stefan Esser Says:

    This might also be interesting to you…

    http://blog.php-security.org/archives/54-JavaScriptHTML-Portscanning-and-HTTP-Auth.html

  4. Edward Z. Yang Says:

    Perhaps the real problem, then, is the ability of HTML to trigger remote includes.

  5. maluc Says:

    that might me true.. but sharing, interconnecting, and building off of one another are some of the core principles of the internet. Disallowing all cross-domain frames, links, images, css, and script isn’t really a viable alternative :/

    And when you limit something, people are just gunna find a less secure hack to work around those limits.. (see AJAX, JSON, PHP includes, custom protocols, etc)

    The price we pay for progress and innovation, but i’d argue it was worth it.

  6. Mephisto Says:

    I have to agree with maluc. In a perfect world these types of vulnerabilities wouldn’t exist. However, in an attempt to allow interconnectivity/interaction between multiple technologies you inevitably sacrifice leaving some windows open while attempting to lock all the doors.

  7. Stefan Esser Says:

    JavaScript scanning without HTTP Auth popups and possible way to bruteforce HTTP auth credentials…

    http://blog.php-security.org/archives/56-Bruteforcing-HTTP-Auth-in-Firefox-with-JavaScript.html

  8. Jungsonn Says:

    I’ve been following this topic for some time, but i can’t make up the practical use for it, or the main idea behind it, and why this is so unique. I mean, this can be done with PHP alone. just scan:

    for($k=0;$k

  9. maluc Says:

    because php cannot scan the victims intranet.. client-side javascript can. That was the biggest use of Jeremiah’s original work on javascript port scanning

    (use < instead, or wordpress deletes everything afterwards :T )

    intranet attacking is a very unexplored frontier. and without the ability to scan it to find hosts - largely unpossible before.

  10. maluc Says:

    whoops.. i meant to say: use & l t ; for <

  11. Jungsonn Says:

    Yeah the code was filtered :S
    it was a simple loop to scan ports.

    Still, i don’t find it very usefull or practical, but it’s a nice idea.