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

71–80 of 165 posts

Re: Hunting for Nginx alias traversals in the wild

#71

Post by m00x »

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.

Re: Hunting for Nginx alias traversals in the wild

#72

Post by licebmi__at__ »

wredue wrote: post #26
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)

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`

Re: Hunting for Nginx alias traversals in the wild

#73

Post by martinflack »

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.

But the issue is -- would it break the things a web server is doing? It doesn't have to be a universal solution.

Re: Hunting for Nginx alias traversals in the wild

#74

Post by autoexec »

Someone1234 wrote: post #40
whiskeymikey wrote: post #18

This is probably a dumb question but why would Bitwarden allow unauthenticated requests to /attachments at all? Even with the Nginx bug, wouldn’t the request have failed if that URL required authentication?

This is an exploit against the web server's configuration, so never executes Bitwarden's authentication code or any Bitwarden code at all. It isn't unusual or incorrect for projects to use their own authentication rather than Nginx or a module. It is still Bitwarden's responsibility since they shipped a dangerous configuration via Docker. Which they seemingly acknowledge and have since fixed.

> It is still Bitwarden's responsibility since they shipped a dangerous configuration via Docker. Which they seemingly acknowledge and have since fixed.

The screenshot makes it look like the docker setup option was still in beta and the page had warnings all over it saying there could be possible issues. I can't really judge Bitwarden too harshly here for releasing something in beta that was later found to have a vulnerability in it.

Re: Hunting for Nginx alias traversals in the wild

#75

Post by autoexec »

ComputerGuru wrote: post #45
phendrenad2 wrote: post #35

This has nothing to do with bitwarden. This is a generic directory traversal attack (enabled by Nginx's configuration language being full of serious gotchas).

It does have to do with BitWarden: they wrote and shipped the buggy config.

It looks like they did say it was still beta and warned there could be issues though. I'll give them credit for that much.

Re: Hunting for Nginx alias traversals in the wild

#76

Post by donutshop »

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 thought so too. But then did a quick search on Shodan and found these:

https://www.shodan.io/search?query=bitwarden

https://www.shodan.io/search?query=vaultwarden

Re: Hunting for Nginx alias traversals in the wild

#78

Post by seanw444 »

m3affan wrote: post #68
D13Fd wrote: post #51

Earlier quoted context omitted.

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

What are the alternarives though?

To Nginx? HAProxy. Or Caddy if you're just doing web stuff.

Re: Hunting for Nginx alias traversals in the wild

#79

Post by NoMoreNicksLeft »

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?

I don't know about everyone else, but at this point I'm no longer doing a proper installation of nginx for personal stuff. I always just spin up a docker image... and I'm not checking if it runs as root or not, really.

Probably really screwing things up. Ouch.

Re: Hunting for Nginx alias traversals in the wild

#80

Post by frays »

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?

You are correct.

Unfortunately, nginx (and other web servers) generally need to run as root in normal web applications because they are listening on port 80 or 443. Ports below 1024 can be opened only by root.

A more detailed explanation can be found here: https://unix.stackexchange.com/questions/134301/why-does-ngi...

Post reply on HN