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

Comments

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:so can javascript

[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:so can javascript

[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:sun.net.ftp....

[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_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.

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.