[wp-trac] [WordPress Trac] #56141: Enhance installer security

[WordPress Trac]

#56141: Enhance installer security
--------------------------+---------------------
 Reporter:  smitka        |       Owner:  (none)
     Type:  enhancement   |      Status:  new
 Priority:  high          |   Milestone:  6.1
Component:  Security      |     Version:
 Severity:  major         |  Resolution:
 Keywords:  dev-feedback  |     Focuses:
--------------------------+---------------------

Comment (by smitka):

 Some updates about the ongoing attack. The main attackers change their
 strategy and generate unique DB credentials per vulnerable site. The
 result is that when I get access to their database, I cannot find new
 hacked sites to notify their admins anymore.

 I sent over 2000 notifications last month and detected around 3000
 different sites in the attacker's databases. I probably only discovered a
 fraction of the compromised sites. In some cases, the attacker was quicker
 than me, and he changed the admin email so I couldn't send the
 notifications. I only gained access to the database if the attacker
 attacked my honeypot servers.


 @lordgurke, I agree it would be great to have the possibility to override
 some constants by the environment values. I have to use the Runkit PHP
 extension to override some values without user intervention. However, we
 still have to keep in mind that env variables can be listed in different
 places, such as phpinfo() output. The chances that this file will be
 available in the unfinished installation are minimal, but I would still
 prefer to avoid using them for the install key.

 I should describe the function of my second proposal in more detail:

 The host specifies **allowed DB servers via env variable**; the localhost
 and 127.0.0.1 are allowed by default. If you use the allowed DB host
 during the installation, the **install key is not required**, and the
 process is unchanged for the majority of new manual installs.

 The situation is different when you want to use an **unlisted DB host**.
 In this scenario, **the installer will generate the install-key.php file**
 and force the user to use it. The user can read it via FTP/SFTP/SSH, or
 the host can show it in the administration (maybe it would be a good idea
 to add another variable to add a link to the host documentation or
 administration).

 There is no need to upload anything, and most users' installation process
 is the same (even if the host doesn't set the variables).

 The flaw with this approach is that there is still a tiny chance that the
 attacker has set up webhosting with the same provider as the target site
 and can use the allowed DB host for malicious activity. To prevent this,
 you can make an "allowed DB names list" too. However, this demands more on
 the host, as it has to prepare unique env variables for each site.

 BTW: it is possible to show the diff between the original setup-config.php
 and my PoC fix: https://gist.github.com/lynt-
 smitka/45608ddeb8df19b0820201d066d4b42c/revisions?diff=unified

 I also added some captions to my explainer video to make it clearer what's
 going on: https://www.youtube.com/watch?v=-1Nd5rdCod0

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/56141#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform