Meaningless http request

Question

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?

score 21 · Accepted Answer · answered Sep 19 '12 at 06:09

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.

answered Sep 19 '12 at 06:09

Polynomial

135,049
43
306
382

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 Sep 19 '12 at 08: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 Sep 19 '12 at 08:41
that's pretty much what I meant, randomly (okay pseudo-random 2am basement two-fingered keyboard hammering) generated during coding. – GdD Sep 19 '12 at 09: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 Sep 19 '12 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 Jan 09 '19 at 21:40

user133431 · Answer 2 · 2016-12-14T18:17:33.227

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

edited Dec 14 '16 at 18:17

answered Dec 14 '16 at 18:04

user133431

21
3

3

source? proof? example? – schroeder Dec 14 '16 at 18:06
1

Here is a request to the authentication page: – user133431 Dec 14 '16 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 Dec 14 '16 at 18:18
Do a search for "XX/YY/ZZ/CI/" and you'll see that many different sites use the same pattern – schroeder Dec 14 '16 at 18:20

Ivan · Answer 3 · 2019-01-09T19:11:30.253

/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.

Meaningless http request

3 Answers3