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

18 comments

  1. so can javascript by Anonymous Coward · · Score: 3, Interesting

    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

    1. Re:so can javascript by Z00L00K · · Score: 1

      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.

      --
      If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
    2. Re:so can javascript by Mikkeles · · Score: 2

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

      --
      Great minds think alike; fools seldom differ.
    3. Re: so can javascript by Anonymous Coward · · Score: 0

      Nice work, you just reinvented the hugely effective and popular applet sandbox

    4. Re: so can javascript by Anonymous Coward · · Score: 0

      It's called Same-Origin Policy and it's already standardized and implemented in browsers. The problem is that there are too many exceptions where SOP doesn't apply.

  2. sun.net.ftp.... by PPH · · Score: 1

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

    --
    Have gnu, will travel.
    1. Re: sun.net.ftp.... by Anonymous Coward · · Score: 0

      It will in the Great Southern Firewall.

    2. Re:sun.net.ftp.... by Anonymous Coward · · Score: 2, Insightful

      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.

  3. So for a PHB... by Anonymous Coward · · Score: 0

    So, the PHB version of this is any programming language with 'Java' in its name is bad.

    And language that sort of looks like an advanced degree (PhP) is bad.

  4. Larry Ellison by Anonymous Coward · · Score: 0

    Is it any surprise he gave $25,000,000 to Trump's campaign?

    He ruined Sun and Java. No surprise there.

    RIP Sun.

  5. Client side attack by Anonymous Coward · · Score: 0

    This is just a client side attack. Repeatedly saying a technique can "punch holes through firewalls" does not make it any more so than spam emails can "punch holes through firewalls" just because a user requests the contents of their inbox.

    If the researchers tried and succeeded against a system that has a firewall designed to filter filesystem transverse characters from URL's and they still worked, then the statement would be true.

    Why do they think that sensationalist drivel will work against security professionals that are trained to spot social engineering?

  6. Firewall problem not really about FTP clients by Anonymous Coward · · Score: 0

    If an attacker can write code in Java and Python to pierce a firewall, then the problem is in the firewall itself. Correcting such "bug" in the http client would only make an attacker change from Java/Python into C/C++ to implement the "feature" needed to pierce the firewall.

    1. Re:Firewall problem not really about FTP clients by Anonymous Coward · · Score: 0

      Let's not forget the fact that FTP should have been closed and buried long ago.

  7. XML external entities by Ed+Avis · · Score: 1

    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.

    --
    -- Ed Avis ed@membled.com
  8. RFC3986 URI parser for Java by Anonymous Coward · · Score: 0

    Best bet is to parse URL's strictly according to RFC3986, then these characters will be escaped, the result can be safely passed to URL as a string.

    An RFC3986 URI java implementation can be found here:

    https://github.com/pfirmstone/JGDMS/tree/trunk/src/org/apache/river/api/net

  9. I supplement firewalls w/ hosts by Anonymous Coward · · Score: 0

    See subject: Most malware uses hostsnames is why. I do so via NEW APK Hosts File Engine 9.0++ SR-7 32/64-bit https://www.google.com/search?hl=en&source=hp&biw=&bih=&q=%22APK+Hosts+File+Engine%22+and+%22start64%22&btnG=Google+Search&gbv=1/

    Ads & malware rob speed/security/privacy

    Hosts add speed (via hardcodes/adblocks), security (vs. bad sites/malware/poisoned dns), reliability (vs. dns down), & anonymity (vs. dns requestlogs/trackers).

    Less power/cpu/ram + IO use vs. DNS/routers/addons/antivirus + less security bugs/complexity & faster vs. addons/routers/remote dns!

    Avoids DNSChangers in routers/IP settings & dns redirects (99.999% of ISP DNS != patched vs. it) + lightens DNS load & resolves faster from local system RAM!

    * Via what u NATIVELY have built into the IP stack in FASTER kernelmode!

    APK

    P.S. - Safe https://www.virustotal.com/en/file/e01211ca36aa02e923f20adee0a3c4f5d5187dc65bdf1c997b3da3c2b0745425/analysis/1433430542/