19

We've been logging GET requests on our domain to the following:

XX/YY/ZZ/CI/MGPGHGPGPFGHCDPFGGHGFHBGCHEGPFHHGG

This has no meaning on our site. A search on the web revealed no information, but a few other places which logged similar requests.

Is this a known kind of attack? What might it be targeting?

3 Answers 3

21

This is a malicious request, but it's not trying to exploit a vulnerability. It's trying to generate a 404 page, in order to determine what kind of web server or CMS you're running, by identifying tokens in the page source. Error pages often specify their CMS name and version, or the web server name and version, so it's an easy target for recon.

Best advice I can give you is to keep everything patched, and make sure your firewall rules are properly configured. Primary targets are likely to be your CMS and web server, but your OS is important to patch too.

If you've got a few IPs that constantly do it, and you're certain they're not valid customers, feel free to block them for a few weeks to see if they remain persistent.

5
  • 1
    I completely agree with @Polynomial, classic random-generated garbage. Check your error pages to see what information you may be leaking about your setup like OS, versions, etc. The more an attacker can learn the easier it is to exploit your system, so make sure your error pages give as little information as possible
    – GdD
    Commented Sep 19, 2012 at 8:03
  • @GdD Interestingly, it's not random. You can find a few instances on Google. The last part looks like keyboard hammering (notice the proximity of the letters on a qwerty keyboard) so I guess it's a hard-coded value designed to always generate a 404.
    – Polynomial
    Commented Sep 19, 2012 at 8:41
  • that's pretty much what I meant, randomly (okay pseudo-random 2am basement two-fingered keyboard hammering) generated during coding.
    – GdD
    Commented Sep 19, 2012 at 9:23
  • 1
    I'd also recommend installing mod_security and the OWASP Core Ruleset if you're on Apache. If it doesn't block this bot already it probably soon will. This will mean that if you ever do slip up and leave a gap between a patch being available and you installing it, they still won't get the 404 page to identify that you're vulnerable, they'll get a 403 instead. The Core Ruleset may also block the bot that exploits the vulnerabilities in addition to the recon bot.
    – Ladadadada
    Commented Sep 19, 2012 at 12:27
  • It's also a good idea to modify the default response page for your webserver/CMS to something custom and including no information about your platform. Often servers will also return headers with information that clients don't need to know such as versions and build numbers. It's a good idea to check for those and see if you can remove them too. And definitely make sure you aren't running in a 'dev' mode where things like stacktraces are returned.
    – JimmyJames
    Commented Jan 9, 2019 at 21:40
1

This is not a malicious request. It is actually a request for the png logo of a Fortinet device. This logo is displayed on the authentication page of Fortinet firewalls and other Fortinet network devices.

That being said, if you are seeing many requests, it could be that an attacker is attempting to brute force the authentication.

Example Request:

Request URL:https://192.168.1.1:1003/XX/YY/ZZ/CI/MGPGHGPGPFGGHHPFBGFHEHIG
Request Method:GET
Status Code:200 OK
Remote Address:192.168.1.1:1003
Response Headers
view source
Connection:Close
Content-Length:1622
Content-Type:image/png
Request Headers
view source
Accept:image/webp,image/*,*/*;q=0.8
Accept-Encoding:gzip, deflate, sdch, br
Accept-Language:en-US,en;q=0.8
Connection:keep-alive
DNT:1
Host:192.168.1.1:1003
Referer:https://192.168.1.1:1003/fgtauth?000a089886bb41a2
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
4
  • 3
    source? proof? example?
    – schroeder
    Commented Dec 14, 2016 at 18:06
  • 1
    Here is a request to the authentication page:
    – user133431
    Commented Dec 14, 2016 at 18:13
  • while this might be true for some Fortinet devices, this pattern is true for multiple different sources - it's not Fortinet-specific
    – schroeder
    Commented Dec 14, 2016 at 18:18
  • Do a search for "XX/YY/ZZ/CI/" and you'll see that many different sites use the same pattern
    – schroeder
    Commented Dec 14, 2016 at 18:20
1
/XX/YY/ZZ/CI/MGPGHGPGPFGHCDPFGGHGFHBGCHEGPFBGAHAH
/XX/YY/ZZ/CI/MGPGHGPGPFGHCDPFGGHGFHBGCHEGPFHHGG
/XX/YY/ZZ/CI/MGPGHGPGPFGHCDPFGGOGFGEH

There are easier and more discreet ways to generate a 404 error to probe for server information. This URL pattern is an artifact of Fortigate/Fortinet and the modern cloud networking environment.

Fortinet's "stop watching porn at work" page makes a few calls to the above paths at url.fortinet.net:8008 in order to download static assets.

Your site is currently hosted on an IP that once was in scope of Fortinet's IP pool. It no longer is, but some hardcoded IP, DNS cache or crawler somewhere is having a hard time coping with this fact and refuses to let go, so you're seeing traffic errantly being redirected to your site instead of being sent to Fortinet.

You'll see similar behavior when you look at the HTTP logs for any web service you start up on a public cloud compute instance-- lots of traffic intended for the previous tenant. This is not a malicious request nor indicative of an attack and is safe to ignore.

For simple but effective security make sure your webserver is checking host headers-- it should only accept traffic that references your actual domain. Anybody who tries to go to http://36.10.52.4/index.html should not be served, they should only be served if they requested http://yoursite.com/index.html.

Doing things this way you can also configure your webserver to return custom HTTP codes (gone, permanently moved, etc.) to anybody requesting resources that belonged to former tenants.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .