<div dir="ltr"><div dir="ltr"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 18, 2020 at 5:04 PM lists <<a href="mailto:lists@lazygranch.com">lists@lazygranch.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In theory not a problem, but look at the text on this page about placing root in location blocks. <br>
<a href="https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/" rel="noreferrer" target="_blank">https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/</a><br>
<br>
I saw your first post and thought it was entertaining. Somebody needs to annoy those hackers. Since I don't use php I trap those requests in a map and return a 444. That way I can use some scripts and pull the hacker IPs out of the log file. If they come from a server, the IP space of that host gets blocked. There are no eyeballs at servers. But I do like the idea of feeding the hacker something unpleasant. <br>
<br></blockquote><div><br></div><div>If you have enough resources you can send them a 200 OK response with 10MB html file with an enormous DOM tree using chunked transfer and no content-length header. They will lost huge amount of resources to download and parse this (probably multiple times).<br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 18, 2020 at 5:04 PM lists <<a href="mailto:lists@lazygranch.com">lists@lazygranch.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In theory not a problem, but look at the text on this page about placing root in location blocks. <br>
<a href="https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/" rel="noreferrer" target="_blank">https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/</a><br>
<br>
I saw your first post and thought it was entertaining. Somebody needs to annoy those hackers. Since I don't use php I trap those requests in a map and return a 444. That way I can use some scripts and pull the hacker IPs out of the log file. If they come from a server, the IP space of that host gets blocked. There are no eyeballs at servers. But I do like the idea of feeding the hacker something unpleasant. <br>
<br>
<br>
<br>
<br>
<br>
Original Message <br>
<br>
<br>
From: <a href="mailto:pizwer88@wp.pl" target="_blank">pizwer88@wp.pl</a><br>
Sent: June 18, 2020 4:08 AM<br>
To: <a href="mailto:nginx@nginx.org" target="_blank">nginx@nginx.org</a><br>
Reply-to: <a href="mailto:nginx@nginx.org" target="_blank">nginx@nginx.org</a><br>
Subject: Nginx potentially leaking real filenames? (hopefully properly formatted)<br>
<br>
<br>
Hi,<br>
<br>
I am experimenting with various ways of annoying bots and automated<br>
vulnerability scanners that reach my service. In one instance I am<br>
serving a recursive decompression bomb for all requests for .php files.<br>
Since none of my services run PHP, and never have, all such traffic can<br>
be safely assumed malicious.<br>
Recently (a couple of months since first deployment) I started seeing<br>
repeated requests to the server trying to fetch the recursive<br>
decompression bomb by its real file name, which should have never been<br>
exposed anywhere.<br>
<br>
Is it possible for nginx to leak the real file name? Through<br>
misconfiguration or other means?<br>
<br>
I am using nginx (version 1.14.2-2+deb10u1) as a reverse proxy and for<br>
SSL termination.<br>
The custom application behind it is not aware of the existence of the<br>
decompression bomb and lives in its own completely separate directory<br>
tree. It never reads nor serves any files from the local server, all its<br>
data is in physically separate database and cache servers. While I<br>
cannot prove absence of vulnerabilities in this custom app, I have not<br>
found any evidence of it being used to (nor leaking) local directory<br>
contents.<br>
The decompression bomb does not contain its file name in its contents.<br>
<br>
Given the above, I believe something in my nginx setup leaked the real<br>
file name of the decompression bomb.<br>
I've tried using all request methods (GET, HEAD, PUT, POST, DELETE,<br>
CONNECT, OPTIONS, TRACE, PATCH) on the server from curl like following:<br>
$ curl --verbose -X <method> <redacted>.com/index.php<br>
and (as expected) none of the responses leaked the file name in any of<br>
the headers nor contents.<br>
<br>
Below is a redacted and inlined version of my nginx configuration. There<br>
is only one server defined, the Debian default server config has been<br>
removed. The error code mapping is there to avoid triggering high error<br>
rate alerts when hit by hundreds of consecutive bot requests.<br>
I would appreciate any help in figuring out what I am doing wrong and<br>
how could the <redacted-payload-filename> have been leaked?<br>
<br>
Thanks,<br>
Pizab<br>
<br>
# nginx.conf<br>
http {<br>
sendfile on;<br>
tcp_nopush on;<br>
tcp_nodelay on;<br>
keepalive_timeout 165;<br>
types_hash_max_size 2048;<br>
<br>
include /etc/nginx/mime.types;<br>
default_type application/octet-stream;<br>
<br>
limit_req_zone "php" zone=attackzone:10m rate=1r/s;<br>
<br>
ssl_certificate <redacted>;<br>
ssl_certificate_key <redacted>;<br>
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;<br>
ssl_session_cache shared:SSL:10m;<br>
ssl_session_timeout 10m;<br>
<br>
server_tokens off;<br>
<br>
access_log /var/log/nginx/access.log;<br>
error_log /var/log/nginx/error.log;<br>
<br>
client_body_buffer_size 1M;<br>
<br>
server {<br>
listen 443 default_server ssl;<br>
listen 80;<br>
<br>
server_name <redacted>.com;<br>
rewrite_log on;<br>
<br>
location /.well-known/acme-challenge {<br>
alias /var/www/html/.well-known/acme-challenge;<br>
}<br>
<br>
location / {<br>
access_log /<redacted>/logs/nginx_access.log;<br>
proxy_set_header Host $http_host;<br>
proxy_redirect off;<br>
proxy_connect_timeout 60;<br>
proxy_read_timeout 160;<br>
proxy_pass <a href="http://localhost:10000" rel="noreferrer" target="_blank">http://localhost:10000</a>;<br>
}<br>
<br>
error_page 429 =229 /error429;<br>
<br>
location ~ \.php$ {<br>
limit_rate_after 1k;<br>
limit_rate 2k;<br>
limit_req zone=attackzone burst=2;<br>
limit_req_status 429;<br>
keepalive_timeout 0;<br>
root /var/www/html/<redacted>/;<br>
default_type "application/xml";<br>
add_header Content-Encoding "br";<br>
try_files /<redacted-payload-filename> =400;<br>
}<br>
<br>
location = /error429 {<br>
return 229 "Too many requests.";<br>
}<br>
}<br>
}<br>
_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org" target="_blank">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx</a><br>
_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org" target="_blank">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx</a></blockquote></div>