I love trilogies, and a WordPress security trilogy was completed today. I’m now in that weird state of having just finished a series I was super into and didn’t want to end (well minus the security implications).
In early August I discussed the first part of this trilogy, written by a security researcher at Checkpoint. Checkpoint has been credited with numerous security findings in WordPress, including 4.3.1 today (which was auto-updated back to 3.7.x).
The first part of the trilogy described how a subscriber role could create trash posts. In part two, author Netanel Rubin found an unprepared sequel UPDATE in code that toggles trashed comments, and used some very clever shenanigans with revisions to be able to make and trash comments on trashed posts, exposing the exploit.
So, after part 2, there are now posts made by subscribers, but they are in the trash, and separately he can control post contents, but that content gets filtered through KSES. Our old friend shortcodes come to the rescue, and in part 3 the author uses a vulnerability in parsing html within attributes to trick KSES so that an exploit can be live on the page. However, the post is still in the trash. So, with one final trick, the author finds a way to exploit an XML-RPC method that doesn’t have the proper check on private status posts — and as a bonus, also happens when setting a post to be sticky.
And after all of that, a simple subscriber can now create XSS capable posts visible to any user or administrator, by way of either viewing private posts or sticky posts. This was with core WordPress only and no plugins at all, which of course would’ve made the task far simpler.
These posts are seriously entertaining (though a bit terrifying), because you get inside the head of a hacker and see how they can combine various smaller holes to link together a much larger exploit. What’s most terrifying is that of course this would be entirely scriptable and could wreak havoc in the wrong hands.
Fortunately, the researcher worked closely with the WordPress security team, and I understand they were great to work with. That’s a fortunate thing for WordPress.
All software has bugs, as the author notes. WordPress is an enticing platform to hack because of its huge marketshare, and it makes it more likely to be targeted with in-depth and complicated attacks like this. This makes it even more important that WordPress developers be vigilant when writing new code, including steady testing, and thinking not just how to achieve what we want with core code, but how to prevent anything other than exactly what is the expected behavior.
You’ll be a better programmer and a better thinker if you read this little security trilogy. And you’ll have a greater appreciation for WordPress core development, too.
