Blog / Corporate / Security Report Chain: The vulnerability reports we receive

Security Report Chain: The vulnerability reports we receive

Security Report Chain

Earlier I wrote about the Security Report Chain (via security.txt), how one documents their policy on vulnerability reporting. You can see the the Agilicus’ security.txt here, as well as the policy. Well, people find them, and, they send you information in the hopes of gigantic bug bounties. Let’s talk about the reports.

The Security Report Chain breaks down into 2 categories so far. The first are exceptionally basic, no research, things like “your web site runs on non-tls”. Well, yes… but all it does is “301 redirect https://”, here we have an HSTS record. And, we are all-in on TLS, being on the preload list. So, uh, thanks for nothing.

Its the second type of Security Report Chain that intrigue me more. They have taken some time. I think they have some automated tools. And they often say things like:

I find you have https://auth.agilicus.com/.well-known/openid-configuration which links to https://auth.agilicus.com/keys which has a set of authentication keys. These should only be available to authenticated users, this is a critical vulnerability.
–some hopeful security researcher

So yes, this is true. And, it does take a bit of reading to understand what it is, and why its not only safe, but desirable. The standard is OpenID Connect, and, it has a discovery document (that first link). In turn, it has a means of discovering the current public keys, which are rotated hourly. Why do we do that? Well, the standard requires it. But what is the intent?

The first, the discovery document, this allows zero-configuration software to just work. A client can read this document, use the configuration, and proceed onwards with OpenID Connect. Nothing in the document is security sensitive (the alternative would have been to hard code it in the client). It simply says which URI to talk to to authenticate, how to obtain tokens, and, how to validate them. Does this belong in my Security Report Chain

The second, the keys (JWKS) are the public key. This allows a client which has received a token from the authentication process to independently verify it. It does not allow you to sign a token, it is not the private key.

OK, so in this Security Report Chain the reporter has done some scan, has found something of interest. Without knowing the standard, they have assumed that encryption keys should not be available unauthenticated. So they have followed my policy, reported the “problem”. But, here’s where I’m not sure what to do. They are doing this solely because they want a bug bounty. I decline to pay such for things which are “as designed, not a bug”, on principle. Would I be better to pay $5 for their diligence? I sent them a response (there were more than a few on similar topics) pointing out individual reading they could do to learn about the standards involved.

Suggestions anyone?

2 thoughts on “Security Report Chain: The vulnerability reports we receive”

  1. Rename /keys to /publickeys the term “secret” to “public” and similar throughout.
    Btw I got a browser alert to your latest blog post “Hit me with your best shot” and your personal blog has a fatal wordpress error… that some cosmic irony or do SSD failures strike again?

    1. the home site auto-upgraded a bit of code that probably should not have 🙂

      obscurity security… the best kind, cuz it costs nearly nothing and passes some of the pentests some of the time!

Leave a Reply

Your email address will not be published.