Hello and welcome to the Monday, March 11, 2020,

edition of the Sands and the Storm Center's Stormcast.

My name is Johannes Ulrich, and the time recording from Jacksonville, Florida.

So today I want to start with WordPress.

I usually kind of ignore WordPress.

There are always numerous vulnerabilities in WordPress, extensions and such, so kind of ignore WordPress. There are always numerous vulnerabilities in WordPress,

extensions and such, so kind of got tired of it and don't really mention them anymore here

in the podcast. But there's something new going on with WordPress that I think is worth

mentioning. And that's attackers deploying JavaScript on compromised websites that are then being used

to trick clients into brute forcing passwords against other third-party WordPress websites.

WordPress has an API to log in.

There's nothing really wrong about this.

That's very common.

But typically you have same origin policy that prevents JavaScript being loaded from a third party from actually abusing these APIs.

JavaScript can still send a simple request to the third party, but JavaScript is then prevented from actually parsing the response. So you could do

theoretically sort of the brute forcing, but there would be no good way for an attacker to figure

out whether or not the password is

actually correct. Unless you add a specific header to the API, access control, our origin,

asterix that will allow third parties to actually then parse the response coming back from the API.

Now, I tried to figure out what's a default setting here in WordPress and immediately came across a Stack Overflow article that says, hey, if you're having a problem with JavaScript axing your WordPress API,

this is the header that you need to add, access control our origin asterisk.

So basically it looks like there's a widespread recommendation to deploy this insecure configuration.

...