Live data from Hacker News

Hunting for Nginx alias traversals in the wild

labs.hakaioffsec.com

31–40 of 165 posts

Re: Hunting for Nginx alias traversals in the wild

#31
post #26

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.

When I roughly know what I'm doing I use search.nixos.org; if you give it the full services.foo prefix it's usually relevant enough, e.g. for ssh you'd want "services.openssh", which you can find skimming through the results of just searching 'ssh' first:

https://search.nixos.org/options?channel=unstable&from=0&siz...

For anything I'm not 100% sure will be obvious I search through a local clone of the nixpkgs repo directly, but I'll be honest and say I just never took time to search for a better tool

Re: Hunting for Nginx alias traversals in the wild

#32

Earlier quoted context omitted.

Shameless plug: Caddy does a great job here. Automatic HTTPS, written in Go so memory safety bugs are not a concern, has a solid file_server module.

Isn't everything forced to https now

Browsers try to navigate you to HTTPS but no, http the protocol is still working as it always has. Both nginx and Apache will require configuration to serve HTTPS.

You might still use HTTP on an internal network in a DMZ or other trusted network.

Re: Hunting for Nginx alias traversals in the wild

#33
post #26

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.

My main usage of Nix is on non-NixOS machines, and I use Home Manager, and while it has a similar problem, just searching the options in the packages it provides configuration for is a smaller issue.

Not sure if this helps you at all or not, it really depends on your usage of Nix, but for managing user configuration I do recommend Home Manager.

Re: Hunting for Nginx alias traversals in the wild

#34
post #14

Earlier quoted context omitted.

BW uses 100K rounds of PBKDF2 for the master password so I don't think that will be any time soon

BW now uses Argon2 over PBKDF. I can’t remember if that is by default, opt-in, or new accounts. But barring an argon vuln, this is even less of a concern. Also, I think BW has been using more than 100k for some time now. Last I saw 600K was the recommendation.

The default for new Bitwarden accounts from Feb 2023 on is PDBFK2 HMAC SHA 256 setting at 600,001 iterations on the client and 100,000 on the server with the option to use Argon2id. These settings are above current OWASP recommendations. https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor... https://bitwarden.com/help/kdf-algorithms/

Re: Hunting for Nginx alias traversals in the wild

#36
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]

Falso dichotomy. Tools can be "powerful" without being easy to misconfigure. To use a carpenter example, circular saws have guard shields that snap into place if the saw is free in the air. Seems like a good thing, no? Are saws meaningfully less "powerful" because of this security feature?

Re: Hunting for Nginx alias traversals in the wild

#37
post #2

Note that this leaks the vault with secrets encrypted - a leak of the cyphertext. > This vulnerability has been disclosed to Bitwarden and has since then been fixed. Bitwarden issued a US$6000 bounty, which is the highest bounty they issued on their HackerOne program. That's a ridiculously low payout.

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.

Re: Hunting for Nginx alias traversals in the wild

#38
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.

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.

Re: Hunting for Nginx alias traversals in the wild

#39

The article didn't mention permissions, would this still work if the nginx user is denied permissions on things like `/var/log`? I suspect it wouldn't but isn't the most common cause of security flaws going to be unchecked assumptions? As an aside, I didn't know Github code search accepted regex.

no it wouldn't work if the user nginx is running as didn't have read access to the directory or files

Re: Hunting for Nginx alias traversals in the wild

#40

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.

Post reply on HN