Apache Solr bug is hit with cryptomining attack

Share this…

Hackers hit over 1,400 Apache Solr servers at the end of February to install a cryptocurrency miner.

According to information security training researcher Renato Marinho, the Apache Solr attackers are using the critical remote code execution vulnerability tagged as CVE-2017-12629. The Apache Software Foundation released a fix for this in October. Solr is a widely used Apache program for building search functionality into websites.

apache solr

Marinho reckons the Solr attackers are the same group who installed Monero miners on vulnerable Oracle WebLogic servers to generate the equivalent of $226,000 in Monero.

“Now that most Oracle WebLogic servers are fixed, miscreants had to move to another target,” the information security expert Marinho wrote in a blog. “Within nine days, from February 28 to March 8, this single campaign exploited 1,416 vulnerable Apache Solr servers to deploy Monero XMRig miners across the globe.”

It’s not known how much Monero the attackers have generated from compromised Solr servers because they’re using a proxy to access Monero miner pools, which allows them to hide their Monero wallet addresses, Marinho told.

Servers, as opposed to PCs, are an attractive target for cryptomining in general because they’re more likely to be running on powerful CPUs.

The attackers are scanning the internet for available Solr servers and using a publicly known exploit that was released in October.

After compromising a machine, the attackers load a bash script that deploys the XMRig miner and sets up tasks to ensure the miner is chugging away day and night. Admins will be able to see a process called ‘fs-manager’ running on affected machines connected to the miner pool through the address ‘pool-proxy.com’ on port 8080.

The information security training specialist notes that IBM InfoSphere version 11.5, JBoss Data Grid versions 7.0.0, 7.1.0, JBoss Enterprise Application Platform (EAP) versions 6, 7, 7.0.8, and JBoss Enterprise Portal Platform version 6 may also be vulnerable to this attack because it exploits vulnerability in a shared library.