Hacker News Reader

Comment by bediger4000 | Hacker News Reader

After looking at Apache httpd log files from a VPS running a Hugo generated blog, I have to agree. I see very few GET requests for favocon.ico, or CSS files or .js files, but tons of requests overall. There's a few well behaved bots (Google, bing, Apple, Seznam), a few less well behaved bots, based on user agent.

Then there's a ton of requests that are obviously machine generated due to the speed of arrival, and not asking for CSS or .js files, but not having a user agent string that indicates programmatic requests.

There's also a fraction of requests that seem to be probing for security vulnerabilities.

View on HN

Low(ish) traffic sites & servers have seen high-proportion-bot-and-vuln-scanner traffic since at least the late 90s. Solution used to be to blackhole IP blocks associated with certain countries, provided you didn't really, really need to serve those countries. Would usually stop 99% of it, so the logs were a lot less noisy and you could tell when you were under focused attack and needed to really pay attention (which was basically 100% of the time, without the blocks)

The modern version is letting CloudFlare hit IPs in those countries with never-ending CAPTCHA challenges.

I used to work in webhosting and HTTP logs are full of really weird stuff where you can't even really understand what they are trying to do. We would pass funny or novel ones back and forth for fun in the sysadmin Jabber chat. My favorite one (it became my internal email sig for a while) was something like:

GET ../../../../../etc/shadow.php?redirect=google.com

You try to follow the thought process just end up crosseyed: OK they are trying to use directory traversal to get the shadow file, but...they expect it to have a PHP extension. Well, I guess that could be some .htaccess RewriteRule misconfiguration that's relatively common. Ok but then they expect it to actually /be/ a PHP script and...to understand the "redirect" parameter? Hmm maybe this is possible if some other vulnerability lets them write to the shadow file. OK but if they can already write to arbitrary files on the machine, why use /etc/shadow, and why do any of this just to generate ... a 3xx to google.com?

Being as confusing as possible actually seems like a really good tactic. Depending on the web server and frameworks installed, couldn't etc/shadow.php actually be a file in a common framework? Also, if I wanted to be extra obscure, "redirect=google.com" wouldn't actually do what you think it would. It's just a key and a value which could be used for who-knows-what internally.

/etc/shadow is a file containing system account info that should never be accessible to the public on a properly-configured webserver. It's possible the request was probing for some very-specific combo of misconfigurations that might permit reading sensitive files, without going so far as to request the sensitive file.

Right, I understand that. What I probably should have made more clear was whether it was trying to get to /etc/shadow, or another .../etc/shadow.php file located somewhere within the web-server's file directory.

It was probably probing, not exploiting, and the “.php” and query parameter probably helps it get filtered away under some common log filter regex/rules.

It’s goal was to see how your server responded to that kind of request (relative path that escapes html root, probably) without standing out too obviously in your logs. Based on the response it provided, your server might have gotten bumped into a list for more targeted probing or exploitation.

Might test for some combo of letting you reach files you shouldn't be able to, and other dangerously-configured httpd rules (e.g. open redirects), in such a way that it lets the webserver take care of the whole request while still verifying you could access the file you want with a different request. Might help evade early detection by IDS or something, in very-specific cases, while still permitting probing of the filesystem.

Like, it might let you basically stat the file without reading its contents, if the webserver does things in the following order: 1) Verify that the file, after applying rewrite rules, exists and is readable; else, 404, 2) see the "redirect" query string, short-circuit request and serve a 304 (or what have you) without actually reading the file we already verified exists—never actually make any syscalls to read the file.

... if it's not that, yeah, no clue.

Basically my thoughts as well. Mainly I take a cyberpunk-esque view of things where the net is a big ecosystem with lots of weird environmental niches, and so it breeds software, people, and organizations to occupy these niches. Asking what this one request is supposed to mean is kind of beside the point, like asking what a particular log in a forest means.

Thank you! I've looked at a lot of PHP malware and a good portion of it is impossible to understand because it's hard to tell what the intent is. Bug or probe? Typo or clever coding trick? Cut-n-paste or testing only against SunOS 4.10 server?

Reply on news.ycombinator.com