Google Chrome FTP PASV IP Malicious Port Scanning Vulnerability.

Vulnerability Stats:

1. Google Chrome FTP Client is vulnerable to FTP PASV malicious port scanning vulnerability.

2. The username in the FTP (ftp://username:[email protected]) can be manipulated by tampering

   it with certain IP address with specification of port as (ftp://xxx.xxx.xxx.xxx-22:[email protected]).

3. The Google Chrome FTP client make connection to the rogue FTP server which uses PASV commands to scan

   the internal as well external domain when conditions are met.

4. Dynamic requests are issued to a rogue FTP server which accepts connection with different usernames

   as the IP address with specified ports to locate the non existing object on the target domain.

   Request 1 : ftp://xxx.xxx.xxx.xxx-21:[email protected]

   Request 2 : ftp://xxx.xxx.xxx.xxx-22:[email protected]

   Request 1 : ftp://xxx.xxx.xxx.xxx-23:[email protected]

   Request 2 : ftp://xxx.xxx.xxx.xxx-25:[email protected]

   Request 1 : ftp://xxx.xxx.xxx.xxx-53:[email protected]

   Request 2 : ftp://xxx.xxx.xxx.xxx-69:[email protected]

5. The trick is applied through JavaScript Scanning.Do consider the same origin policy.

[RFC 959 States that]

“PASSIVE (PASV): This command requests the server-DTP to “listen” on a data port (which is not its default

data port) and to wait for a connection rather than initiate one upon receipt of a transfer command.The

response to this command includes the host and port address this server is listening on.”

“The User-PI may request the server side to identify a non-default server side data port with the PASV command.

Since a connection is defined by the pair of addresses, either of these actions is enough to get a different

data connection,still it is permitted to do both commands to use new ports on both ends of the data connection.   “

[Network Perimeter View]

The Google Chrome will issue request as:

[PID 4904] SEND: 220 FTP PASV

[PID 4904] RECV: USER 127.0.0.1-445

[PID 4904] SEND: 331 Please specify the password.

[PID 4904] RECV: PASS pass

[PID 4904] SEND: 230 Login successful.

[PID 4876] RECV: TYPE A

[PID 4876] SEND: 200 Switching to ASCII mode.

[PID 4876] RECV: PASV

[PID 4876] SEND: 227 Entering Passive Mode (127,0,0,1,0,23)

[Impact]

The FTP protocol includes the PASV (passive) command which is used by Google Chrome to request an alternate

data port. The specification of the FTP protocol allows the server response to include an alternate server

address as well, although this is rarely used in practice. A malicious web page hosted on a specially-coded

FTP server could use this feature to perform a generic port-scan of machines inside the firewall of the

victim. Moreover it is possible to scan other domains too for open targets. The generatedfraudulent request helps attacker

to exhibit internal network information through sustainable port scanning through JavaScript.

[Google Response]

I can repro this. Ignore the user/password part, the core problem is that in PASV

mode, Chrome will obey a server-issued instruction to connect to:

1) 127.0.0.1 or other local addresses,

2) Restricted TCP ports.

The security impact is that the browser would reveal service banners, if any, to the

scanning party. No data is sent to the service, but it’s still not a very nice thing

to do, so we should fix it.

Two obvious solutions come to mind:

1) Reject all ports < 1024 (as ftp in PASV mode is expected to use ephemeral ports on

server side).

2) Preferably, also apply the same port black list for > 1024 ports that we use for

http:// and ftp:// port checking,

3) Only connect back to ports on the system to which we initiated a connection (this

is heavy-handed, but IIRC, is followed by other browsers too), ignoring any IP data

returned by server. [ A finer-grained alternative is to block RFC private network <->

public network fenceposts (but this does not resolve the issue in all scenarios

imaginable). ]

[Greets]

Greets to Bindhsell Team for providing FTP PASV Technique. Very generic POC have been provided by Mark

from the bindshell team. The code is being modified for my own testing purposes but for generic usage

very good POC have been structured there. A detailed technical paper has also been published which will

explain in detail the technique. Please Refer: