Live data from Hacker News

Hunting for Nginx alias traversals in the wild

labs.hakaioffsec.com

81–90 of 165 posts

Re: Hunting for Nginx alias traversals in the wild

#81
post #23

If I understand correctly, this is a vulnerability in self-hosted Bitwarden only. Is that correct?

Yes, per the article: "Bitwarden also offers a self-hosted option for those who want to maintain their own server, which is the one we are going to examine."

Re: Hunting for Nginx alias traversals in the wild

#82
post #80
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...

Nginx is started as root but it does not run as root, it changes its user after opening log files and sockets. (unless you use a lazy docker container and just run everything as root inside it).

Re: Hunting for Nginx alias traversals in the wild

#83
post #80
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...

Nginx workers shouldn’t run as root and certainly don’t on any distro I know. Typically you have a www-data user/group or equivalent. Dropping privilege is very basic.

Re: Hunting for Nginx alias traversals in the wild

#84
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?

Typical umask is 022 so most things are readable by nginx workers but not writable, they don’t need to be explicitly assigned (e.g. to www-data). If your application generates sensitive data of course you should probably use a 077 umask.

Re: Hunting for Nginx alias traversals in the wild

#85
post #82
post #80

Earlier quoted context omitted.

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

Nginx is started as root but it does not run as root, it changes its user after opening log files and sockets. (unless you use a lazy docker container and just run everything as root inside it).

Even in (the official) docker image, a nginx user is created: (latest, layer 6)

/bin/sh -c set -x && groupadd --system --gid 101 nginx && useradd --system --gid nginx --no-create-home --home /nonexistent --comment "nginx user" --shell /bin/false --uid 101 nginx .....

[1] https://hub.docker.com/layers/library/nginx/latest/images/sh...

Re: Hunting for Nginx alias traversals in the wild

#86
post #5
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.

not compared to the $500 Google gave them

Not sure why your comment is last in the page. Google have significantly more resources and the authors looked to disagree with the amount awarded for the google vulnerability.

Re: Hunting for Nginx alias traversals in the wild

#88
post #13

Earlier quoted context omitted.

Small companies can't just give out $50k bounties, even if it would be deserved.

They raised 100 million $ last year https://siliconangle.com/2022/09/06/bitwarden-reels-100m-ope...

Huh. First time hearing about this. No longer a small company then.

Re: Hunting for Nginx alias traversals in the wild

#89
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 am not. Working well so far. My instance is behind Caddy, behind a secret URL path. To talk to the instance, this “pre-shares secret” needs to be known first. So far I haven’t seen any abnormal hits. I’m closing in on 3 years of using it in this setup, via Vaultwarden.

I’m aware that this is security through obscurity. The instance’s accounts use strong passwords and MFA.

Re: Hunting for Nginx alias traversals in the wild

#90
post #80
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...

> Ports below 1024 can be opened only by root.

Or processes running with the CAP_NET_BIND_SERVICE capability! [1]

Capabilities are a Linux kernel feature. Granting CAP_NET_BIND_SERVICE to nginx means you do not need to start it with full root privileges. This capability gives it the ability to open ports below 1024

Using systemd, you can use this feature like this:

    [Service]
    ExecStart=/usr/bin/nginx -c /etc/my_nginx.conf
    AmbientCapabilities=CAP_NET_BIND_SERVICE
    CapabilityBoundingSet=CAP_NET_BIND_SERVICE
    User=nginx
    Group=nginx
(You probably also want to enable a ton of other sandboxing options, see `systemd-analyze security` for tips)

[1]: https://man7.org/linux/man-pages/man7/capabilities.7.html

Post reply on HN