JoltandBleed vulnerabilities? What’s Up?
Oracle recently issued emergency patches for five vulnerabilities:
- CVE-2017-10272 is a vulnerability of memory disclosure; its exploitation gives an attacker a chance to remotely read the memory of the server.
- CVE-2017-10267 is a vulnerability of stack overflows.
- CVE-2017-10278 is a vulnerability of heap overflows.
- CVE-2017-10266 is a vulnerability that makes it possible for a malicious actor to bruteforce passwords of DomainPWD which is used for the Jolt Protocol authentication.
- CVE-2017-10269 is a vulnerability affecting the Jolt Protocol; it enables an attacker to compromise the whole PeopleSoft system.
Individually, each vulnerability is concerning and somewhat formidable. When combined—like the multi-colored lions of Voltron—they become extraordinarily powerful...if an attacker can get into the right place on the network to take advantage of them.
Why are the JoltandBleed vulns a Big Deal™?
As noted, if an attacker can get into the right place on a victim’s network, they can use an exploit crafted to take advantage of those five weaknesses to dump the contents of active memory of the application server; part of that memory includes usernames and passwords—including administrator-level credentials.
The industrious folks on the ERPScan team discovered these weaknesses, responsibly disclosed them to Oracle, presented them at DEEPsec last week, and have now demonstrated what they’ve called the JOLTandBLEED attack.
The most straightforward way to describe a potential attack scenario is that an adversary would use a flaw in the parameter handling of one opcode (“function call”) of the Jolt server to send bad parameters over-and-over-and-over-and-over-and-over again (there is no subtlety in this attack). As each connection is made, the exposed bits of memory are slurped up and can be post-processed to make out various data structures, including the in-memory database of usernames and passwords.
ERPScan has posted a video demonstration of the JoltandBleed attack but has not released proof-of-concept (PoC) code. No known malicious exploits exist.
What can I do?
As usual for coordinated vulnerability disclosures and patch releases, the best course of action we can recommend is to patch and restart at your earliest opportunity.
If your change windows and the stars aren’t aligned for your enterprise, however, there are definitely mitigations for this vulnerability. Let’s take a look at the reference architecture for PeopleSoft (the “Pure Internet Architecture”—PIA—in Oracle parlance):
Oracle also has a companion security guide for PeopleSoft and the PIA architecture. There are very detailed, network-segmented, high-availability configuration recommendations in that security guide.
From what we can tell—since no PoC code exists for us to test with—successful exploitation requires direct communication with Jolt/Tuxedo. This makes sense since the exploit requires hammering on an opcode with invalid parameters directly on the affected component. This should not be possible from the web server side, and the more sensitive components of the overall architecture should be isolated from the general network. Granted, organizations can and do customize the deployment of PeopleSoft to fit into various constraints. So, it is possible that some organizations deploy all the components on the same system(s) and expose them—intentionally or unintentionally—to network segments (possibly even the internet) where attackers can start to poke at them.
If you have had to make such alterations to the reference architecture, now would be a great time to re-think them and at least create host, switch, router and/or firewall access control lists (ACLs) or rules to prevent general access to the ports and services that are exposed. Of note, ERPScan found over 1,000 PeopleSoft instances hanging off the public internet and, in a highly targeted HTTP scan today on port 9001 today (2017-11-20) Rapid7 Labs identified nearly 500 likely vulnerable WebLogic instances across the globe:
Now, this is a noisy exploit. It requires hammering the service to pick out nuggets of memory that need to be recomposed to find useful bits. Instrumenting your logging and alerting environments to watch for this would be a great way to detect an in-progress attack and then employ orchestration (or notes/alerts to defenders) to block attackers.
Even if you’re not exposed on the internet, you may be (OK, “very likely are”) exposed internally and attackers are becoming fairly adept at gaining access to at least user-endpoints within organizations using traditional phishing and malware delivery techniques. You will definitely want to seriously consider that ACL advice from above applying to both internal and external network segments.
Rapid7 researchers are keeping an eye out for more PoC code and IRL exploit attempts and will issue further guidance as updates to this blog.
(Banner image by Jack Ebnet used CC-BY-SA)