It didn't take long for hackers to weaponize (opens in new tab) a critical Java vulnerability for profit. Using the Log4J exploit, an unidentified actor managed to wrestle control of HP's AMD-based 9000 EPYC servers, turning the powerful hardware into cryptocurrency miners. The feat provoked a doubling of the hash rate for the CPU-based cryptocurrency Raptoreum (RTM) from 200 MH/s to 400 MH/s before most of the exploited machines were brought offline.
Log4J is a Java vulnerability recently outed as part of the famous Apache suite and merited the highest-possible threat classification (10) under the "CVSS 3.0" guidelines. This is because the exploit doesn't require physical access and allows for escalation of privileges to trick the system into connecting to, downloading, and running malware from a hacker-controlled server. Several software providers have patched the vulnerability, but that wasn't the case for HP's EPYC 9000 machines.
HP's EPYC server seems to have been targeted for one reason only: To mine Raptoreum (RTM), a CPU-based cryptocurrency based on a Proof-Of-Work (PoW) model that leverages the GhostRider algorithm. Ghostrider combines the x16r and CryptoNight algorithms and plays particularly nice with AMD's cache-dense Zen designs. And while AMD's mainstream Ryzen 9 5900X (12-core) and 5950X (16-core) both feature 64 MB of L3 cache, the company's Zen 3-based EPYC Milan CPUs double that to 128 MB, increasing performance and daily earnings. AMD's upcoming Milan-X EPYC CPUs are bound for market release in 2Q 2022. The processors will up the L3 cache size to a whopping 768 MB by leveraging 3D V-Cache - one can only imagine what sort of hash rates that upcoming silicon will be able to unlock.
Raptoreum developers first noted an unusual uptick in hash rate from December 9th. While the number of machines contributing to Raptoreum has been steadily increasing, December 9th saw an abnormal jump in network hash rate from its typical 200 MH/s up to a literal doubling, at 400 MH/s - with the increase coming from a single wallet address.
In a statement to EIN News, a leading Raptoreum developer explained that "During the attack, many servers were breached, each outputting a significant amount of hash power on very high-end server equipment. Very few organizations in the world have their hands on this kind of hardware, making it extremely unlikely that the attack was done using the individual's own hardware. Through a private investigation, there is now strong evidence that suggests Hewlett-Packard 9000 EPYC server hardware was being used to mine Raptoreum coins."
"We discovered that the miners they were using were all given HP nicknames and were all stopped abruptly which fortifies speculation of a company breach, followed by a patch of the servers. The Log4J Raptoreum mining exploit started December 9th until it mostly ended on December 17th. During this period hackers were able to collect approximately 30% of the total block reward which is roughly 3.4 million Raptoreum (RTM (opens in new tab)), worth around $110,000 USD as of 12/21/2021. Although activity has dropped considerably, it is actively mining to this day on what still looks to be a single premium machine which has failed to patch."
Out of the 3.4 million Raptoreum tokens held in the wallet, the hackers managed to move around 1.5 million of them, cashing them in via the CoinEx exchange. The remainder 1.7 million tokens were left idling - perhaps waiting for positive price-action before cashing out on the prospective earnings. Interestingly, Raptoreum's valuation remains unaffected by the sudden wallet action - which would have been in the top 20 wallets at the 3.4 million RTM mark.
And as the article points out, this Java exploit (or rather Apache exploit) doesn't require physical access to the systems to be performed. This recently-revealed exploit is being called one of the most serious security vulnerabilities ever, and all sorts of businesses and government agencies worldwide have been getting their servers hacked in recent weeks.
It's the result of a bug in popular open-source server software that's been present and overlooked in the code for the better part of the last decade. If there's any "inside job" involved, it would be with flaws getting purposely introduced into open-source code by contributors, though it could just as easily be an accidental oversight in the code. A lot of companies and organizations like to believe that open-source software is somehow immune from serious flaws, but realistically, there are likely numerous flaws like this that have been hiding in the code that runs the internet for years. When a particular piece of software sees such widespread use, such flaws coming to light can cause widespread security breaches around the globe. And it can often take weeks or potentially even months for an organization to get all their servers patched.
But insiders with godlike access do the same, and worse.
I wonder how well peer-review of incoming submissions operates within the Apache team, then again, I'd imagine a product as well established as this should be at least equally comparable to any commercial company. Irrespective, the bug originated in this open source code. It's going to be extremely interesting to look at the relevant submission/s that contributed to this exploit.
On a separate, though connected note, as programming languages and dependencies march onwards towards greater and greater levels of abstraction, then we run an increasingly significant danger of losing our ability of communicating in the only language CPU's understand...machine code(/assembly language). The same, of course, applies with every other programmable device, and this looming 'issue' is only going to get worse over time.
Maybe someone within the organisation wanted to see how wanted to test something out while the hardware was not doing much in the run up to Christmas and running this was better solution than trying to fake up a work load?