3

Suddenly, starting from about yesterday-evening (gmt+2), I get lots of -what I suspect are- 'hits' from bots that are looking variations of this file:

/somerealpath/includes/formvars.php

I'm curious to know what this is, and why so suddenly these scans?

They all seem to scan the same couple of paths. They could be getting these as the first xx google hits, but they are exactly the same each time.

  • The root,
  • one special subdir
  • a pdf in that subdir.

The scans come from various ip's, but they all have useragent:

 "Mozilla/5.0 (iPad; U; CPU OS 3_2_1 like Mac OS X; en-us) AppleWebKit/531.21.10 (KHTML, like Gecko) Mobile/7B405"

Which, for some sort of security-problem-scan seems odd: why would they all scan with the same tool? Why are they all using the same urls to check for the file?

I doubt think it is a targeted attack as the volume isn't big enough to cause major trouble, and the file doesn't exist anywhere so trying again and again isn't usefull...

It could be some sort of zero-day for something that came with a tool that included user-agent spoofing and some sort of "find some valid urls trough google" code, but that would also be strange? And why not guess some sort of /pathwiththelibraryname guess in between?

The only thing I can find with that filename is some sort of webcalendar but the file itself seems clean enough (only some function), so I doubt that's it.

I'm just curious about what this might be (and annoyed at the errors it creates in my logfiles, but that's another thing :) )

Community
  • 1
Nanne
  • 133
  • 6
  • They are not using the same tool, they are spoofing their agent, seems strange they would claim they are using Mozilla 5.0 on OS X/iOS though – Ramhound Apr 25 '12 at 15:25
  • Yes, I might have formed that sentence a bit strange, but as all the ip's are spoofing the exact same useragent, I doubted that this is a coincidence: the only way that would be the case if the spoofing was done by a "third party", so either a tool, or they are botnet or something? That's what I tried to say at least. – Nanne Apr 25 '12 at 15:31

1 Answers1

4

The file /include/formvars.php is used by WebCalendar. About 2 days ago, (April 23rd 2012) a remote code execution exploit for WebCalendar was released.

Although /include/formvars.php isn't the actual vulnerable file, its a good way of verifying that WebCalendar is installed. Its looks like the attacker needs install/index.php and includes/settings.php however these files are very common so by checking if these files are present there is no guarantee that its actually a WebCalendar instance. If the file /include/formvars.php is present, it will likely follow up with a POST request to install/index.php to inject PHP code and then a GET request to includes/settings.php to execute the injected payload.

rook
  • 46,916
  • 10
  • 92
  • 181
  • AH, good find! I couldn't find anything related to webcalendar, not too good in finding these exploits it seems :). Do you have any clue as to why all the people exploiting seem to use the same browserspoofing? – Nanne Apr 25 '12 at 16:54
  • 1
    @Nanne its just some auto-hacker script spitting out http requests, so it can specify anything as the UA. This happens every time a RCE flaw like this comes out, nothing special. – rook Apr 25 '12 at 16:56
  • Probably :). Ofcourse I see many of these checks appear, but this was the first that I noticed they use the same settings for their script. The ones that check for phpmyadmin seem to use different settings al the time, that's why it registered as strange to me. – Nanne Apr 25 '12 at 17:03
  • My log shows 3 sets of hits today from 3 IPs with same profile including same user agent. – mgkrebbs Apr 25 '12 at 20:39