8
Jul
2019
Tag Archives: Cross-Site Request Forgery (CSRF)/Cross-Site Scripting (XSS)
3
Jul
2019
Vulnerability Details: Cross-Site Request Forgery (CSRF)/Cross-Site Scripting (XSS) in Visitors Traffic Real Time Statistics
The changelog entry for the latest version of Visitors Traffic Real Time Statistics is “CSRF bug fixing in settings page (prevent SQL injection) – reported by Mr. Paul”. Looking at the changes made we didn’t see any change made to fix a cross-site request forgery (CSRF) vulnerability, but did see a SQL statement was changed to prepared statement, which would prevent the possibility of SQL injection. Further checking showed that there is still a CSRF vulnerability that can be used to change the plugin’s settings. We notified of the developer of that yesterday, but so far we have not heard back from them and the issue hasn’t been resolved.
…
21
Jun
2019
Vulnerability Details: Authenticated Persistent Cross-Site Scripting (XSS) in Photospace Responsive
The plugin Photospace Responsive was closed on Tuesday. The changelog for the version released since then is “Security update”. The change made partially fixes a security vulnerability, though to the extent if fixes it, not really correctly.
…
13
Jun
2019
Simply Closing a WordPress Plugin With a Vulnerability Likely to Be Exploited Just Leaves Websites Open to Being Hacked
As part of making sure the customers of our service are getting the best information on vulnerabilities in WordPress plugins they may be using we monitor for hackers probing for usage of plugins on our website and then try to figure out what the hackers might be looking to exploit. A week ago that led to us running across two plugins with unfixed vulnerabilities. One of those plugins was closed on the WordPress Plugin Directory on May 9. In the past day we had saw a hacker probing for another plugin that was closed on the same day, Real Estate Manager – Property Listing and Agent Management.
What we found when went to look to see if there were any vulnerabilities in this plugin was nearly identical to what we found with the previous one, making it seem likely that they were both closed due to security issues discovered by the same party. Closing them and doing nothing else isn’t a solution, as what has happened with these plugin is yet another reminder of. This is a solvable problem, but the people currently running the WordPress Plugin Directory seem to be incapable of handling or even acknowledging the problem. One of the six people on the team running it, for example has claimed there is never a need to remove closed plugins: [Read more]
7
Jun
2019
Vulnerability Details: CSRF/XSS in Category Specific RSS Menu (Category Specific RSS feed Subscription)
If there was ever an interest on the WordPress side of things to actual improve the security of plugins one obvious area for that would be a mechanism for developers to report if security vulnerabilities have been fixed in the plugins, so that additional reviewing of them could be done. The latest version of the plugin Category Specific RSS Menu (Category Specific RSS feed Subscription) would seems like a good example of where that could further improve the security of the plugin, as it turns out the new version fixes a security issue but while only addressing half of the security issues that caused the vulnerability.
…
6
Jun
2019
Did WordPress Leave Users of the Plugin About Me Page in the Dark About Vulnerability Hackers May Now Be Targeting?
As part of making sure the customers of our service are getting the best information on vulnerabilities in WordPress plugins they may be using we monitor for hackers probing for usage of plugins on our website and then try to figure out what the hackers might be looking to exploit. For the second time today, that has led to us running across a plugin with an unfixed vulnerability that hackers could be interested in.
This time it involves the plugin About Me Page, which was closed on the Plugin Directory on May 9. No reason has been given for the closure, but one reason it could have been closed is for a security vulnerability like the authenticated persistent cross-site scripting (XSS) vulnerability we immediately ran across when we starting looking at the plugin. That is a type of vulnerability we have seen hackers targeting recently, though with only 1,000+ installs it would seem less likely to be a targeted considering the attacker would need a WordPress account, but it may be that hackers are casting a wider net or don’t know the limited usage of the plugin. [Read more]
4
Jun
2019
Vulnerability Details: Authenticated Persistent XSS in Personalized WooCommerce Store (Personalized WooCommerce Cart Page)
That the plugin WooCommerce Store (Personalized WooCommerce Cart Page) would contain a serious security vulnerability isn’t really surprising since the developer has had numerous security issues in their plugins and doesn’t appear to have been interested in making sure they are doing things securely.
…
29
May
2019
28
May
2019
Vulnerability Details: Cross-Site Request Forgery (CSRF)/Cross-Site Scripting (XSS) in WP Open Graph
A cross-site request forgery (CSRF)/cross-site scripting vulnerability fixed in the plugin WP Open Graph is a good example of why trying to rely on changelog entries to tell if you there is a security update is included in a new version doesn’t work well as the version this was fixed in didn’t have a changelog entry. We ran across this because the CSRF portion was vaguely disclosed by the JPCERT/CC and credited to Koichi Kuriyama of Cryptography Laboratory, Department of Information and Communication Engineering, Tokyo Denki University. In looking into it we found that also involved XSS.
…
22
May
2019
Cross-Site Request Forgery (CSRF)/Cross-Site Scripting (XSS) Vulnerability in Slimstat Analytics
Yesterday we detailed a persistent cross-site scripting (XSS) vulnerability in the plugin Slimstat Analytics and about the same time the discoverer of the vulnerability Sucuri had released a post with similar details, but notably silent about how the vulnerability was fixed. We are not sure why they didn’t include that, but it is important since the fix was less than ideal as instead of using the relevant WordPress escaping function the developer used code that did a more limited version of that function (yesterday we notified the developer that could be better handled). It is always a good idea to not to roll your own security code when you don’t need to, so what happened there might be a sign that the developer doesn’t have the best handle on dealing with the security of WordPress plugins.
That is further backed up by a cross-site request forgery (CSRF)/cross-site scripting (XSS) vulnerability we found in the plugin, which we noticed by chance while figuring out what versions were impacted by the other vulnerability so that we could let them know if versions of the plugin used on their websites were impacted. We noticed part of that vulnerability while looking at a fairly old version, so we suspected it would have been noticed and fixed by now considering the plugin has 100,000+ active installations according to wordpress.org, but that isn’t the case. [Read more]