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

41–50 of 165 posts

Re: Hunting for Nginx alias traversals in the wild

#41

Post by whiskeymikey »

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.

Ahh okay. That explanation makes sense. Thanks!

Re: Hunting for Nginx alias traversals in the wild

#42

Post by jerf »

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 craftsman blames his tools... instead of fixing them.

How so many programmers read that as license to use crap tools boggles me.

Re: Hunting for Nginx alias traversals in the wild

#43

Post by princevegeta89 »

francislavoie wrote: post #11
kibwen wrote: 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.

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.

+1 to Caddy. Just tried it recently and I was very happy to forget all the nginx jargon the next moment.

Re: Hunting for Nginx alias traversals in the wild

#44

Post by technion »

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.

Re: Hunting for Nginx alias traversals in the wild

#45

Post by ComputerGuru »

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.

Re: Hunting for Nginx alias traversals in the wild

#46

Post by housemusicfan »

phendrenad2 wrote: post #36
housemusicfan wrote: post #25

Earlier quoted context omitted.

[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?

Shall we make straight razors illegal too while we're at it?

Let's not reduce everything to the least common denominator lest we end up like (formerly) Oregon where you couldn't pump your own gas because it was "dangerous" for the lay person.

Re: Hunting for Nginx alias traversals in the wild

#47

Post by loeg »

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.

https://man7.org/linux/man-pages/man2/openat2.2.html RESOLVE_BENEATH

(FreeBSD has this in ordinary openat(2) as O_RESOLVE_BENEATH.)

Re: Hunting for Nginx alias traversals in the wild

#48

Post by amluto »

phendrenad2 wrote: post #38
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.

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 IMO rather embarrassing bug and should he fixed.

Re: Hunting for Nginx alias traversals in the wild

#49

Post by NoZebra120vClip »

emaciatedslug wrote: post #34
SV_BubbleTime wrote: post #22

Earlier quoted context omitted.

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/

All the replies have given random statistics, but these don't shed much light on the length of time it may take an attacker to brute-force a password, or find a chink in the armor of the vault's encryption algorithm.

Now as I said, a significant threat actor with lots of time in their future plans can collect encrypted stuff such as vaults and bide their time. Someday, the decryption may be cost-effectively cheap. Someday, a flaw may be uncovered in the cryptography. Someday, a vault owner's secret key(s) may leak and can be correlated.

As I said, it's just a question of time, and the ability to hold on to your cards for long enough that they can be played in the proper manner. It may take 5 years, 10 or 20, but if the payoff is valuable enough, it's worth the wait for the threat actor.

Re: Hunting for Nginx alias traversals in the wild

#50

Post by Frondo »

housemusicfan wrote: post #46
phendrenad2 wrote: post #36

Earlier quoted context omitted.

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?

Shall we make straight razors illegal too while we're at it? Let's not reduce everything to the least common denominator lest we end up like (formerly) Oregon where you couldn't pump your own gas because it was "dangerous" for the lay person.

I don't think you'd find a single woodworker anywhere who, if they could afford it, wouldn't prefer a table saw with Sawstop. How much are your fingers worth to you?
Post reply on HN