Can't search for packages at work

[grepwood]

When connecting from workplace VPN, I get this error: It's a HTTP authentication dialog. This is not needed when I connect without my workplace VPN.

[ysndr]

It might be that your VPN filters the urlcoded authentication we use with the elasticsearch backend. Did you check for such options?

[grepwood]

No, I'm locked out of such settings, and it's ridiculous. This doesn't occur with many search sites like google.com, duckduckgo.com, github.com, www.debian.org/distrib/packages or packages.ubuntu.com, so I don't see how my VPN is at fault here. I'll double check when back at work. To me it looks like whatever triggers this, is finding its way into a login endpoint that isn't supposed to be publicly exposed in the first place :/

[robleach]

Confirming, this also happens to me, but only when on my work's VPN.

[ysndr]

Can you confirm with curl or postman that direct requests to bonsaisearch go through and that your VPN allows basic auth (which might be blocked for sec reasons)?

The credentials for users can be found in https://github.com/NixOS/nixos-search/blob/3b41f2dcfd3448efea38f241c5229ac4948e51a7/frontend/src/index.js#L9-L12:

https://nixos-search-5886075189.us-east-1.bonsaisearch.net:443
username: z3ZFJ6y2mR
password: ds8CEvALPf9pui7XG

auth: Basic

example with curl:

curl -u z3ZFJ6y2mR:ds8CEvALPf9pui7XG https://nixos-search-5886075189.us-east-1.bonsaisearch.net:443

>>

{
  "name" : "ip-172-31-78-165",
  "cluster_name" : "elasticsearch",
  "cluster_uuid" : "dmpZBRo5RhOj720OzdKAPw",
  "version" : {
    "number" : "7.2.0",
    "build_flavor" : "oss",
    "build_type" : "tar",
    "build_hash" : "508c38a",
    "build_date" : "2019-06-20T15:54:18.811730Z",
    "build_snapshot" : false,
    "lucene_version" : "8.0.0",
    "minimum_wire_compatibility_version" : "6.8.0",
    "minimum_index_compatibility_version" : "6.0.0-beta1"
  },
  "tagline" : "You Know, for Search"
}

[geofft]

I had this problem at my workplace, and the reason is that our outbound web proxy filters out auth headers by default to prevent people from accidentally leaking internal passwords to external websites, because basic auth is so rare. (FWIW, our web proxies are Blue Coat devices configured to do MITM with an internal SSL certificate, but I'm not sure if this is default Blue Coat behavior and it may also be default behavior for other DLP systems too.)

To rephrase the comment above because it's so surprising - the website legitimately uses basic auth to make XHR requests to the Elasticsearch backend, and the password is hard-coded in the https://search.nixos.org source. If you're getting an auth prompt, it's because you're successfully reaching the (correct) backend but the hard-coded auth header isn't making it there. I had to ask the web proxy / security team to allow outbound Authorization headers to bonsaisearch.net to get the site to work.

[grepwood]

Don't you think that exposing hardcoded credentials to a backend database is a little insecure in terms of website design? Or even exposing users to palpable elements of the backend.

[ncfavier]

I assume the exposed account has a very restricted scope (but then why does it need a password?). @garbas ?

[grepwood]

This is a pretty big security issue because since the database is exposed to the public, you can get its version and crossreference that against CVE lists. ggwp

[geofft]

I believe that what's going on is that they're using a hosted service from Bonsai (https://bonsai.io/) to avoid running a backend themselves, which means that

• probably Bonsai provides no unauthenticated option (but if there is, it would be good to use it!), but that doesn't mean that anything sensitive is behind the hard-coded password.
• the Bonsai company runs the Elasticsearch instance and makes it available to any user who signs up, so if there are any CVEs / if they aren't fully patched, that's already a problem for them, because the public can go sign up for a new Bonsai account. (And their entire business is running, managing, and upgrading Elasticsearch for you.)

So, yes, the design of the website is exposing internal details of the backend, and in a world where there is copious funding to run a website with all the best practices in the world, there would be some sort of nixos-search API that did nothing of value beyond relaying what's inside the Elasticsearch database and a team of people on call 24/7 to keep that API running. But I don't think there is any actual security issue with the current design.

[grepwood]

I don't think there is any actual security issue with the current design.

What about RCE against Bonsai?