View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 4846 | Composr | core | public | 2022-05-08 04:59 | 2022-10-19 00:46 |
| Reporter | Chris Graham | Assigned To | PDStig | ||
| Priority | normal | Severity | Security-hole | ||
| Status | resolved | Resolution | fixed | ||
| Summary | 4846: Installers are vulnerable to bot attack | ||||
| Description | Wordpress sites have been getting hacked in the time window between uploading the installer, and it being used. This is possible because new SSL certificate registrations are publicly being advertised by many registrars, including Let's Encrypt. It's easy for a bot to find a newly configured domain. This however would affect our entire industry. The only reasonable fix I can think of is to customise any installers downloaded from our site with the IP address of the the machine downloading them, locking them to that machine. It'd have to be made configurable in some kind of file as otherwise people are going to trip up when doing things like wgetting the installers directly onto a server. The error message about an IP mismatch must be explicit, saying what IP is expected vs what is there (probably partially masked, for privacy). The IP restriction should be in a file that cannot be directly downloaded, probably a .php file. | ||||
| Additional Information | https://portswigger.net/daily-swig/wordpress-sites-getting-hacked-within-seconds-of-tls-certificates-being-issued | ||||
| Tags | Roadmap: v11, Type: Security | ||||
| Attach Tags | |||||
| Time estimation (hours) | 6 | ||||
| Sponsorship open | |||||
|
|
I've thought about this some more, and I think it's reasonable we can making knowing a valid database username+password function as an "installer login". We'd make these changes... 1) Change the DB details probing that we do by looking for an existing Composr install / third party forum install. We never autofill the DB password from the probing, but rather we make the database password field required if we probed successfully and found the password was not blank (this stops users submitting the form thinking the probe is autofilling all the DB details). 2) We won't allow any step after DB credentials are taken to happen without a valid DB connection being established first. 3) The above doesn't happen by DB details saved into _config.php anymore, but rather through DB connection details relayed through the steps as hidden inputs (POST parameters) 4) Disable the XML DB driver if no .git directory is present (because this doesn't require DB credentials, and we are assuming dev machines aren't just connected to the public Internet) 5) Disable using the DB root user if no .git directory present (root user is any of the DB driver's output of default_user()) (because it is common to have a root user with a blank password on a machine, and we don't want bots to be able to guess that unless we really are a dev machine in which case we can assume a higher level of dev responsibility) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2022-05-08 04:59 | Chris Graham | New Issue | |
| 2022-05-08 04:59 | Chris Graham | Tag Attached: Roadmap: v11 | |
| 2022-05-08 04:59 | Chris Graham | Tag Attached: Type: Security | |
| 2022-05-08 05:00 | Chris Graham | Additional Information Updated | |
| 2022-08-15 20:39 | Guest | Note Added: 0007459 | |
| 2022-08-15 20:40 | Chris Graham | Note Added: 0007460 | |
| 2022-08-15 20:40 | Chris Graham | Assigned To | => user4172 |
| 2022-08-15 20:40 | Chris Graham | Status | Not Assigned => Assigned |
| 2022-10-19 00:46 | PDStig | Status | Assigned => Resolved |
| 2022-10-19 00:46 | PDStig | Resolution | open => fixed |
