File Transfer Protocol or (FTP) for short is old, and when I say old - I mean 1971 old when it was initially published as RFC 114. It defines a way clients can transfer files to a server. Typically gated with a password and either sent clear text, or over SSL/TLS/SFTP, it’s a rock solid way to get files sent to their destination and is widely supported. But in today’s world of boundless vulnerabilities, FTP has it’s share of problems because it was never intended to be a secure protocol. FTP is open to brute force attacks, bounce attacks, packet captures, port stealing, spoofing, and other attacks.
We had a conversation with Guy Podjarny, the CEO, and co-founder of Snyk who is no stranger to security vulnerabilities with open source libraries. Check out the commentary below to learn more about common types of vulnerabilities, the impacts of FTP security problems, and what you can do to stop the threats.
ADM: What are the most common vulnerabilities?
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.