[Bug]: Logging of Sensitive Data exposed to public access

[robertdevore]

What happened?

The debug-aspire-update.log file reveals that the AspireUpdate plugin logs excessive sensitive data during API interactions. This includes information that could aid in reconnaissance activities if accessed by unauthorized users, posing a significant security risk.

When active, unauthenticated users are able to access the logs by simply going to domain.com/wp-content/debug-aspire-update.log.

Security Concerns Identified

1. Exposure of Plugin Metadata

   • The log includes detailed metadata about installed and active plugins:
     • Plugin names, versions, authors, descriptions, and URIs.
     • Active plugins list, which can help attackers identify potential vulnerabilities in outdated or misconfigured plugins.

2. Disclosure of WordPress Environment Details

   • Logs reveal sensitive environment information, including:
     • User agent string, WordPress version, PHP version, and server details.
   • This data can be leveraged for targeted attacks, especially if the site is running outdated software.

3. Verbose API Logging

   • API endpoints and responses, including WordPress.org core, plugin, and theme update checks, are logged verbosely. This data could be exploited to understand the site's software stack.

Version

0.5 (Default)

OS

MacOS

What browsers are you seeing the problem on?

No response

WordPress

6.7

PHP

No response

Server

No response

Database

No response

Theme

No response

Must-Use Plugins

No response

Plugins

No response

WordPress Site Health Output (optional)

No response

Relevant debug log output

No response

Screenshots/Live demo link

No response

Additional Notes

No response

Code of Conduct

• I agree to follow the Code of Conduct.

[chuckadams]

No real solutions here, just a rant on WP security:

Considering WordPress still needs to run on garbage shared hosting that only offers the 1990s-era experience of putting the whole blasted framework and all its support files like logs in a web root that's completely readable to the world, and writable to any and every plugin...

Encrypting the log file is one possibility, but having to reinitialize the stream cipher every line makes for unspeakably bad crypto that's not portable either to boot, and defeats most of the purpose of a log anyway. Maybe just reject any placement of the log under the web root, so sorry but you have to have real hosting to have logs. That or a big screaming red banner that the whole world can and will read your logs because Wordpress.

[namithj]

This is why I pushed for the clear log button. You log stuff for debugging, figure things out, disable logging and clear the log file. It's the only thing practical with shared hosts which limits us to public html folder.

We should add some kind of warning in the UI for the enable debug functionality.

[chuckadams]

As for a real solution: One thing that should work by default for many setups would be to begin the log filename with a dot, since many (most) web servers do deny access to those in their default config. Probably the best we can do for shared setups.

[chuckadams]

It should also be pretty simple to have the UI check this: just include some javascript in the UI that requests the log file where it would expect to find it given the pathname, and if it succeeds, show a big nasty warning that your log files are public. Could probably just use HEAD for this even, not even GET.

[namithj]

OK so we do this

1. Show a warning to the user that enabling debugging will expose the debug file to the outside world and ask them to clear the log once debugging is done.
2. Clear log when debugging is turned off
3. Check if the log file is accessible using JS and then only trigger the warning in step 1
4. We name the file .debug-aspire-update.log

Anything else needed?

[chuckadams]

Those steps LGTM. Not sure about automatically clearing the log, sometimes people just want to pause and resume logging, but maybe it is best to keep it ephemeral. Way too much data gets exfiltrated these days from "temporary" files that aren't.

[robertdevore]

Could also update the log file name so it's something more unique/random which would stop direct access + hinder brute forcing the filenames.

Something like debug-aspire-update-2scc91edc73em.log would reduce the risk greatly without requiring a lot of extra lifting.

Could also look at adding a line to htaccess files during plugin upload that restricts the folder access to the file.