Live data from Hacker News

Hunting for Nginx alias traversals in the wild

labs.hakaioffsec.com

51–60 of 165 posts

Re: Hunting for Nginx alias traversals in the wild

#51
post #48

Earlier quoted context omitted.

It's done for speed. Straightforward text replacement is so much faster than checking to see if a path is properly terminated by a slash. And remember that Nginx became popular due to benchmarks that showed that it was more "web scale" than Apache2.

I find it hard to believe that searching for “..” would even show up in a benchmark. In any case, it seems that nginx does try to search for .. but has a bug in the corner case where the “location” doesn’t end with a slash. I assume there’s some kind of URL normalization pass that happens before the routing pass, and if the route matches part of a path component, nothing catches the .. If I’m right, this is just an I…

Yeah, this whole thing reads to me like a bug in nginx. There is no obvious reason users would need that functionality.

Re: Hunting for Nginx alias traversals in the wild

#52
post #37

Earlier quoted context omitted.

I don’t know enough about bounty programs to comment on the amount, but my understanding is that leaking encrypted secrets isn’t really dangerous?

a password vault contains a lot of long-lived secrets protected by a human-provided key, so it's really not something you want out there, even encrypted.

I would assume most people that are doing self-hosted are securing it behind a VPN like Wireguard instead of opening it to the whole web. (at least I hope so)

Re: Hunting for Nginx alias traversals in the wild

#53
post #9

If all you need is a simple way to serve static files that minimizes resource consumption and is reliably secure, what is the state of the art these days? In the past I would probably reach for Nginx, but I wonder if a more focused/less configurable tool would be preferable from a security standpoint.

how is a static site served from S3 considered in these parts of the interweb? i've never done this, but see it as an option, yet i never really hear others using it either.

Re: Hunting for Nginx alias traversals in the wild

#55
post #42

Earlier quoted context omitted.

[flagged]

A poor craftsman blames his tools... instead of fixing them . How so many programmers read that as license to use crap tools boggles me.

Yeah, after that phrase confusing me for years, I concluded that it really means a good craftsman won't even have bad (ie blame worthy) tools to begin with.

Re: Hunting for Nginx alias traversals in the wild

#56
post #16

How is this not seen as a vulnerability in nginx? This behavior is utterly absurd, seems to have no beneficial purpose, and straightforwardly exploitable.

[flagged]

There are quite a few such foot guns in nginx, it's part of why I've moved to using caddy.

Re: Hunting for Nginx alias traversals in the wild

#57
post #7

At risk of asking a dumb question, is there any good reason that you’d want nginx to allow traversing into “..” from a URL path? It just seems like problems waiting to happen. Edit: Actually, I’m a bit lost as to what’s happening in the original vuln. http://localhost/foo../secretfile.txt gets interpreted as /var/www/foo/../secretfile.txt or whatever… but why wouldn’t a server without the vulnerability interpret http…

> Why does “..” in paths only work sometimes?

That fully depends upon the file permissions. In this case, let's assume that a user has permissions to read files all the way from the web index directory (../index.html) back to the root directory (/). At that point, since they have permission to traverse down to the root directory, they now have permission to view any world viewable file that can be traversed to from the root directory, for instance /etc/passwd.

In other words, imagine a fork with three prongs, and your web server resides on the far right prong. Imagine that the part of the fork where the prongs meet (the "palm" of the fork) is the file system. If your web server residing on the far right prong of that fork allows file permission to files and directories that lead all the way to the palm of the fork, at that point you could continue accessing files on other prongs once you have reached the palm.

Re: Hunting for Nginx alias traversals in the wild

#58
post #9

If all you need is a simple way to serve static files that minimizes resource consumption and is reliably secure, what is the state of the art these days? In the past I would probably reach for Nginx, but I wonder if a more focused/less configurable tool would be preferable from a security standpoint.

werc, shttpd, etc.

Treat any web request like you would a real user on a Linux system you'd need to give access to to download files via scp. Chroot, strict permissions, etc. Can't escape what you can't escape. A ../ should return the same as expected in the shell, permission denied

Re: Hunting for Nginx alias traversals in the wild

#59
post #9

If all you need is a simple way to serve static files that minimizes resource consumption and is reliably secure, what is the state of the art these days? In the past I would probably reach for Nginx, but I wonder if a more focused/less configurable tool would be preferable from a security standpoint.

I have used Caddy for years, automatic SSL certificates, does file serving, does reverse proxy, very easy and clear to configure. Single-binary (Go) so easy to "install", single configfile.

Re: Hunting for Nginx alias traversals in the wild

#60
post #9

If all you need is a simple way to serve static files that minimizes resource consumption and is reliably secure, what is the state of the art these days? In the past I would probably reach for Nginx, but I wonder if a more focused/less configurable tool would be preferable from a security standpoint.

Merecat https://github.com/troglobit/merecat/

Last release 2016??
Post reply on HN