Hi, I am experimenting with various ways of annoying bots and automated
vulnerability scanners that reach my service. In one instance I am serving a
recursive decompression bomb for all requests for .php files. Since none of my
services run PHP, and never have, all such traffic can be safely assumed
malicious. Recently (a couple of months since first deployment) I started
seeing repeated requests to the server trying to fetch the recursive
decompression bomb by its real file name, which should have never been exposed
anywhere. Is it possible for nginx to leak the real file name? Through
misconfiguration or other means? I am using nginx (version 1.14.2-2+deb10u1)
as a reverse proxy and for SSL termination. The custom application behind it
is not aware of the existence of the decompression bomb and lives in its own
completely separate directory tree. It never reads nor serves any files from
the local server, all its data is in physically separate database and cache
servers. While I cannot prove absence of vulnerabilities in this custom app, I
have not found any evidence of it being used to (nor leaking) local directory
contents. The decompression bomb does not contain its file name in its
contents. The decompression bomb file <redacted-payload-filename> exists
and is properly served in response to .php file requests. Given the above, I
believe something in my nginx setup leaked the real file name of the
decompression bomb. I've tried using all request methods (GET, HEAD, PUT,
POST, DELETE, CONNECT, OPTIONS, TRACE, PATCH) on the server from curl like
following: $ curl --verbose -X <method>
<redacted>.com/index.php and (as expected) none of the responses leaked
the file name in any of the headers nor contents. Below is a redacted and
inlined version of my nginx configuration. There is only one server defined,
the Debian default server config has been removed. The error code mapping is
there to avoid triggering high error rate alerts when hit by hundreds of
consecutive bot requests. I would appreciate any help in figuring out what I
am doing wrong and how could the <redacted-payload-filename> have been
leaked? Thanks, Pizab # nginx.conf http { sendfile on;
tcp_nopush on; tcp_nodelay on; keepalive_timeout 165;
types_hash_max_size 2048; include /etc/nginx/mime.types;
default_type application/octet-stream; limit_req_zone "php"
zone=attackzone:10m rate=1r/s; ssl_certificate <redacted>;
ssl_certificate_key <redacted>; ssl_protocols TLSv1 TLSv1.1 TLSv1.2
TLSv1.3; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m;
server_tokens off; access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log; client_body_buffer_size 1M;
server { listen 443 default_server ssl; listen 80;
server_name <redacted>.com; rewrite_log on;
location /.well-known/acme-challenge { alias
/var/www/html/.well-known/acme } location / {
access_log /<redacted>/logs/nginx_access. proxy_set_header
Host $http_host; proxy_redirect off;
proxy_connect_timeout 60; proxy_read_timeout 160;
proxy_pass localhost:10000 localhost:10000 ; } error_page
429 =229 /error429; location ~ \.php$ { limit_rate_after
1k; limit_rate 2k; limit_req zone=attackzone burst=2;
limit_req_status 429; keepalive_timeout 0;
root /var/www/html/<redacted>/; default_type
"application/xml"; add_header Content-Encoding
"br"; try_files /<redacted-payload-filename> =400;
} location = /error429 { return 229 "Too many
requests."; } } }
_______________________________________________
nginx mailing list
[email protected]
http://mailman.nginx.org/mailman/listinfo/nginx
