Java and Python FTP Attacks Can Punch Holes Through Firewalls

"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..."

so can javascript

[Anonymous Coward]

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

Re:

[Z00L00K]

I would say that it's not the language that's faulty, it's the lack of a proper sandbox. If some code is downloaded from a certain address then it shall only be allowed to access that address for further data.

As a side effect it would also kill all those cross-site ad loading scripts.

Re:

[Mikkeles]

Hey, why would one expect any different from languages made by hacks?

sun.net.ftp....

[PPH]

Does this same vulnerability exist in the org.apache.commons.net.ftp stuff?

Re:

[Anonymous Coward]

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

XML external entities

[Ed Avis]

I think it's a flaw in some XML or XSLT libraries that DTD expansion and external entity resolution is either on by default, or in some cases, cannot be turned off. It also opens up attack vectors for XML injection using xsl:include, where if an attacker can provide the XSLT he can also read arbitrary file contents. It would make more sense for the default XML mode to not allow fetching any external content, and you have to set a 'trusted' flag in the API to turn on the magic.