Currently supported functionality:
- Port Scans
- Network Scans
- Detecting private IP address
It works on the latest versions of Chrome, Safari and Firefox that support CORs and WebSockets.
Use it on Chrome and Safari for best results. Firefox throws exceptions sometimes when scanning through COR, not sure why this happens. Scans using WebSockets work properly though.
Currently it has been tested only on Windows XP and Win7 systems. Behavior could differ on Linux and Mac
Cross domain XHR has five possible readystate statuses and WebSocket has four possible readystate statuses. When a new connection is made to any service the status of the readystate property changes based on the state of the connection. This transition between different states can be used to determine if the remote port to which the connection is being made is either open, closed or filtered.
When a WebSocket or COR connection is made to a specific port of an IP address in the internal network the initial state of WebSocket is readystate 0 and for COR its readystate 1. Depending on the status of the remote port, these initial readystate statuses change sooner or later. The below table shows the relation between the status of the remote port and the duration of the initial readystate status. By observing how soon the initial readystate status changes we can identify the status of the remote port.
There are some limitations to performing port scans this way. The major limitation is that all browserís block connections to well known ports and so they cannot be scanned. The other limitation is that these are application level scans unlike the socket level scans performed by tools like nmap. This means that based on the nature of the application listening on a particular port the response and interpretation might vary.
There are four types of responses expected from applications:
- Close on connect: Application terminates the connection as soon as the connection is established due to protocol mismatch
- Respond & close on connect: Similar to type-1 but before closing the connection it sends some default response
- Open with no response: Application keeps the connection open expecting more data or data that would match its protocol specification
- Open with response: Similar to type-3 but sends some default response on connection, like a banner or welcome message
The behavior of WebSockets and COR for each of these types is shown in the table below.
The port scanning technique can be applied to perform horizontal network scans of internal networks. Since both an open port and a closed port can be accurately identified, horizontal scans can be made for specific ports that would be allowed through the personal firewalls of most corporate systems.
Identification of an open or closed port would indicate that a particular IP address is up.
Ports like 445 or 3389 are ideal for such purpose as these are usually allowed across personal firewalls of desktop systems. It has been found that port 445 is of Application type-1 on Windows 7 and can be detected whether it is open or closed. However port 445 on Windows XP and port 3389 are of application type-3 and the host can only be detected if these ports are closed on such systems.
Most home userís connected to WiFi routers are given IP addresses in the 192.168.x.x range. And the IP address of the router is often 192.168.x.1 and they almost always have their administrative web interfaces running on port 80 or 443.
These two trends can be exploited to guess the private IP address of the user in two steps:Step 1: Identify the userís subnet
This can be done by scanning port 80 and/or 443 on the IP addresses from 192.168.0.1 to 192.168.255.1. If the user is on the 192.168.3.x subnet then we would get a response for 192.168.3.1 which would be his router and thus the subnet can be identified.
Step 2: Identify the IP address
Once the subnet is identified we scan the entire subnet for a port that would be filtered by personal firewalls, port 30000 for example. So we iterate from 192.169.x.2 to 192.168.x.254, when we reach the IP address of the user we would get a response (open/closed) because the request is generated from the userís browser from within his system and so his personal firewall does not block the request.
To avoid Cross Protocol exploitation almost all popular browsers block connections to certains well known ports. Due to this the status of these ports cannot be determined.
The determination of port status is based on timing of the readyState status changes. Opening multiple simultaneous connections interferes with this timing leading to unreliable results. Hence to avoid such situations all scans are performed one port at a time.
Internal Networks Only:
As stated above, timing is critical to identification of port status. Depending on the location of the target device this timing could vary. JSRecon has been tuned to scan internal networks with very low turn around time. Scanning external networks would require only two minor changes - values of the variables open_port_max and closed_port_max must be suitable updated.