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
Does this same vulnerability exist in the org.apache.commons.net.ftp stuff?
Have gnu, will travel.
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.
Is it any surprise he gave $25,000,000 to Trump's campaign?
He ruined Sun and Java. No surprise there.
RIP Sun.
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?
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.
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
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
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/