@SimonWaters opened this issue on December 15th 2016

During security testing 3.0.0-rc3 I noted the following inconsistencies in the use of TLS that means someone with access to network traffic from client to servers (Piwik server or *.piwik.org) or from server to Internet could manipulate the content of pages within Piwik or executable modules, or exec within Piwik even if the end server uses TLS to protect all its page views.

  1. Download link for 3.0.0-rc2 on Piwik blog https://piwik.org/blog/2016/12/piwik-3-release-candidate/ uses HTTP not HTTPS when linking to builds.piwik.org

Mitigate this by migrating the servers to HTTPS and use HSTS to keep users using HTTPS even if they encounter an HTTPS link, including builds.piwik.org.

Although all builds are PGP signed, you wouldn't known this unless you specifically go looking for that information, when you are directed to http://piwik.org/blog/2014/11/verify-signatures-piwik-packages/ this could also mitigate or defeat people attempting to impersonate the builds.piwik.org server.

  1. Help information within in the app links to the Piwik site using HTTP when HTTPS is available.

Mitigation - use HTTPS for these links.

Use of HSTS might reduce the window for attack without needing to change all links.

Some of this information also goes via the Proxy, but still opens pages over HTTP.

  1. Feed burner information is loaded from

http://feeds.feedburner.com/Piwik

by the server to populate the Piwik Blog box by default.

plugins/RssWidget/Widgets/RssChangelog.php: $rss = new RssRenderer('http://feeds.feedburner.com/PiwikReleases'); plugins/RssWidget/Widgets/RssPiwik.php: $rss = new RssRenderer('http://feeds.feedburner.com/Piwik');

The HTTPS version of feedburner URLs are available, although there is some mixed content due to innocraft images loading over HTTP, these images aren't rendered in the RSS summary.

There doesn't appear to be any attempt to sanitise content in the RssRenderer, if the content could be relied on to be from a trusted source the current sanitisation may be sufficient, I didn't try manipulating or replacing feedburner responses, it can at least be exploited to lead users to the wrong website.

Testing of server HTTP use was incomplete, as we didn't start recording server HTTP activity before the installation was started. We noted other server initiated traffic over HTTP, but weren't able to confirm that Piwik was the source.

@SimonWaters commented on May 23rd 2017

Noted in testing 3.0.4 that the request below still travels over HTTP, it also leaks pretty much everything (MYSQL version, PHP version, client IP address, timezone, server URL), and could be manipulated by attacker between server and Piwik server to prevent upgrades being applied, as well as identifying vulnerable servers.

I appreciate server to server HTTPS can be frustrating as many servers have such poor TLS settings out of the box (which is why WordPress does it itself, which isn't ideal either).

GET /1.0/getLatestVersion/?piwik_version=3.0.4&php_version=7.0.16&mysql_version=5.5.54&release_channel=latest_stable&url=http%3A%2F%2F10.66.2.85%2Findex.php&trigger=CoreHome&timezone=Europe%2FLondon HTTP/1.1 Host: api.piwik.org User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:53.0) Gecko/20100101 Firefox/53.0 Accept: / X-Forwarded-For: 10.67.255.98 Via: 3.0.4 (Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:53.0) Gecko/20100101 Firefox/53.0)

Powered by GitHub Issue Mirror