{"vuid":"VU#328867","idnumber":"328867","name":"Multiple vendors' firewalls do not adequately keep state of FTP traffic","keywords":["firewall","TCP protocol","FTP protocol","bypass firewall","ICSA Labs","application layer"],"overview":"Firewalls and other systems that inspect FTP application layer traffic may not adequately maintain the state of FTP commands and responses. As a result, an attacker could establish arbitrary TCP connections to FTP servers or clients located behind a vulnerable firewall.","clean_desc":"Many firewalls perform stateful inspection of application layer traffic, allowing them to support passive FTP and other applications that  make connections using dynamically chosen ports. In the case of a passive FTP connection to an FTP server located behind a firewall, the firewall examines the application layer of the FTP control channel and interprets FTP commands and responses in order to determine what TCP ports the server is using for data connections. When a client requests a passive FTP connection by issuing the PASV command, the FTP server responds positively with a string like \"227 Entering Passive Mode h1,h2,h3,h4,p1,p2\", instructing the client to initiate a TCP connection to IP address h1,h2,h3,h4 on port p1,p2. The firewall monitors this string and creates a dynamic rule allowing an inbound TCP connection from the client to the server on the specified port. Some firewalls create dynamic rules without assuring that the PASV response string is part of a legitimate FTP connection. An attacker who is able to log in to an FTP server behind a vulnerable firewall issues an FTP command that echoes the argument of the command back to the attacker (NLST is one example of such a command). The attacker includes a PASV response string as the argument to the command, so that the PASV response \"227 Entering Passive Mode h1,h2,h3,h4,p1,p2\" is echoed back through the firewall. Using a spoofed IP address and a separate TCP/IP stack (libnet and libpcap), the attacker sends specially crafted TCP packets that acknowledge (ACK) the echoed response from the FTP server up to the start of the PASV response. If the operating system used by the FTP server supports the partial acknowledgement of TCP data segments (RFC 2581), it will resend the unacknowledged data, starting with the beginning of the PASV response. A vulnerable firewall will see a properly terminated PASV response at the start of a packet and create a rule allowing the client to connect to the specified port on the FTP server. This behavior has been previously discussed in public forums (February 2000): http://online.securityfocus.com/archive/1/47688/2000-02-12/2000-02-18/1\nhttp://online.securityfocus.com/archive/82/45571/2000-02-08/2000-02-14/1\nhttp://online.securityfocus.com/archive/82/45758/2000-02-08/2000-02-14/1\nIn the February 2000 discussion, a number of similar techniques are mentioned: using a URL with a properly padded FTP command (HTML email or web page with hostile URL sent to clients)\nusing other FTP commands (STAT) to echo PORT commands or PASV responses back through the firewall\nusing TCP MSS to control/lower the size of a TCP packet and properly align FTP commands and responses\nuploading a file or creating a directory with a crafted name that contains FTP commands, then using \"ls\" or similar to echo the command back through the firewall\nThese techniques, including the use of partial acknowledgement as described above, might also be used with the PORT command by a malicious FTP server to open connections to active FTP clients that are behind a vulnerable firewall. It is possible that similar vulnerabilities exist in the way firewalls handle other applications that use dynamic ports. FTP application layer gateways and proxy servers may also be affected. An FTP server or FTP client running on an operating system that does not accept partial acknowledgement of TCP data segments is not susceptible to this specific attack. FTP servers that do not pad 3-digit numbers within multi-line responses exacerbate this problem by making it difficult for firewalls to recognize legitimate FTP status codes (VU#288905). From section 4.2 of RFC 959: If an intermediary line begins with a 3-digit number, the Server must pad the front to avoid confusion. In rare cases where these routines are able to generate three digits and a Space at the beginning of any line, the beginning of each text line should be offset by some neutral text, like Space.","impact":"A remote attacker may be able to access TCP ports on an FTP server or client that is behind a vulnerable firewall system, which could expose other network services to attack.","resolution":"Apply Patch or Upgrade\nApply the appropriate patch or upgrade as specified by your vendor.","workarounds":"Disable FTP Inspection In some products it may be possible to disable the FTP application layer inspection feature, however this will most likely prevent passive FTP sessions from reaching an FTP server located behind a firewall, and may prevent active FTP sessions that originate from clients who are behind a firewall. Restrict Access Do not allow anonymous access to FTP servers from untrusted networks like the Internet. Note that this will only limit the number of potential sources of attacks; it will not prevent attacks from networks that are allowed to access the FTP servers. Disable Active FTP Do not allow untrusted FTP servers to initiate connections to FTP clients. This will prevent clients from using active FTP for data channel connections. Secure FTP Servers Keep exposed FTP servers up-to-date with the latest patches and disable all unnecessary services.","sysaffected":"","thanks":"The CERT/CC thanks Mikael Olsson of \nClavister AB\n and Al Potter of \nICSA Labs\n for reporting this vulnerability and providing information used in this document.","author":"This document was written by Art Manion.","public":["http://www.ietf.org/rfc/rfc959.txt","http://www.ietf.org/rfc/rfc2581.txt","http://online.securityfocus.com/archive/1/47688/2000-02-12/2000-02-18/1","http://online.securityfocus.com/archive/82/45758/2000-02-08/2000-02-14/1"],"cveids":[""],"certadvisory":"","uscerttechnicalalert":null,"datecreated":"2002-06-20T15:44:47Z","publicdate":"2002-10-07T00:00:00Z","datefirstpublished":"2002-10-08T15:43:57Z","dateupdated":"2003-03-07T21:59:17Z","revision":74,"vrda_d1_directreport":"","vrda_d1_population":"","vrda_d1_impact":"","cam_widelyknown":"15","cam_exploitation":"0","cam_internetinfrastructure":"13","cam_population":"9","cam_impact":"17","cam_easeofexploitation":"15","cam_attackeraccessrequired":"20","cam_scorecurrent":"24.0975","cam_scorecurrentwidelyknown":"28.400625","cam_scorecurrentwidelyknownexploited":"45.613125","ipprotocol":"","cvss_accessvector":"","cvss_accesscomplexity":"","cvss_authentication":null,"cvss_confidentialityimpact":"","cvss_integrityimpact":"","cvss_availabilityimpact":"","cvss_exploitablity":null,"cvss_remediationlevel":"","cvss_reportconfidence":"","cvss_collateraldamagepotential":"","cvss_targetdistribution":"","cvss_securityrequirementscr":"","cvss_securityrequirementsir":"","cvss_securityrequirementsar":"","cvss_basescore":"","cvss_basevector":"","cvss_temporalscore":"","cvss_environmentalscore":"","cvss_environmentalvector":"","metric":24.0975,"vulnote":null}