FTP vulnerabilities and what you can do

Podjarny: Different ecosystems are sensitive to different types of vulnerabilities. The Node.js ecosystem, for instance, is especially susceptible to denial of service vulnerabilities, keeping the central execution thread busy and thus preventing it from serving other users. Hundreds, and at times thousands, of those are found each year. The Java ecosystem, on the other hand, is often tripped by deserialisation vulnerabilities, a sensitive operation performed when loading data into memory. While smaller in number, these vulnerabilities are often extremely severe, leading to remote command execution like the Struts vulnerability that tripped Equifax and the more recent "Spring Break” vulnerability.

ADM: What is the value of open source? How about its challenges?

Podjarny: Open Source lets us harness the power of the community to boost our own businesses, focusing our own efforts on building functionality that is truly unique. Its primary challenge is the inverted ownership - open source maintainers write the code but offer no warranties on maintaining it, requiring organisations using open source to manage software they know very little about. Now that enterprise adoption of open source has become pervasive, the need for better practices and tooling to help enterprises manage OSS is stronger than ever.

ADM: FTP is a widely used protocol, often used to pass files between companies. What is the potential impact of this vulnerability on enterprises?

Podjarny: This vulnerability exposes anyone using FTP to fetch files from an FTP server that is not fully trusted. The malicious FTP server can trick the client into saving files anywhere on the file system, potentially overwriting system files and leading to remote command execution.

ADM: How does the FTP Vulnerability impact the public?

Podjarny: The vulnerability affects services you may be using on a regular basis. For instance, a vulnerable stock exchange pulling information from different data sources using FTP may allow one data source to overwrite information from others. A social portal allowing users to import photos from an FTP site may take over the site and access other users information. These examples are hypothetical - the exact damage depends entirely on the attacker’s ability to reach an FTP server accessed by a vulnerable client.  

This is stemming from an old Linux vulnerability discovered 16 years ago, which means this wasn’t fixed and we haven’t learned from our mistakes. As with the recent Panera breach, where vulnerabilities were ignored and impacted millions of customers, why do we continue to make insecure decisions?

Avoiding a specific vulnerability once is easy, but avoiding all vulnerabilities all the time is extremely hard. Security at scale is incredibly complex, and developers can easily miss potential edge cases, especially when constantly pushed to ship software faster.

ADM: What are the security risks of allowing anonymous FTP read/write? Can anyone upload a sort of shell that would allow them to compromise the system?

Podjarny: FTP’s support for anonymous usage doesn’t make it less secure, but it does strengthen the need to mistrust and constrain the actions a client can make. In this specific case, the vulnerability is in the FTP client, not server, implying it knows which server it’s talking to (it won’t be fully anonymous), but it still shouldn’t trust it beyond what is necessary.

ADM: How do we process and validate data coming from FTP servers?

Podjarny: We should treat data coming from FTP servers as suspicious, and ensure we process it as data and nothing more. If we must use this data to guide programmatic actions, for instance deciding where should files be stored, we must scrutinise it very closely to ensure it’s not malicious. Most developers know they need to validate input coming from a user browsing their site, but many of those forget that information coming from a backend system - such as an FTP server - should be validated just the same.