1. 44
  1.  

  2. 5

    The author frames this as a problem with WordPress (the article concludes with WordPress is still vulnerable with the latest version, 6.0. )

    However, I think that this is a problem with Certificate Transparency;

    A very common situation is that a user will first configure a web host with a certificate, often using automated tools like Certbot, and then start the installation of a web application like WordPress. The certificate will show up shortly after in one of the public Certificate Transparency logs; this process takes only a few minutes.

    That makes sense; if you don’t configure the web host with a certificate, you can’t connect to it. Of course you could use HTTP for the installation, but then you’d open a whole different can of security problems. Personally I set up hosts with a self-signed certificate first, and then opt for a publicly trusted certificate when I’m done, but I can see how this could be a bit too advanced for most hobbyists.

    Let’s Encrypt gives you free certificates, but if you use it, it will announce your hostname to the world. Hey, here is a new web server, maybe you can compromise it before the admin finishes setting it up. The solution would be to make Certificate Transparency more limited; it could require a token in DNS before you can query it. Putting the responsibility for this securty problem on WordPress is the world upside down.

    But in the meantime, the only way for an admin to be safe is to use wildcard certificates. But that requires DNS challenges which are harder to set up than HTTP challenges, so we will have to live with this problem for a while.

    1. 39

      I don’t buy this at all. For one thing, it’s really very easy to solve this within the parameters I think you’re implying: just put WP on an unpredictable path, or gate it behind HTTP basic auth.

      But more generally I think any security model based on hosting a public server that people can’t find is just broken. Domain names can be discovered in many ways, of which certificate transparency logs are just one newer and particularly easy example. It’s a race against time at best, and an unwinnable race against time against a determined attacker.

      1. 2

        I don’t buy this at all. For one thing, it’s really very easy to solve this within the parameters I think you’re implying: just put WP on an unpredictable path, or gate it behind HTTP basic auth.

        I don’t see how any if this works without WordPress making installs more complicated. Some setup either happens before you upload files, or you get cloud WordPress involved.

        1. 11

          This isn’t complicated. If you install it from source, there should be no admin password until you set it in the config (along with the DB connection info and a bunch of other stuff you already have to set). If a hosting company installs it for you, they should assign a random password and give it to you out of band.

          1. 3

            IIRC, the traditional wordpress install process involves you configuring the DB connection info in the installer, and the installer writing the config for you - so in theory, you don’t currently need to make any manual config edits.

            1. 1

              Presumably they don’t want you to put the admin password in a file … But the point about connection information for the database is completely valid.

              1. 1

                Right, I was thinking it’s just an initial password you’d have to change during the web setup process when you set up the real admin account. (Another improvement I’d make is forcing an admin user to be created rather than having an “admin” account exist at all.)

            2. 4

              making installs more complicated

              Even with a key, opening a locked door is harder than opening an unlocked one; that’s not a great argument for leaving your doors unlocked.

              Wordpress could require you to set an “initial setup password” at install time, or require that initial setup be done on the loopback address (you can ssh-forward a port to connect), or any number of other methods.

              1. 4

                Wordpress could require you to set an “initial setup password” at install time, or require that initial setup be done on the loopback address (you can ssh-forward a port to connect), or any number of other methods.

                And yet, all of these things are significant barriers to install, something WordPress has optimized over it’s 20ish year history. Should they do something? Yes. Are they likely to do something that complicates the install process too much more than they already have to? Pretty unlikely.

                So, let’s see in order of “these are mitigations I can think of off the top of my head* with difficulty between 1 (easy) and 5 (easy) for J. Basic User:

                1. Have the user setup http basic auth before install: 5
                2. Require the user edit a file before uploading it to the website that has an install password: 3
                3. Move the install to a random directory for setup, and then move it back / symlink it / whatever: 4
                4. Require registering the domain with WordPress.com and somehow validating it when you login via WordPress.com: 2
                5. Recommend people use web hosts that have 1-click WordPress setups, and make them deal with it: 1
                6. Do nothing: 1

                Not sure of the install statistics, but I’d guess that 1-click setups are probably fairly popular, so the “experts” that are offering them should be able to take on most of the burden. Then, maybe the edit a file before uploading is good enough for the bulk of the other users who are going so far as to set it up themselves, completely… Seems reasonable to me.

          2. 17

            The actual problem is:

            These installers usually come without any authentication. Whoever accesses a web host with a WordPress installer can finish the installation.

            There was a discussion here last week that went into “secure by default.” Security is improved by not having to turn security features on in the first place. Usually that’s because users may forget or put off turning them on. In this case it’s because of a race condition.

            A program should not ship with fixed, well-known credentials to administer it. This has caused so many problems in the past, such as millions of easily-hackable MongoDB installations. Raspberry Pi just updated their installers to stop creating a default “pi” admin account.

            1. 2

              I think the problem here is that you unzip the downloaded release onto your shared hosting account, but then you need “somehow” to supply it with unique credentials just for you. Since it’s all about ease of use, editing a file remotely might be too much to ask (especially if it requires you to get the syntax right), this is not really an option.

              It doesn’t really have fixed credentials BTW; it just presents you with an installation wizard which sets up the admin user for you with a password of your own choosing.

              1. 2

                If you can unzip the files remote editing seems like a pretty low bar. Maybe they can make a “config generator” that produces a second zip that sets a password (that is also shown on the website). If you want to be really fancy just inject a random password on the fly into the main zip. (Computationally easy but removes the ability to use a basic HTTP CDN)

                But in my mind just unzipping an archive into your webserver shouldn’t allow remote code execution. That seems like the wrong tradeoff to me. The unzipped files should be “unarmed” by default.

                1. 1

                  I mean, you could have a setting “mode = uninitialized” in the zip, then on startup, WP sees that, and dumps a password into startup-password.txt on the machine in a private location accessible to SFTP but not WWW, and then WP deletes that file the first time someone logs in. There are plenty of ways to do it. You just have to care about being the largest source of exploits on the web today and not shrug it off.

              2. 5

                How is it ever acceptable for it to start a publically connectible instance without a password? It should just create a password on set-up and print that to console or to a file, the hosters can then take that and for example email it to the customer or display it in their management console or whatever.

                1. 3

                  oh it’s definitely a problem with wordpress, or more specifically:

                  […] that an installation will usually be performed quickly and thus it should pose little risk […]

                  Here is the mistake. Don’t put an open system on the public internet and expect it to be safe.

                  Now how do you make it secure without making the setup complicated is the question, as stated many times below.

                  1. 2

                    The solution would be to make Certificate Transparency more limited; it could require a token in DNS before you can query it.

                    Offering a way to turn off CT is like offering a backdoor for encryption. No matter how much you claim that only the “good guys” will be able to use it, sooner or later it is inevitable that the “bad guys” will be able to use it to.

                    Meanwhile this is Wordpress’ problem. The security of the installer is entirely dependent on nobody else knowing there’s a Wordpress installer running on a given URL; that’s simply not workable as a security model, and honestly hasn’t been for years and years. CT is just the thing that’s making you aware of it, but if you think the “bad guys” don’t or won’t ever have other ways to scan newly-registered or newly-provisioned stuff, well, you’re just flat wrong. People are going to figure out ways to do this, and every time a vector opens up for it Wordpress will be broken.

                    So this absolutely is Wordpress’ problem (and any other software that has the same “security” model). There are tons of ways to fix this — injecting a randomly-generated password into the download and making the user copy it from the page wouldn’t even be that hard! — and it’s time for WP to adopt one of them.

                    1. 1

                      The solution would be to make Certificate Transparency more limited; it could require a token in DNS before you can query it.

                      So basically I’m translating this as:

                      “it would require the DNS admin to do operations before the unsecure wordpress can be exploited”.

                      How would this solve the real problem of wordpress being unsecure by default?

                      Putting the responsibility for this securty problem on WordPress is the world upside down.

                      It’s just 2 separate things:

                      • discoverability of an unsecure system (cert transparency is just one way to find them)
                      • leaving a system vulnerable

                      Fixing one won’t fix the other.

                      1. 2

                        discoverability of an unsecure system (cert transparency is just one way to find them)

                        It’s a very effective one, I would argue it’s even the most effective one by far. Other methods (continuous scanning) take a lot more effort and are a lot harder to do covertly. Especially if you want to hit the time window between uploading and setting the admin password, which will typically be well under an hour.

                        So basically I’m translating this as:

                        “it would require the DNS admin to do operations before the unsecure wordpress can be exploited”.

                        DNS admins do typically not allow zone transfers to anyone, try running dig AXFR lobste.rs @ns1.dnsimple.com, yet crt.sh shows me that there was an l.lobste.rs at some point. Why should I be allowed to query this, and why is it not possible to opt-out from that? So why the difference? Why do we still block zone transfers as a security measure (don’t show more data than you have to), yet we’re fine with bad actors subscribing to CT feeds telling them which hostnames are new and possibly an easier target.

                        Setting a token in your TXT record, such as the sha512 hash of a secret string, and requiring to provide the secret string when querying CT logs for your domain, would improve security of CT a lot.

                        But making CT opt-in might be even better, as CT does not really offer much unless you’re one of the big ones. Most reports I’ve seen from people monitoring CT for their domain, is figuring out that their cloud provider switched CAs, such as recently when Cloudflare started signing using two different CAs (one wonders why people who use CT don’t use CAA records). But I have yet to see a small site use CT to find out about a rogue CA (not just bad practices, actual exploitable security problems), and be able to do something about it.

                        1. 6

                          Making CT opt-in… doesn’t really work. The point, for better or worse, of CT as a security model is that all CAs are observable and their mistakes can be picked up in third-party audits. If there’s any mechanism for secret certificates to be issued, CT instantly loses most of its value.

                          Also, CT is designed to provide an efficient means for third parties to check that the CT log services themselves are serving the same log to everyone. But that requires CT log services to serve the same log to everyone. If we accept the existence of entries that the server is not prepared to reveal to everyone, we’re also accepting a reduction in the level of confidence we can have in CT itself.

                          Incidentally, most domains are discovered by passive DNS monitors at some point, and this data is generally available for sale (to security companies, but you can count on bad actors finding a way). How quickly that happens will depend on various factors, but it can be comparable to CT—so while it’s obvious that CT makes this kind of attack a lot easier, I don’t think it was ever safe. CT’s contribution might even be a positive one, if it ultimately leads to more effort invested in making the secure way easy.

                          In any case, having lost the obscurity in a security-through-obscurity setup, I think it’s probably wrong to focus on trying to get the obscurity back.

                    2. 3

                      Ugh. Some responses come to mind:

                      • use an ssh tunnel to securely set it up, and afterwards, enable ssl certs. I’d hope that the detected hostname and http protocol aren’t too hard to unwind.
                      • caprover allows for setting the initial default password from the command line. Following this is the most promising, I think.
                      • watch the logs as you set it up, filter out your own IP, maybe get a heads up, at least
                      • do it locally, then copy the files and database to the server

                      (Apparently, all of my ideas involve ssh.)

                      1. 6

                        The problem here is the audience who’s setting up these instances. It is uh, almost definitely not going to be people who are familiar with any of those things.

                        1. 4

                          No, the actual problem is that someone misled them into thinking that installing WP yourself when you’re not familiar with any of those things is an acceptable state of affairs.

                          People see that there’s a “free” way to get it, and rather than signing up for some managed plan that will actually serve them better decide that it’s “easy enough” to just follow the steps in a readme… but over time they will almost certainly tend to a 100% chance of breaking or getting hacked, as there is no actual plan to maintain the site.

                          1. 2

                            Wordpress has an automatic update function AFAIK, so I’m not sure the risk is as high as you think it is. The real problem comes when people install shitty unmaintained add-ons.

                            1. 2
                              • Updates aren’t universally enabled – I think they may be the default now, but weren’t for a long time
                              • There’s approximately zero oversight of what can get pushed out on those automatic updates, so they’ve been a supply chain attack target
                              • Those same people are the ones who are unlikely to be able to judge the shitty unmaintained add-ons from the rest
                              • These self-managed installs often end up on bottom of the barrel unmanaged vps instances, so there is likely nothing updating the os, httpd, php, etc…
                          2. 1

                            I didn’t consider these “solutions” as much as “possible workarounds” - they’re not trivial!

                        2. 2

                          I would say that 99% of the times, for php cms, you work in local and the you upload your db and files with phpmyadmin and filezilla.

                          No exposed cms to configure. Especially if you are the type of person who has the knowledge to get certificates by yourself with certbot.

                          For the rest of the world, as mentioned by others, they will get an instance issued by the share hosting company using cPanel or similar, which set random user and credentials for you.