Web Server Log Entry Question

Comments

• bulbasaur Member

  June 2022

  Someone trying to probe for a vulnerability. Logging the full set of headers and any potential bodies would be interesting and might shed some more light into what's that they're trying to probe for, sadly I no longer run my honeypots to be able to provide more information.

  Thanked by 2Not_Oles Tony40
• Nekki Veteran

  June 2022

  The Saudi government are after you.

  Thanked by 2Alireza Erisa
• Peppery9 Member

  June 2022

  The Saudis are installing Pegasus security software on your server free of charge, no need to be alarmed.

  Thanked by 1varwww
• Boogeyman Member

  June 2022

  Data exfiltration through log if your server is compromised. I will encrypt the data and divide it into many small pieces as request parameter and then send http requests to a compromised server I have access to then from log I will retrieve that data. There are other interesting ways to exfiltrate data through DNS, p2p, etc protocols.

  Otherwise just trying to DOS/find interesting things/etc.

  Thanked by 2ralf Not_Oles
• Not_Oles Member, Patron Provider

  June 2022

  The log snippet was from a server running Debian 11.3.

  # apache2 -v
  Server version: Apache/2.4.53 (Debian)
  Server built:   2022-03-14T16:28:35
  # 
  

  Not sure how it relates to the logged attacks, but it looks like there were some recent CVEs for Apache and that Debian 11.3's Apache version might be behind. Here's from the Slackware64-current changelog:

  Wed Jun 8 19:15:34 UTC 2022

  [ . . . ]

  n/httpd-2.4.54-x86_64-1.txz: Upgraded.
  This update fixes bugs and the following security issues:
  mod_proxy X-Forwarded-For dropped by hop-by-hop mechanism.
  Information Disclosure in mod_lua with websockets.
  mod_sed denial of service.
  Denial of service in mod_lua r:parsebody.
  Read beyond bounds in ap_strcmp_match().
  Read beyond bounds via ap_rwrite().
  Read beyond bounds in mod_isapi.
  mod_proxy_ajp: Possible request smuggling.
  For more information, see:
  https://downloads.apache.org/httpd/CHANGES_2.4.54
  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-31813
  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-30556
  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-30522
  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29404
  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-28615
  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-28614
  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-28330
  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-26377
  (* Security fix *)
• joyr Member

  June 2022

  by the frequency, it looks like a DDoS attempt.

  Thanked by 1Not_Oles
• TimboJones Member

  June 2022

  @joyr said:
  by the frequency, it looks like a DDoS attempt.

  4 in 2 seconds by two hosts doesn't usually trigger "DDoS attempt". It looks like it's trying to find writable areas, perhaps temp dirs from getting Lets Encrypt certificates or something.

  Thanked by 1Not_Oles
• mgcAna Member, Host Rep

  June 2022

  Such attempts are generally observed on domains those were once compromised and then later cleaned. They are still trying to look for old files. Now 2 things may happen :
  1. They will try for a while and then leave you alone
  2. If still have that vulnerability which allowed to leave payload first time, it will be noticed and will then try to again compromise the system.

  Thanked by 1Not_Oles
• johnnyquestion Member

  June 2022 edited June 2022

  dump the post requests into a file
  here is php
  $request = file_get_contents('php://input');
  file_put_contents('request.txt', $request,FILE_APPEND);

  Thanked by 1Not_Oles