Problem with nginx authentication guide?

[rugk]

I randomly looked at https://github.com/PrivateBin/PrivateBin/wiki/Restrict-upload-using-NGINX and is not there a problem?

Problem

The limit_except is in the / block. As such, the password authentication is only required for that access case.
The \.php$ block itself below is still unprotected.

Idea

As such, POST requests to / should be catched by the authentication, that works, but if I directly send a POST to /index.php from the outside, won't this circumvent the nginx authentication?

Or did I understand the nginx config wrong here?

Question

@ViRb3 @dlangille edited the page, maybe you have a test instance with that config or can confirm/deny this?

[dlangille]

I don't know the answer.

My instance is at https://bin.langille.org and uses the code in question. Please feel free to test your theory there. :)

[rugk]

Here you go: https://bin.langille.org/index.php?6b303e2d3c1b1892#DhseA3n5Mg7usWAzXXZnT6x4V8cWKWqHx8x8hkWJqaEt or https://bin.langille.org/?6b303e2d3c1b1892#DhseA3n5Mg7usWAzXXZnT6x4V8cWKWqHx8x8hkWJqaEt (viewing is not protected after all, so makes no difference.)

It's exactly as described (easily testable with browser dev tools.)

Note for reproducers: You need to add a breakpoint here to get the encryption key on failure and encode it (CryptTool.base58encode(symmetricKey); as the original code does it) and copy it:

PrivateBin/js/privatebin.js

Line 4555 in e84a869

if (failureFunc !== null) {

[rugk]

As I don't know how to fix that in a second, and such a new config would need testing, I just added a warning to that page. I am also unsure how we'd further proceed, – after all I am not sure who possibly used that guide in our wiki.

I am escalating that internally somewhat, because I see that it was kinda official part of the wiki and must not stand there as it does now.

[dlangille]

I am also unsure how we'd further proceed, – after all I am not sure who possibly used that guide in our wiki.

What about adding it as a note to the next release? When that happens, social media takes over. I for one will help spread the news. When it's a security issue the news will spread fast. Care needs to be taken to emphasise that it is a configuration issue, not a PrivateBin issue.

Full disclosure: I work for an infosec company, but in sysadmin, not in analysis.

[ViRb3]

The current wiki page is very different from what I submitted initially. Here is a link to my verison: https://github.com/PrivateBin/PrivateBin/wiki/Restrict-upload-using-NGINX/5c904dd8e5ee29882c8f735ea7aca96287866a99

In my case, there is one catch-all case, which is cookie-protected, and the auth endpoint, which is password-protected. As far as I can see, there is no problem in that.

However, you are right that in the current edit, all files ending in .php are not protected at all. This is definitely bad and should be fixed.

My personal config at the moment looks like this:

server {
    server_name foo.bar;

    location / {
        if ($request_method = GET) {
            error_page 418 = @noauth;
            return 418;
        }
        proxy_pass http://privatebin:8080;
    }

    location @noauth {
        internal;
        auth_request off;
        proxy_pass http://privatebin:8080;
    }

    listen 443 ssl http2;
    # set up an auth provider here
    auth_request /auth;
}

[rugk]

From my first glance, I agree, your solution should not have this flaw. It would likely also be useful to re-document your solution as an alternative example, too.

[ViRb3]

Not trying to throw blame, but given the profile of the project, you should probably lock wiki edits to contributors only, or at least have maintainers verify edits before publishing. This issue went unnoticed since 2019 and there's no way to know who might have used it.

[rugk]

We'll discuss that internally certainly. What I can say, however, already, is that “verify edits before publishing” is AFAIK technically not possible in GitHub. Either a wiki is editable by all or by none (only contributors can edit it).

[ViRb3]

Yeah, you'd need to extract the wiki to regular files in a git repo, perhaps GitHub pages, and then non-maintainers can submit PRs.

[dlangille]

I don't know how to convert the proxy_pass examples to my use case which is not using a proxy.

[dlangille]

I duplicated the limit_except to the location ~ \.php$ - does that mitigate it?

[rugk]

In my testing, it does. I now cannot POST it to index.php anymore/it requires authentication.

[elrido]

Thanks for testing, I've updated the snippet in the wiki accordingly.

[dlangille]

Thank you. I'm sorry for this.

[rugk]

No need to be sorry, mistakes happen. The good thing is it has been noticed, and we are currently evaluating how to react now and especially further improve it all here to prevent errors like this from happening (like having a second pair of eyes looking upon the wiki or so), but that is to be decided later.