0

I'm maintaining an Apache / PHP-FPM setup with multiple vhost configurations and one of these vhosts has been illegally pentested by someone. It's running a rather outdated Laravel CMS using a custom 404 page.

Examining the Apache log, I noticed that several thousand requests to non-existent URLs were answered by Apache with the status code 200 while the CMS log shows the correct 404 code. My problem is that I am not able to reproduce this behavior no matter what I try or what pentesting tool I use.

I'm quite sure that the attacker actually got the intended 404 page.

Here is one log entry of the attacker:

"GET /tNeKvYla/blog/post/some-post HTTP/1.1" 200 9443

Here is the log entry when I do the same request:

"GET /tNeKvYla/blog/post/some-post HTTP/1.1" 404 27639

Note the different response sizes at the end. I had to figure out that Apache doesn't compress 404 responses. So I converted the 404 page to a normal one to find out the number of bytes when compressed and yes, the response size is equal.

Regarding the 404 page, there is no special configuration involved and I have never encountered any misbehavior.

Can someone explain to me what is going on and why? Maybe someone is able to identify the pentesting tool that can be used to force such behavior? As a side question, what is the purpose of not compressing 404 responses?

2
  • I assume the pages at these URIs are dynamically generated (such as using .htaccess)? Perhaps the page it runs to service is page is looking at other aspects of the request (referrer, user agent, etc).
    – jpiddle888
    Commented May 15 at 2:15
  • My thought exactly. A thing that might be useful is to install Wireshark and see what's actually in those packets apart from the host header.
    – tsc_chazz
    Commented May 15 at 2:33

0

You must log in to answer this question.

Browse other questions tagged .