Posts tagged e107
Previously I wrote a blog post about the ByroeNet/Casper-Like bot scanners, and relate that the most important evolution of these scanners where the integration of e107 RCE (EDB-ID : 12715) and LFI vulnerabilities exploitations. I created a rule to monitor precisely the activity of theses e107 dedicated exploitations.
Here under you can find real time graphs for the e107 RCE vulnerability.
Emerging Threats has provide, the 9 July, new Snort signatures (2011175 and 2011176) related to emerging attack attempts. These two signatures are categorized into the USER AGENTS recognition category, and identified as Remote File Inclusion scanners (see the discussion on ET mailing-list). The detection is done on “Casper Bot Search” and “MaMa CaSpEr” strings in the User-Agent part of HTTP header.
Directly in production these rules have fire tonnes of alerts, more than usual, something interesting was happening. I decided then to investigate more about theses alerts and checked all the ET mailing list conversations. Mike Cox has provide the source code of the scanner, the 8 July and directly when I saw it, tilt !
As I saw and says since many months the traditional RFI scanners are mutating constantly to include more and more functions and attack vectors (RFI, LFI, XML-RPC, RCE, targeted applications exploits).
This new scanner is only an evolution of the BaMbY multi functions scanner dated from 28/05/2010. Now the scanner is named “ByroeNet” and released the 17/06/2010. The ByroeNet scanner was first seen on Internet the 17/06/2010 on t7.fileave.com/e107.txt, so directly exploited just after his creation.
The major modification of the BaMbY fork is the integration of a scanning and exploiting module for e107 CMS. The !e107 (cmde107 – e107scan) scanner module, with support of dorks, is trying to exploit the 24 May 2010 e107 RCE released exploit. But between his traditional RFI scanner module and dorks, the scanner could also exploit the 31 May 2010 e107 RFI released exploit.
ByroeNet scanner is defining different hard coded user agents how are modifiable :
For sub cmdxml : my $userAgent = LWP::UserAgent->new(agent => ‘perl post’);
For sub cmde107 : $access->agent(“Mozilla/5.0”);
For sub e107scan : $ua->agent(‘Mozilla/4.76 [ru] (X11; U; SunOS 5.7 sun4u)’);
For sub xmlcek : my $userAgent = LWP::UserAgent->new(agent => ‘perl post’);
For sub xmlxspread : my $userAgent = LWP::UserAgent->new(agent => ‘perl post’);
For sub lfiexploit : my $agent = “”;
For sub cmdlfi : my $hie = “j13mbut /dev/stdout\”); ?>j13mbut”; $browser->agent(“$hie”);
After investigating our Honey Net HTTP logs, from 15 Jun to 12 July, I find these different user agents how are targeting e107 CMS.
You can find the default ByroeNet hardcoded user agents :
- Mozilla/4.76 [ru] (X11; U; SunOS 5.7 sun4u)
- perl post
But also Casper customized user agents :
And some new others customized user agents :
- b3b4s Bot Search
- dex Bot Search
- Dex Bot Search
- kmccrew Bot Search
- plaNETWORK Bot Search
- rk q kangen
- sasqia Bot Search
- sledink Bot Search
As you can see the user agents are only reflecting the “Crew” or “Team” how is using the “ByroeNet” scanner.
To have more interesting stats, we can see which user agent was the more prolific and the first seen.
Casper Bot Search is really the more prolific user agent, but the others user agents must also be considered.
For conclusion, the mutation of traditional RFI scanner is clearly demonstrated, and I don’t think that such ET rules are really effective, cause each “Crew” or “Team” is dedicating they attacks by customising the user agents (same as a graffiti tagger). Emerging Threats rules shouldn’t not focus on user agents but more on attack vectors, cause user agents are to volatile.