back to article Apache Superset: A story of insecure default keys, thousands of vulnerable systems, few paying attention

Apache Superset until earlier this year shipped with an insecure default configuration that miscreants could exploit to login and take over the data visualization application, steal data, and execute malicious code. The open source application, based on Python's Flask framework, defaulted to a publicly known secret key: …

  1. David 132 Silver badge
    Facepalm

    Got there in the end.

    Honestly, I am reminded of the quote attributed to Churchill, speaking in his case of the Americans: "They will do the right thing in the end, but only after trying all the alternatives" (or words to that effect).

    I'm glad that the Apache security team finally forced users to change the default key. But how frustrating that they shilly-shallyed for so long over it. Yes, yes, "don't want to break existing installs" and all that, but I think this is one of those cases where such breakage is definitely the lesser of two evils.

    1. Doctor Syntax Silver badge

      Re: Got there in the end.

      "don't want to break existing installs"

      It's best to look on those installs as already broken and needing to be fixed.

  2. EarthDog

    Using what "random number" generator

    They all have weaknesses. Best to not use one shipped with any major SW package.

  3. runt row raggy

    log4j

    you would have thought that the log4j fiasco would have yielded a bit more introspection. but you can understand how apache could maybe have thought, well that wasn't us... oh. right.

  4. sitta_europea Silver badge

    "The best approach is to take the choice away from users and require them to take deliberate actions to be purposefully insecure..."

    er, obviously. If you've *ever* had to deal with any users.

  5. Pascal Monett Silver badge

    "this episode illustrates that users do not read documentation and don't read logs"

    Which is a basic truth anyone who ever had to write a user manual has known for ages.

    What this "episode" really illustrates is that, when making a product that uses an encryption key, make sure that right at the beginning the product does not start when using the default key and make an error message that makes it clear that it won't start until said default key has been changed.

    1. Sceptic Tank Silver badge
      Facepalm

      Re: "this episode illustrates that users do not read documentation and don't read logs"

      There's a way to flood the help desk's phone lines.... "My app won't start. What's going on?"

      1. Anonymous Coward
        Anonymous Coward

        Re: "this episode illustrates that users do not read documentation and don't read logs"

        Better this than law enforcement calling because you were used as a jump site to a much more profitable target.

    2. Roland6 Silver badge

      Re: "this episode illustrates that users do not read documentation and don't read logs"

      Need to remember the "users" being referred to here are people like you and me who set up software, not end users...

  6. Robert Carnegie Silver badge

    Or. let the app start, but then it stops after five minutes, logging the reason in detail?

  7. iron

    > "The best approach is to take the choice away from users and require them to take deliberate actions to be purposefully insecure," he said.

    No you're wrong there, the best approach is to use secure defaults. That way the idiots can't set it up insecurely in the first place.

    1. matjaggard

      What's the difference between "secure defaults" and "requiring them to take deliberate actions to be purposefully insecure" they sound completely identical to me.

      1. OhForF' Silver badge

        "requiring them to take deliberate actions to be purposefully insecure": what they did, refuse to run when the default key is not changed

        "secure defaults": create a random key when the default key is detected on startup and document where the lazy admin that didn't set his own key can find the secret if he needs it client isde

        Not identical but both fixing the problem of a known default key being used in way too many installations.

        1. Claptrap314 Silver badge

          Great. If you are Chef or Jenkins (I think), that means that your "secret" is now in the log file.

          Seriously, just refuse to start.

  8. Spamfast
    FAIL

    How difficult is it for the installer to generate a random key on installation? How many networking kit breaches are caused by hard coded backdoor telnet (!) or ssh logins? The company officers need to personally liable for this nonsense.

    1. matjaggard

      Very difficult. If you do that then every instance that starts without some shared state will be incompatible with every other one. Restarted an instance in kubernetes? All your users are now blocked. Got two instances running? Users moving from one to the other can't have access.

    2. Claptrap314 Silver badge

      There are at least two problems. The first is that this secret has to be stashed somewhere. That somewhere has to be documented. That document has to be public.

      But if you DO go this way, please, PLEASE DO NOT PUT YOUR **** MASTER KEY IN THE LOG FILE!

      Or do--the actual level of security is roughly the same.

      The second problem is one of coordination. The reply mentioned K8s, which is a bad example, because if you ARE using containers, then you provide the shared secret when the container comes up. In a heterogeneous environment NOT managed centrally, however, this is a big problem.

      (Not as big as the problem of defaulting your firewall to allow all, mind you...)

  9. Anonymous Coward
    Anonymous Coward

    Unbelievable naivety

    I cannot believe that the Apache developers were this naive. Shame on them. It took many tries to get them to stop the app starting/working with a bad key.

    Of course the people not changing the key are also likely not going to update. I'd wager a high proportion are "DevOps" container-gluers.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like