Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hunting for Nginx alias traversals in the wild

labs.hakaioffsec.com

Post reply on HN
Print view View original

101–110 of 165 posts

Re: Hunting for Nginx alias traversals in the wild

#101

Post by PhilipRoman »

jand wrote: post #77

Please excuse the silly question: Would proper directory and file ownerships not prevent this traversal? If nginx does not run as root, how can it read other files than the ones explicitly assigned to the nginx user?

Ah the wonders of 022 umask. Personally I would always recommend making files unreadable to other users. If not for all files then at least significant directories like everything under /home, etc.

It may require more fiddling with group memberships, but it's well worth it.

Re: Hunting for Nginx alias traversals in the wild

#102

Post by GlitchMr »

evgpbfhnr wrote: post #21

FWIW gixy (nginx configuration checker) catches this: https://github.com/yandex/gixy/blob/master/docs/en/plugins/a... (and nixos automatically runs gixy on a configuration generated through it, so the system refuses to build <3)

NixOS doesn't run Gixy anymore, see https://github.com/NixOS/nixpkgs/pull/209075.

Re: Hunting for Nginx alias traversals in the wild

#103

Post by starttoaster »

housemusicfan wrote: post #25
amluto wrote: 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]

A poor carpenter blames his tools because it is the carpenter who maintains them. Unless you’re contributing back to upstream nginx’s code, the analogy isn’t apt. A carpenter could and should simply choose the best tool for the job, and when they determine what that tool is, maintain it as well as can be.

Re: Hunting for Nginx alias traversals in the wild

#104

Post by archi42 »

m00x wrote: post #71
technion wrote: post #44

OK hear me out: a Linux capability like option that removes the .. option from the kernels file name parser. Like web apps have been seen various bypasses involving somehow smuggling two dots somewhere since we were on dial up modems. It's time to look for a way to close this once and for all, as the Linux kernel has done with several other classes of user land bugs.

That would break so many things that it would be insane to do. You could just run nginx as a separate user with very limited rights, or just run it on Docker. This, plus updating regularly usually fixes 90% of security issues.

Most (I hope all) distributions already run nginx as a separate user. It's best practice.

But that won't help if you alias to "/foo/bar/www" and the the application has a SQLite database at "/foo/bar/db.db", which the nginx user has to have access to. Same if you run it in a container (or lock down permissions using systemd).

Re: Hunting for Nginx alias traversals in the wild

#105

Post by SuperSandro2000 »

GlitchMr wrote: post #102
evgpbfhnr wrote: post #21

FWIW gixy (nginx configuration checker) catches this: https://github.com/yandex/gixy/blob/master/docs/en/plugins/a... (and nixos automatically runs gixy on a configuration generated through it, so the system refuses to build <3)

NixOS doesn't run Gixy anymore, see https://github.com/NixOS/nixpkgs/pull/209075 .

NixOS core maintainer here. That's about nginx' own test. Gixy is still run when writing any nginx config file with the writer helper function https://github.com/NixOS/nixpkgs/blob/b6cc06826812247fe54655...

Re: Hunting for Nginx alias traversals in the wild

#106

Post by SuperSandro2000 »

licebmi__at__ wrote: post #72
wredue wrote: post #26

Earlier quoted context omitted.

I just gave nix a go and so far it seems great. But do you know, if they’re a nicer options finder? The one I found where you just search all several thousand options kinda sucks. I want to just see my package (say, ssh) and just the ssh options, but the results get littered with irrelevancy.

I would suggest using man and searching like any piece of documentation. Specifically you are looking for `man configuration.nix`

That's actually worse search experience and slower because less is struggling with the amount of lines.

Re: Hunting for Nginx alias traversals in the wild

#107

Post by berkes »

Bluecobra wrote: post #52
rcxdude wrote: post #37

Earlier quoted context omitted.

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)

I'm afraid not. I've seen some really dumb setups of BW when helping selfhosted.

I do think that while selfhosting is admirable, in the case of your password vault, it's not. It's one thing where I'd always advice against selfhosting or DIY, because the downside risk is just too big.

The chance of fng up may be tiny, bit if you fck up, it's bad. Potentially bankruptcy or jail bad.

Re: Hunting for Nginx alias traversals in the wild

#108

Post by magicalhippo »

lyu07282 wrote: post #15
542458 wrote: 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…

That has been a known issue in nginx for a very long time and its a common attack vector at CTFs: https://book.hacktricks.xyz/network-services-pentesting/pent...

There is a LFI vulnerability because:

    /imgs../flag.txt
Transforms to:

    /path/images/../flag.txt
I've only implemented a handful of HTTP servers for fun, but I've always resolved relative paths and constrained them. So I'd turn "/path/images/../flag.txt" into "/path/flag.txt", which would not start with the root "/path/images/" and hence denied without further checks.

Am I wrong, or, why doesn't nginx do this?

Re: Hunting for Nginx alias traversals in the wild

#110

Post by junon »

technion wrote: post #44

OK hear me out: a Linux capability like option that removes the .. option from the kernels file name parser. Like web apps have been seen various bypasses involving somehow smuggling two dots somewhere since we were on dial up modems. It's time to look for a way to close this once and for all, as the Linux kernel has done with several other classes of user land bugs.

That makes no difference. Code often normalizes paths before they ever touch the filesystem API
Post reply on HN