Slashdot Mirror
Java and Python FTP Attacks Can Punch Holes Through Firewalls (csoonline.com)
"The Java and Python runtimes fail to properly validate FTP URLs, which can potentially allow attackers to punch holes through firewalls to access local networks," reports CSO Online. itwbennett writes: Last weekend security researcher Alexander Klink disclosed an interesting attack where exploiting an XML External Entity vulnerability in a Java application can be used to send emails. At the same time, he showed that this type of vulnerability can be used to trick the Java runtime to initiate FTP connections to remote servers. After seeing Klink's exploit, Timothy Morgan, a researcher with Blindspot Security, decided to disclose a similar attack that works against both Java's and Python's FTP implementations. "But his attack is more serious because it can be used to punch holes through firewalls," writes Lucian Constantin in CSO Online.
"The Java and Python developers have been notified of this problem, but until they fix their FTP client implementations, the researcher advises firewall vendors to disable classic mode FTP translation by default..." reports CSO Online. "It turns out that the built-in implementation of the FTP client in Java doesn't filter out special carriage return and line feed characters from URLs and actually interprets them. By inserting such characters in the user or password portions of an FTP URL, the Java FTP client can be tricked to execute rogue commands..."
"The Java and Python developers have been notified of this problem, but until they fix their FTP client implementations, the researcher advises firewall vendors to disable classic mode FTP translation by default..." reports CSO Online. "It turns out that the built-in implementation of the FTP client in Java doesn't filter out special carriage return and line feed characters from URLs and actually interprets them. By inserting such characters in the user or password portions of an FTP URL, the Java FTP client can be tricked to execute rogue commands..."
and you can block secondary outbound traffic, and when you do, chrome complains:
A Parser-blocking, cross-origin script, http://www.googletagservices.com/tag/js/gpt.js, is invoked via document.write. This may be blocked by the browser if the device has poor network connectivity. See https://www.chromestatus.com/feature/5718547946799104 for more details
IMO, the issue isn't in Java FTP. It is in the code that calls the library
Tthe original cite mentioned the XML default DTD parser - see https://shiftordie.de/blog/2017/02/18/smtp-over-xxe/
Note that this is the sort of thing that can happen when you don't sanitize your inputs - just like in a SQL injection.
Personally I always either turn off DTD expansion or provide my own (generally I turn it off).
You may also want to take a look at https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Prevention_Cheat_Sheet
Of course the Sun FTP library could probably be hardened a bit more, for the half dozen or so people still ignoring Oracle's advice to never call the Sun APIs.
But from what I can see, org.apache.commons.net.ftp doesn't call the shell at all, so any such attack would depend completely on the code surrounding the call to FTP.
I find that these sorts of investigations and the warnings they generate tend to be pretty iffy
because they are not testing any particular application - just testing the APIs with code of their own choosing.
Click-bait with an alarmist tone... how utterly mundane.