From 4ee4e3c6b4bfbb2c8f3d78c09d2b0cd33897aa58 Mon Sep 17 00:00:00 2001 From: ultimatecoder Date: Thu, 18 Apr 2019 17:02:23 +0530 Subject: [PATCH 1/5] Adding in-progress draft for Javascript based Port scanner. --- _posts/draft.md | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 _posts/draft.md diff --git a/_posts/draft.md b/_posts/draft.md new file mode 100644 index 0000000..d5bdc7a --- /dev/null +++ b/_posts/draft.md @@ -0,0 +1,8 @@ +Recently, I was reading about possible ways to fingerprint open TCP ports at +workstation of a client using Javascript. I suggested to read [this](http://blog.andlabs.org/2010/12/port-scanning-with-html5-and-js-recon.html) this vulnerability is discovered by AndLabs. That blog post describes a possible way to fingerprint open TCP ports at clinet workstation. The author claims that Ajax request to ports which are open at clinet worksation are delayed were delayed than empty ports. + + + Firefox browser allows XML HTTP Requests (XHR) for localhost which allows is proposed by +[here]() +While reading that post I found their tool "JS-Recon" implementing this attack +is not available. From 110cfd85297084a1beb70e480621a8c3fc121fc9 Mon Sep 17 00:00:00 2001 From: ultimatecoder Date: Thu, 18 Apr 2019 19:28:26 +0530 Subject: [PATCH 2/5] In-progress blog post, introducing Javascript based port scanner --- _posts/draft.md | 75 +++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 69 insertions(+), 6 deletions(-) diff --git a/_posts/draft.md b/_posts/draft.md index d5bdc7a..c0a828b 100644 --- a/_posts/draft.md +++ b/_posts/draft.md @@ -1,8 +1,71 @@ -Recently, I was reading about possible ways to fingerprint open TCP ports at -workstation of a client using Javascript. I suggested to read [this](http://blog.andlabs.org/2010/12/port-scanning-with-html5-and-js-recon.html) this vulnerability is discovered by AndLabs. That blog post describes a possible way to fingerprint open TCP ports at clinet workstation. The author claims that Ajax request to ports which are open at clinet worksation are delayed were delayed than empty ports. +tldr; +scanner tries to identify open ports +tool is based on possible venerability to fingerprint open TCP ports at client +workstation using Javascript. I will explain my motivation for writing this +tool. - Firefox browser allows XML HTTP Requests (XHR) for localhost which allows is proposed by -[here]() -While reading that post I found their tool "JS-Recon" implementing this attack -is not available. + +Background + +Recently, I came across a possibility to fingerprint open TCP ports via browser +based Javascript attack. This attack was discovered by AndLabs and briefly +introduced at +[this](http://blog.andlabs.org/2010/12/port-scanning-with-html5-and-js-recon.html) +blog post. + +CORS a half way protection + +Ajax request to cross domain are prevented by a browser to avoid CORS attacks. +If you are not aware what CORS is, then I suggest you to read [this][cors_guide] +post before progressing further. + +What happens when you do an ajax request to "https://localhost:8084"? + +If any service is running on port *8084* at your computer, then a browser will +forward your request to that service. When that service returns any response, +the browser checks for the CORS headers in the response. Responses without +appropriate CORS headers are dropped by the browser. From the client side, there +is no way to identify a reason for failed request. You can't identify that the +request failed because of CORS error or 404 until you track it in debug console +of your browser. + +The error response from the browser for XHR on ports where any service is +running is late than ports where no services are running. The delay in coming +response exposes this variability to finger print open TCP ports at client +workstation. + + +My motivation for writing this tool + +Now a days, browser is the most commonly used tool. Everyone is not a developer +who can write Javascript to assert the possibility of this venerability. Despite +trying hard, I failed to find the source code of JS-Recon. I am writing this +tool so that anyone irrespective with their background can try and believe the +possibility of this venerability. + + +This venerability attracted me to try it out via their implementation done at +JS-Recon tool. When I clicked at the mentioned link, I found the domain has +expired. I tried finding the source code of that tool, but ended with no +results. I fired some XML HTTP Requests (XHR) to localhost at my Developer +console and I was clearly seeing the pattern identified by the author. + + +he mentioned method by the author. For confirming his +hypothesis I wanted to try this vulnerability. Unfortunately, mentioned tool +isn't available at this moment. I tried best to find the source of that tool, +but I ended with no results. + + +seemed expired to me. That blog +post describes a possible way to fingerprint open TCP ports at clinet +workstation. The author claims that Ajax request to ports which are open at +clinet worksation are delayed were delayed than empty ports. + + +Firefox browser allows XML HTTP Requests (XHR) for localhost which allows is +proposed by [here]() While reading that post I found their tool "JS-Recon" +implementing this attack is not available. + +[cors_guide]: https://add-cors-guide.com From 011f6f2ac37ffcd62abdaa6fed6061a7daf3e452 Mon Sep 17 00:00:00 2001 From: ultimatecoder Date: Fri, 19 Apr 2019 10:39:27 +0530 Subject: [PATCH 3/5] In-progress --- _posts/draft.md | 82 +++++++++++++++++++++++++++---------------------- 1 file changed, 45 insertions(+), 37 deletions(-) diff --git a/_posts/draft.md b/_posts/draft.md index c0a828b..9490ef6 100644 --- a/_posts/draft.md +++ b/_posts/draft.md @@ -1,18 +1,49 @@ tldr; -scanner tries to identify open ports -tool is based on possible venerability to fingerprint open TCP ports at client -workstation using Javascript. I will explain my motivation for writing this -tool. +Chatur is a Javascript based port scanning tool. This tool proves the possible +venrability of fingerprinting open TCP ports at client workstation using pure +Javascript. Background -Recently, I came across a possibility to fingerprint open TCP ports via browser -based Javascript attack. This attack was discovered by AndLabs and briefly -introduced at +Recently, I came across a possibility to fingerprint open TCP ports at client +workstation using browser side (aka clinet side) Javascript. This attack is +discovered by AndLabs in the year 2010. In this section, I will explain the +anatomy of this venerability. There are not regit pre-requisites, but it is +better if you know how to perform an XML HTTP requests in Javascript. + +If I write a Javascript code to put a XHR to `http://localhost:8084` and host it +at `xyz.com` then when you visit the `xyz.com` the browser will fire that XHR to +port `8084` of your workstaion because `localhost` for your browser is your +workstation. This gap explores many possibilities, one of them is timing to open +a socket. If you fire bunch of XHR on different ports of localhost and capture +the time browser took to open the socket then you can obser that response timing +The browser(and operating system) takes bit longer time to open a socket on a +non empty port. + +that request will touch the workstaion of whoever is browsing my website. This +is possible because browser do not blocks XHR to `localhost`. Using this gap I +and founder of this vunerability has observed one common pattern in response +timings. Requests to non empty ports were returning late than ports where no +service was running. Using this clue, if response on such port is delayed we can +claim that there is an active service on such port + +I will suggested to read [this](http://blog.andlabs.org/2010/12/port-scanning-with-html5-and-js-recon.html) -blog post. +blog post published by them to understand this vunerability at more detail +level. + +If I do a XML HTTP request to a random port of localhost, response timing of +empty ports is faster than the response of ports where any service is running. + +If you do a XML HTTP +Requests to cross domain, browser will expect an appropriate CORS headers in +response. Requests which aren't returning a response with appropriate CORS +headers are failed by the browser. + +Which means, anyone + CORS a half way protection @@ -38,34 +69,11 @@ workstation. My motivation for writing this tool -Now a days, browser is the most commonly used tool. Everyone is not a developer -who can write Javascript to assert the possibility of this venerability. Despite -trying hard, I failed to find the source code of JS-Recon. I am writing this -tool so that anyone irrespective with their background can try and believe the -possibility of this venerability. - - -This venerability attracted me to try it out via their implementation done at -JS-Recon tool. When I clicked at the mentioned link, I found the domain has -expired. I tried finding the source code of that tool, but ended with no -results. I fired some XML HTTP Requests (XHR) to localhost at my Developer -console and I was clearly seeing the pattern identified by the author. - - -he mentioned method by the author. For confirming his -hypothesis I wanted to try this vulnerability. Unfortunately, mentioned tool -isn't available at this moment. I tried best to find the source of that tool, -but I ended with no results. - - -seemed expired to me. That blog -post describes a possible way to fingerprint open TCP ports at clinet -workstation. The author claims that Ajax request to ports which are open at -clinet worksation are delayed were delayed than empty ports. - - -Firefox browser allows XML HTTP Requests (XHR) for localhost which allows is -proposed by [here]() While reading that post I found their tool "JS-Recon" -implementing this attack is not available. +Browser is the most common tool used by us. Asserting this venerability requires +knowledge of Javascript and everyone is not a developer. Despite trying hard, I +failed to find the source code of JS-Recon (the tool written by AndLabs proving +possibility of this attack). I am sharing this tool so that you or anyone else +irrespective of your technical backgrounds can try this tool to verify the +possibility of this attack. [cors_guide]: https://add-cors-guide.com From 6a70fa69c5d053ae0b191f8acd42a216c54f3c9f Mon Sep 17 00:00:00 2001 From: Jaysinh Shukla Date: Fri, 19 Apr 2019 17:58:36 +0530 Subject: [PATCH 4/5] Improving in-progress code --- _posts/draft.md | 121 ++++++++++++++++++++++++++++++------------------ 1 file changed, 77 insertions(+), 44 deletions(-) diff --git a/_posts/draft.md b/_posts/draft.md index 9490ef6..a265e16 100644 --- a/_posts/draft.md +++ b/_posts/draft.md @@ -1,79 +1,112 @@ tldr; -Chatur is a Javascript based port scanning tool. This tool proves the possible -venrability of fingerprinting open TCP ports at client workstation using pure +Chatur is a Javascript based port scanning tool. This tool proves the +possibility of fingerprinting open TCP ports at client workstation using pure Javascript. - Background Recently, I came across a possibility to fingerprint open TCP ports at client -workstation using browser side (aka clinet side) Javascript. This attack is +workstation using browser side (aka client side) Javascript. This attack is discovered by AndLabs in the year 2010. In this section, I will explain the -anatomy of this venerability. There are not regit pre-requisites, but it is -better if you know how to perform an XML HTTP requests in Javascript. - -If I write a Javascript code to put a XHR to `http://localhost:8084` and host it -at `xyz.com` then when you visit the `xyz.com` the browser will fire that XHR to -port `8084` of your workstaion because `localhost` for your browser is your -workstation. This gap explores many possibilities, one of them is timing to open -a socket. If you fire bunch of XHR on different ports of localhost and capture -the time browser took to open the socket then you can obser that response timing -The browser(and operating system) takes bit longer time to open a socket on a -non empty port. - -that request will touch the workstaion of whoever is browsing my website. This -is possible because browser do not blocks XHR to `localhost`. Using this gap I +anatomy of this venerability in simple way. I expect you are able to understand +the basics of XML HTTP Request. + + +What happens when you fire an XHR? + +Browser initiates a TCP socket at the destination URL and sends header and body +of the request. Once header and body is sent, browser terminates the active +socket and waits for the server to deliver a response. That is how HTTP works +under the hood. + + +If I write a Javascript code to put a XHR to 'http://localhost:8084' and host +that code at 'xyz.com' then when you visit the 'xyz.com' the browser will fire +that XHR to port '8084' of your workstation because 'localhost' for your +browser is your workstation. This gap invites many vulnerabilities for user. +One of them is the possibility to fingerprint open TCP ports at client +workstation. + +While observing the timing browser took to receive headers from the server were +highlighting a clear pattern. Responses + + + + + +Browser opens a socket to the destination URL, sends header and then sends body +of the request to the server and terminates the socket. That's how HTTP is +designed. In our example, browser will open a TCP client socket to +'http://localhost:8084' and sends header and body and terminates the socket. + + + + + +Using `XMLHTTPRequest.onstatechange` listener, we can identify + + +If you want to fingerprint that any dedicated port at client workstation is +open or closed, you just fire XHR to that port. + + + + + +If bunch of XHR on different ports of localhost and capture the time browser +took to open the socket then you can obser that response timing The browser(and +operating system) takes bit longer time to open a socket on a non-empty port. + +That request will touch the workstation of whoever is browsing my website. This +is possible because browser do not block XHR to 'localhost'. Using this gap I and founder of this vunerability has observed one common pattern in response timings. Requests to non empty ports were returning late than ports where no -service was running. Using this clue, if response on such port is delayed we can -claim that there is an active service on such port +service was running. Using this clue, if response on such port is delayed we +can claim that there is an active service on such port. -I will suggested to read +I will suggested reading [this](http://blog.andlabs.org/2010/12/port-scanning-with-html5-and-js-recon.html) -blog post published by them to understand this vunerability at more detail -level. +blog post published by the AndLabs briefly describing this venerability at more +detail level. -If I do a XML HTTP request to a random port of localhost, response timing of +If I do an XML HTTP request to a random port of localhost, response timing of empty ports is faster than the response of ports where any service is running. -If you do a XML HTTP -Requests to cross domain, browser will expect an appropriate CORS headers in -response. Requests which aren't returning a response with appropriate CORS -headers are failed by the browser. - -Which means, anyone +If you do a XML HTTP Requests to cross domain, browser will expect an +appropriate CORS headers in response. Requests which aren't returning a +response with appropriate CORS headers are failed by the browser. +Which means, anyone CORS a half way protection Ajax request to cross domain are prevented by a browser to avoid CORS attacks. -If you are not aware what CORS is, then I suggest you to read [this][cors_guide] -post before progressing further. +If you are not aware what CORS is, then I suggest you to read +[this][cors_guide] post before progressing further. What happens when you do an ajax request to "https://localhost:8084"? If any service is running on port *8084* at your computer, then a browser will forward your request to that service. When that service returns any response, the browser checks for the CORS headers in the response. Responses without -appropriate CORS headers are dropped by the browser. From the client side, there -is no way to identify a reason for failed request. You can't identify that the -request failed because of CORS error or 404 until you track it in debug console -of your browser. +appropriate CORS headers are dropped by the browser. From the client side, +there is no way to identify a reason for failed request. You can't identify +that the request failed because of CORS error or 404 until you track it in +debug console of your browser. The error response from the browser for XHR on ports where any service is -running is late than ports where no services are running. The delay in coming +running is later than ports where no services are running. The delay in coming response exposes this variability to finger print open TCP ports at client workstation. - My motivation for writing this tool -Browser is the most common tool used by us. Asserting this venerability requires -knowledge of Javascript and everyone is not a developer. Despite trying hard, I -failed to find the source code of JS-Recon (the tool written by AndLabs proving -possibility of this attack). I am sharing this tool so that you or anyone else -irrespective of your technical backgrounds can try this tool to verify the -possibility of this attack. +Browser is the most common tool used by us. Asserting this venerability +requires knowledge of Javascript and everyone is not a developer. Despite +trying hard, I failed to find the source code of JS-Recon (the tool written by +AndLabs proving possibility of this attack). I am sharing this tool so that you +or anyone else irrespective of your technical backgrounds can try this tool to +verify the possibility of this attack. [cors_guide]: https://add-cors-guide.com From 680d932c824d1c81628cc66c0d6512f6784b440d Mon Sep 17 00:00:00 2001 From: ultimatecoder Date: Sat, 20 Apr 2019 19:34:37 +0530 Subject: [PATCH 5/5] Improving the blog post --- _posts/draft.md | 120 ++++++++++++++++++------------------------------ 1 file changed, 44 insertions(+), 76 deletions(-) diff --git a/_posts/draft.md b/_posts/draft.md index a265e16..f9dd6a7 100644 --- a/_posts/draft.md +++ b/_posts/draft.md @@ -1,19 +1,19 @@ -tldr; +### TL;DR; -Chatur is a Javascript based port scanning tool. This tool proves the -possibility of fingerprinting open TCP ports at client workstation using pure -Javascript. +Chatur is a Javascript based port scanner. This tool proves the vulnerability of +fingerprinting open TCP ports at client workstation using Javascript. -Background + +### Background Recently, I came across a possibility to fingerprint open TCP ports at client workstation using browser side (aka client side) Javascript. This attack is discovered by AndLabs in the year 2010. In this section, I will explain the -anatomy of this venerability in simple way. I expect you are able to understand -the basics of XML HTTP Request. +anatomy of this venerability in the simplest way. Knowledge of basic XML HTTP +Request is expected to understand this post. -What happens when you fire an XHR? +#### What happens when you fire an XHR? Browser initiates a TCP socket at the destination URL and sends header and body of the request. Once header and body is sent, browser terminates the active @@ -21,92 +21,60 @@ socket and waits for the server to deliver a response. That is how HTTP works under the hood. -If I write a Javascript code to put a XHR to 'http://localhost:8084' and host -that code at 'xyz.com' then when you visit the 'xyz.com' the browser will fire -that XHR to port '8084' of your workstation because 'localhost' for your -browser is your workstation. This gap invites many vulnerabilities for user. -One of them is the possibility to fingerprint open TCP ports at client -workstation. - -While observing the timing browser took to receive headers from the server were -highlighting a clear pattern. Responses - - - - - -Browser opens a socket to the destination URL, sends header and then sends body -of the request to the server and terminates the socket. That's how HTTP is -designed. In our example, browser will open a TCP client socket to -'http://localhost:8084' and sends header and body and terminates the socket. +#### How to fingerprint open TCP port of client workstation? +If I write a Javascript code to put a XHR to 'http://localhost:8084' and host +that code at 'xyz.com' then when you visit the 'xyz.com' the browser will fire +that XHR to port '8084' of your workstation because 'localhost' for your browser +is your workstation. This gap invites many vulnerabilities for user. One of +them is the possibility to fingerprint open TCP ports at client workstation. +While counting the time browser took to receive headers from the destination +were highlighting a clear pattern. A XHR to port where no service was running +were returning quick than a occupied port. -Using `XMLHTTPRequest.onstatechange` listener, we can identify - - -If you want to fingerprint that any dedicated port at client workstation is -open or closed, you just fire XHR to that port. - - - - +#### Algorithm -If bunch of XHR on different ports of localhost and capture the time browser -took to open the socket then you can obser that response timing The browser(and -operating system) takes bit longer time to open a socket on a non-empty port. +1. Fire a bunch of XHR at a target port of client workstation. +2. Measure the time browser took to receive the response headers +3. If timing of response headers is greater than the usual response time + repetitively consider that any service is running on that port. -That request will touch the workstation of whoever is browsing my website. This -is possible because browser do not block XHR to 'localhost'. Using this gap I -and founder of this vunerability has observed one common pattern in response -timings. Requests to non empty ports were returning late than ports where no -service was running. Using this clue, if response on such port is delayed we -can claim that there is an active service on such port. -I will suggested reading +You should read [this](http://blog.andlabs.org/2010/12/port-scanning-with-html5-and-js-recon.html) -blog post published by the AndLabs briefly describing this venerability at more -detail level. +blog post published by the AndLabs which is briefly describing this +venerability. -If I do an XML HTTP request to a random port of localhost, response timing of -empty ports is faster than the response of ports where any service is running. +### Chatur -If you do a XML HTTP Requests to cross domain, browser will expect an -appropriate CORS headers in response. Requests which aren't returning a -response with appropriate CORS headers are failed by the browser. +#### How to pronounce Chatur? -Which means, anyone +The Cha is Charming and Tur is Turn. Cha-Tur. You can observe +[this][chatur_videp] -CORS a half way protection +#### How Chatur works? -Ajax request to cross domain are prevented by a browser to avoid CORS attacks. -If you are not aware what CORS is, then I suggest you to read -[this][cors_guide] post before progressing further. +Chatur accepts range of ports and floods all them with XHR. It captures the +response time browser took to return the headers for all the requests. From +header response time of all the requests, unusual hike is considered as occupied +port. -What happens when you do an ajax request to "https://localhost:8084"? +#### My motivation for writing this tool -If any service is running on port *8084* at your computer, then a browser will -forward your request to that service. When that service returns any response, -the browser checks for the CORS headers in the response. Responses without -appropriate CORS headers are dropped by the browser. From the client side, -there is no way to identify a reason for failed request. You can't identify -that the request failed because of CORS error or 404 until you track it in -debug console of your browser. +Browser is the most common tool used by us. Asserting this venerability requires +knowledge of Javascript and everyone is not a developer. Despite trying hard, I +failed to find the source code of JS-Recon (the tool written by AndLabs proving +possibility of this attack). I am sharing this tool so that you or anyone else +irrespective of your technical backgrounds can try this tool to verify the +possibility of this attack. -The error response from the browser for XHR on ports where any service is -running is later than ports where no services are running. The delay in coming -response exposes this variability to finger print open TCP ports at client -workstation. -My motivation for writing this tool +#### Feedback -Browser is the most common tool used by us. Asserting this venerability -requires knowledge of Javascript and everyone is not a developer. Despite -trying hard, I failed to find the source code of JS-Recon (the tool written by -AndLabs proving possibility of this attack). I am sharing this tool so that you -or anyone else irrespective of your technical backgrounds can try this tool to -verify the possibility of this attack. +Please share your feedback with me. [cors_guide]: https://add-cors-guide.com +[chatur_video]: https://add-chatur-video.com