One of the things we feel is important in discussing security threats to websites is to be realistic about the potential dangers of those threats. Far to often security companies will try to hype up minor issues, leading to unnecessary concerns about some things and to little concern about other things. One thing we see them doing is making a big deal about the amount of hacking attempts going on, while not mentioing that the success rate of those hacking attempts is incredibly small and many are done by people who clearly don’t know what they are doing. That second issues involves things like hackers try to exploit vulnerabilities that don’t actual exist or, as discussed in this post, doing things that make sure they won’t be successful in their hacking attempts.

In the past on this blog we have said that if it were not for us a lot of known vulnerable WordPress plugins would remain in the Plugin Directory. A quick reminder of that came last week when looking through a series of hacking attempts we saw one for a plugin that we did not have any vulnerabilities listed for yet:

/wp-content/plugins/spicy-blogroll/spicy-blogroll-ajax.php?var2=../&var4=../../wp-config.php

Through a quick search we found that a local file inclusion vulnerability had been disclosed in that plugin, Spicy Blogroll, July 13, 2013. The plugin was still available in the Plugin Directory despite that vulnerability still being in the current version (we notified the Plugin Directory of the issue last week, but they have yet to take action).

The plugin hasn’t been updated in five years, so not surprisingly it isn’t in wide use at this point, with just 60+ active installs according to wordpress.org. The stats page also shows that they are not many downloads of it these days either:

A hacker trying to exploit the vulnerability at this point really doesn’t seem to make much sense, seeing as the chance that you would happen to hit a website running it are incredibly low.

In this case there is the larger problem that their exploitation attempt could not succeed even if the website had the plugin installed. To understand why that is we need to look at the code the  relevant plugin file, /spicy-blogroll-ajax.php.

The local file inclusion occurs here:

14

require_once($var2.$var4);

That require_once() function using variables defined here:

9

$var2 = unscramble($_GET['var2']);

11

$var4 = unscramble($_GET['var4']);

Those take user inputted variables and pass them through the function unscramble(), which is defined later in the file:

31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

function unscramble($text1){
 $len=strlen($text1);
 $rng=ord(substr($text1,1,1))-70;
 $rn=$rng%2;
 $seed=ord(substr($text1,0,1))-$rng-64;
 $count=7;
 $text2='';
 for($i=2; $i<=$len-1; $i++) {
 $seed*=-1;
 $count+=1;
 $ch=ord(substr($text1,$i,1))-$seed;
 if ($ch==42){$ch.=92;}
 $text2.=chr($ch);
 if($count%5==$rn){$i++;}
 }
 return $text2;
}

The hackers clearly didn’t look closely at the code or test the vulnerability attempt before attempting to attack websites as they missed the GET values they sent would be run through that unscramble() function.

So instead of including the file

../../../wp-config.php

the file

55(4qv’iilcm(vj

is included.

That obviously isn’t going to accomplish what they were trying to accomplish.

That isn’t the end of their problems. It looks they thought this was an arbitrary file viewing vulnerability, which would have allowed them to view the contents of the wp-config.php file. But since it is a local file inclusion vulnerability, it would have instead caused that file to be included. Since the wp-config.php is included whenever you request a WordPress page, including it in this instance would haven’t been dangerous.