Episode 98: How Application Passwords Work in WordPress 5.6

WordPress 5.6 was released this week with a new feature called application passwords. In this episode we talk about how application passwords work, where to find them in your WordPress installation, and why Wordfence decided to turn these off by default in version 7.4.14. We also talk about a new Magecart attack that places card skimmers inside of CSS files, MailPoet joining WooCommerce and what this means for eCommerce on WordPress sites.

FireEye, one of the largest security firms, reported they were hacked by a nation state APT group. And a wormable zero-click vulnerability was found in Microsoft Teams.

Here are timestamps and links in case you’d like to jump around, and a transcript is below.
0:25 Application passwords introduced in WordPress 5.6, Wordfence Live social engineering demo
7:57 Credit card skimmers found in CSS files
10:30 MailPoet joins WooCommerce, The Repository newsletter
14:04 FireEye reveals it was hacked by a nation state APT group
17:49 Wormable zero-click vulnerability discovered in Microsoft Teams

Find us on your favorite app or platform including iTunes, Google Podcasts, Spotify, YouTube, SoundCloud and Overcast.

Click here to download an MP3 version of this podcast. Subscribe to our RSS feed.

Episode 98 Transcript

Ram Gall:
Hi, and welcome to episode 98 of Think Like a Hacker, the podcast where myself, QA Engineer and Threat Analyst Ramuel Gall, and Director of Marketing Kathy Zant-
Kathy Zant:
Hi, Ram. How you doing?
Ram:
Hi. We’re going to talk about some cool stuff this week, as usual, aren’t we?
Kathy:
Yeah, I think we are. There’s a lot going on. We just had WordPress 5.6 get released a couple of days ago. You wrote a post about that, didn’t you?
Ram:
I did. So, there’s a bunch of cool things, but one of the things it introduces is something called application passwords.
Kathy:
Tell me more about that.
Ram:
Application passwords are basically a way for WordPress to grant access via its REST-API to external applications and programs. So, you can automate passing data back and forth or making changes on your site remotely via an external program. Now, this is really cool, and it does have a lot of possible future utility, and it’s going to be resistant to brute force attacks. You can’t do credential stuffing with it because these are randomly generated each time you use them. So, that’s the good news. And where you can find them, if you don’t have the latest version of Wordfence installed… By the way, if you do have the latest version of Wordfence installed, we have turned them off by default, and we will get to why in a minute.
Kathy:
Okay. So, if I don’t have Wordfence installed, or if I’ve actually gone into Wordfence… And we added something in version 7.4.14 that turns off application passwords by default. So, if I untoggle that in my Wordfence settings, where am I going to find using application passwords in WordPress 5.6?
Ram:
Here’s the thing. You do have to have a TLS certificate or an SSL on your site. So, it has to be HTTPS, but if you have that, you can manually generate these passwords by going to your user profile.
Kathy:
Oh, interesting. So, does every user get this?
Ram:
Every single user on the site gets this, at least everyone that can access the profile page.
Kathy:
Okay. So, if I have a user that, say, has minimal permissions, like a subscriber, that has application passwords, too?
Ram:
It should. Yes.
Kathy:
Now, if I was going to do something with application passwords, with a subscriber-level user, that would only give that user access to subscriber-level functions, right?
Ram:
Correct. And they would have to actually be implemented in the REST-API for them to actually take advantage of that. Now, not a lot of plugins that do add features into the REST-API that can be accessed by subscriber-level plugins, but there probably are some that do. And e-commerce features, you might want those to be accessible by customer-level users.
Kathy:
Okay. Tell me, why did we decide in Wordfence 7.4.14 to turn this off by default?
Ram:
So, you can manually create one of these passwords, but there’s another way to get those generated, and it’s a lot easier. And that’s basically just a case of generating a link that goes to a specific page with specific querystring parameters. If you can get someone to click this link, the site will ask if you want to generate an application password for that application. And, here’s the thing. You can name the application whatever you want. And let’s say an attacker sends an email saying, “Hey, this plugin that you have installed on your site, we’ve just added application features. Click here to set it up.” And if you’re logged out, then you do have to log into your site. But once you click there, you can just say “authorize,” and whatever application you just authorized, the password gets sent to them.
Kathy:
So, if this was an administrator level account that had this application password, it would then have administrator-level permissions, and they could do things like, create a new user?
Ram:
You can create new users, you can write posts, all via the REST API built-in functionality. So, and yes, you can’t log into a site using an application password, but that doesn’t matter if you can create an administrative user using the application password of an existing administrator.
Kathy:
And Chloe Chamberland is the one who discovered that this could be done, and she demo’ed this, or demonstrated, on Wordfence Live the other day, didn’t she? What did she show us?
Ram:
Correct. She actually socially engineered me into giving her an application password via a email that looked like it was from Jetpack, though there were some tells that it was from her, specifically the fact that it was signed “Evil Hacker.” I should’ve seen that coming, but you know…
Kathy:
Yeah. Chloe is fun for phishing expeditions, isn’t she.
Ram:
I know, right?
Kathy:
Yeah. But she really does show us what this looks like, or what it could look like if an attacker wanted to do something with this. I mean, it is basically preying upon someone who might not know any better and would click that link and grant access, correct?
Ram:
Yeah. You can always tell yourself, “I would never be socially engineered like that,” but I want to say maybe a decade or so ago, I have actually clicked on a phishing link and filled out credentials into a phishing form. I immediately realized what was happening and changed all my passwords after this. But, I mean, this was before I knew as much as I do now, but it can happen to anyone. And don’t underestimate social engineering, because people are the weakest link. And, I mean, that’s not to say that users aren’t smart, but they still do dumb things sometimes.
Kathy:
Right. And there’s a lot of people who are out in the world, running a business… you know, flower shops… and they’re just like, “Okay, well, here’s the new version of WordPress.” They update it, but they might not be fully versed in everything that’s being added into the new version of WordPress, and they might not understand what an application password is, because it’s not being used by anything right now. So, it’s very ethereal, or it’s not something that has a use case. So, it doesn’t seem like something that could be used by anybody bad, because nobody’s really using it. So, it’s safe, right?
Ram:
I mean, a lot of developers are probably going to find this makes their lives a lot easier. A lot of plugin developers are probably going to start taking advantage of it in the near future, but for the time being, every site that has WordPress 5.6 installed could be socially engineered like this, but the actual, legitimate use cases are just slowly going to pop up. So, the number of people that could be exposed to malicious use cases is a lot higher than the ones that have a use for the legitimate use case… For now.
Kathy:
Right, because the use case right now feels abstract. It’s this thing that could happen, maybe, some day, but without it having an actual implementation right now, it’s hard for the average user to visualize how this could happen, which is, I think, why we made the decision to build this into Wordfence and turn off application passwords by default.
Ram:
Yeah. As time goes on, if they start coming into more frequent usage, we may have to add some nuance to it, maybe just a warning whenever you try to set up an application password rather than just an on or off button. Who knows. But for the time being, we felt that the risks outweighed the benefits, and we do offer you a way to turn it back on. It’s under Wordfence firewall brute force settings. So, yeah.
Kathy:
Excellent. Okay. Well, we’ll keep you updated. I’m really interested in seeing when this does get used by a developer for something that’s really cool. Because I think, future-focused, this is going to add additional functionality to WordPress that’s going to make WordPress even more user-friendly and useful for those users who are using it.
Ram:
Yeah. When we did Wordfence Central, we had to basically make our own authentication and authorization functionality. And thanks to Matt Barry, our lead developer, who is absolutely brilliant, he managed to make a incredibly secure system, but a lot of the time, if you try to roll your own for something like that, it’s not going to turn out nearly as well, and this would have made that a lot easier. If this had been out when we came out with Central, we may have decided to use it instead. I don’t know that for sure, but there’s a decent chance of it.
Kathy:
Interesting. Okay. Well, we’ll keep you guys posted on this. We saw a story… Well, it was in both BleepingComputer and ZDNet… about hackers using… Well, we’ve seen a number of web skimmers, but we’re starting to see them being buried in CSS files. What do you know about this, Ram?
Ram:
So, this is interesting. They call them Magecart scripts, and they call them that because Magento was one of the first open-source content management systems, CMS systems, designed for e-commerce that was free. And I don’t want to say easy to use, because it really wasn’t, but usable. And initially there was one or more threat actors that would insert JavaScripts into Magento sites and use them to steal credit card information as customers were entering that information and send it back. And they started calling them Magecart scripts, and it may have initially referred to a single threat actor. I’ve heard them referred to as “the Magecart gang.” But as far as we know now, it’s more of a modus operandi, or an MO, than it is a single organization. There are multiple Magecart gangs out there that all add skimmers to sites.
Kathy:
So, there’s no big organization with the king of Magecart that…
Ram:
As far as I know. I mean, there might be. There could be a central Magecart organization, but I suspect that it’s different threat actors.
Kathy:
Sure. Sure. And what are they doing with style sheet or CSS files?
Ram:
So, this one’s interesting, and it’s interesting because they hid the actual skimmer script in a CSS file. Now, I should go into some more detail on that, and that’s to say that if you’re on a modern browser, you still can’t execute JavaScript directly inside a CSS file. You can’t load it up and the script will run. But basically, it looks like what was happening with this, if I’m looking at the screenshots correctly, and these were shared by Willem de Groot, founder of Dutch security firm Sanguine Security, but they were embedding the actual script in the CSS file, and then they had a separate JavaScript on the actual site’s page that said, “Hey, look at the CSS selector and execute whatever you find inside of it.”
Kathy:
Now, if somebody has got malware in a CSS file, they probably have malware elsewhere in the site as well, too. Right?
Ram:
Correct. It is possible to construct a skimmer using only CSS, but it’s huge, it’s clunky, it kind of stands out. It’s not widely used in the wild, as far as we know. Using just pure CSS selectors to exfiltrate data, it can be done, but it doesn’t seem to be as common as other methods.
Kathy:
All right. Excellent. Cool. Hey, did you see the news that MailPoet is joining WooCommerce?
Ram:
I did. So, I guess since WooCommerce is an Automattic company, so this means that Automattic now has MailPoet and WooCommerce, but this is more your beat than mine. So, I know what they do. I know what WooCommerce does. It’s an e-commerce solution. And I know that MailPoet is a way to send mailing lists, but that’s about all I know.
Kathy:
Well, I can’t remember, It was about maybe five years ago or so that we actually saw WooCommerce was purchased by Automattic way back in the day. And I thought that was really cool. It was neat to see Automattic and WordPress really see how important e-commerce is going to be for WordPress growth and for sites looking to sell things, which is a big part of what I think WordPress’s growth is about. When you are selling things, if you run an e-commerce site, there are a number of things other than just taking the order that you need to do. You need to email your users and send them a receipt for what they purchased. You need to send them stock notifications. You need to be able to send them shipment notifications and delivery notifications, marketing things.
Kathy:
So, MailPoet is now being used by 300,000 sites, and we know the team over there. They’re great. They also do The Repository, which is a great newsletter for WordPress news. You should go find that, and we’ll put that in the show notes. It’s a great little newsletter just to stay up on top of all of the things that are happening in WordPress. But I’ve noticed that they have been adding more and more transactional types of emails and support for WooCommerce users in their documents and their marketing, and actually have advised a friend of mine, who is now using WooCommerce and MailPoet, to send out their e-commerce news.
Kathy:
And so, I find this is going to be very interesting. Obviously, in the e-commerce space, Shopify is the behemoth. It’s the one that is doing all of the e-commerce types of things and is a one-stop shop. And I think this is going to make WooCommerce even more competitive in the e-commerce space, and I think this is going to be great for WordPress. So, a big congratulations to the team over at MailPoet for joining WooCommerce, and a fine choice by Automattic to have MailPoet come along on that WooCommerce journey. I think it’s going to be great.
Ram:
All I have to say is, wow. E-commerce is hard.
Kathy:
E-commerce is hard. There’s a lot of moving parts. And I mean, if you think about… I mean, obviously, everybody who listens to this podcast has probably purchased something from Amazon at one point or another, and they’ve kind of set the gold standard. What happens in an e-commerce transaction, what kind of information needs to be available. Your cart is fairly persistent. All of these types of things that people then come to expect with even the smallest shop. And so, therefore, in order to compete with behemoths like Amazon, you have to have that kind of functionality available to your users, because that’s what people expect. And so, to be able to build something like this for WooCommerce and for WordPress users, is… It takes a lot, and it’s exciting to see where WooCommerce is going. This is a very good sign.
Ram:
So, anything that makes it more accessible is definitely a good thing.
Kathy:
Yes, definitely. More functionality and able to unseat the behemoths. I always like a little bit of disruption for things that get a little too big.
Ram:
Yep. Don’t we all.
Kathy:
So, what do you know about FireEye?
Ram:
FireEye’s… So, this is actually one of the big cybersecurity news items this week. FireEye is a cybersecurity firm. They do a lot of penetration testing, contract stuff. They’re fairly big, they’re highly respected, and they got hacked. So, I mean, by a nation-state actor. It was APT29, which also gets the name of Cozy Bear, not to be confused with Fancy Bear, though they are apparently both backed by the Russian state security services, but they don’t usually work in tandem with each other. They tend to not really work together, from what I’ve heard.
Kathy:
Interesting. Okay. But they’re bears because they’re Russian?
Ram:
That is my understanding. Yes.
Kathy:
Okay. And we don’t want… Scary bears.
Ram:
Exactly.
Kathy:
Like, one is maybe a grizzly and the other is a black bear?
Ram:
I do not know if that’s an apt comparison, but I think the Cozy Bear gets a brown and blue motif.
Kathy:
Ah, interesting. Okay. Well, that sounds pretty scary there.
Ram:
It does. I guess they used a novel combination of techniques, which doesn’t really tell us much, but I believe that at least some of the tools that were stolen, since a lot of what they stole were the penetration testing tools that FireEye uses.
Kathy:
And what would they use penetration testing tools for?
Ram:
Well, to hack other people. So, a lot of the tools, I guess, that they may have been able to access one of the GitHub accounts that had these tools available on it… So, FireEye does penetration testing for government, federal agencies, high-profile businesses, organizations, and these are the tools that FireEye uses to basically get paid to hack these organizations in order to make sure that they’re secure. So, they’ve got some good stuff. From what we understand, there were no zero days, no new or undisclosed zero days, among their toolkit, but there was a lot of stuff similar to Cobalt Strike or Metasploit, a lot of frameworks and tool kits and scripts that make hacking stuff a lot easier. So, FireEye did release… They released Snort rules and also some signatures to detect if those tools are being used against your enterprise or organization. Now, I mean, this is probably not going to impact any WordPress users, just because these are largely tools designed to operate against enterprise systems, that kind of thing, but…
Kathy:
So, an enterprise system would be, like, a mail server or a network?
Ram:
Mail server, corporate network, that kind of thing. I mean, yes, there are going to be cases where the network’s structured where your WordPress website can grant access to your corporate network, but that’s usually a bad idea. Don’t do that, unless you really, really have to.
Kathy:
No application passwords to the enterprise network.
Ram:
Yes, please no.
Kathy:
Okay. All right. So, this is interesting because it’s just such a complex and sophisticated type of attack that happened, and the tools that were taken were fairly sophisticated. And so, we may see some sophisticated actions taking place with all of this.
Ram:
Correct. And I’ve taken a look at some of the Snort rules, and it looks like a lot of what was interesting about it was the way that FireEye actually hid, basically, their phone home stuff and made it look legitimate. They’d hide their “Hey, we succeeded at hacking” requests in really believable, really innocent-looking packages.
Kathy:
So, they really flew under the radar with this.
Ram:
Exactly.
Kathy:
So, that’ll be interesting to watch. We’ll have to keep an eye on that story. What’s going on with Microsoft Teams, speaking of enterprises?
Ram:
Yes. So, there’s a security researcher, Oskars Vegeris, and he’s published documentation on a wormable, cross-platform, remote code execution, zero-click vulnerability in Microsoft Teams, which all those words put together equals a bad time.
Kathy:
It does sound like a bad time.
Ram:
Yeah. So, it started out as a cross-site scripting vulnerability at the teams.microsoft.com domain, and it could be used to trigger remote-code execution in the Teams desktop application. And so, here’s the thing about the Teams desktop application, and you may remember something like this being in the news about Slack, I want to say maybe a year ago, and the reason it’s cross-platform… It was cross-platform for the Slack issue and it’s cross-platform for the Teams issue… is that they are both coded in Electron, which is basically a Chromium browser web app that just happens to run on your desktop.
Ram:
So, I mean, the good news is that they did get this patched in October, and I think the patch was automatically deployed by Microsoft, but before that was done, it was possible for an attacker to pull an XSS against the victim, and then that victim would infect other people’s Teams desktop clients, and then the attacker would gain access to sensitive internal documents or any messages that people communicated on the Teams application. And I think possibly files from other Microsoft services and authorizations tokens, which could be bad, because that could be, like, 365 email or cloud-hosted Word documents. It’s unclear how much access that would grant, but if it’s an SSO token, a single sign-on token, that would give you everything in Office 365 for that user. And that would be very bad, depending on how heavily the organization depended on Office 365.
Kathy:
Wow. That could be really frightening. So, but this is patched now. It was found in, what, October?
Ram:
Yep. It was patched in October. Microsoft, I guess, was kind of reluctant to even issue it a CVE, and they underplayed how severe it was, but they did patch it, and it looks like they patched it fairly quickly, so it looks like they took it seriously, even if they pretended not to.
Kathy:
And Microsoft Teams looks like it has, at the moment, 115 million daily active users, and is still sort of, compared to some other tools like Slack, is not the hugest player in the market. So, they’re probably-
Ram:
But it’s gaining real quick.
Kathy:
Is it really? Okay.
Ram:
Yeah. And, I mean, we’re going to continue to see issues in widely used applications, and that’s just part of how software works. The important thing is making sure to keep everything up to date as soon as you can, because in this case, it looks like they did automatically deploy the patch, but if your organization, for some reason, has a policy that prevents that from happening or whatnot, then you could still be vulnerable to something like this. I don’t think that there’s a way to do that for Teams, but lots of business-critical stuff is going to have vulnerabilities and has vulnerabilities right now, and people are going to find it, and they’re going to patch it, but if you don’t update, you’re going to be vulnerable.
Kathy:
Right. Right. And the longer a vulnerability is known, the higher risk I think it is, because you just get more and more people trying to poke at it. Right?
Ram:
Correct. I mean, zero-day attackers usually hoard them. They don’t let other attackers know that they have them. They just use them judiciously, so as not to get caught for stuff that’s very important, most of the time.
Kathy:
Right. Exactly. So, update, update, update. Well, that looks like all of our stories. That’s it, huh? No more?
Ram:
That is it for now. Hey, thanks for chatting about the hacker-y stuff that’s happened this week.
Kathy:
All of the hacker-y stuff here on Think Like a Hacker. Thanks to everyone who’s been listening, and thanks to… It looks like we’re big in Ireland now. Did you see that?
Ram:
I did. I did. That’s pretty cool. I’ve always wanted to visit.
Kathy:
We might have to, now that we’re Think Like a Hacker, I think-
Ram:
Maybe we could go to WordCamp Dublin when there is one.
Kathy:
That sounds like a plan. I’m ready.
Ram:
I am so ready for that.
Kathy:
I’m ready for another WordCamp, too. I’m missing all of our WordPress community and everything, but we are so grateful that you joined us here on Think Like a Hacker. We’re so grateful that you join us every Tuesday on Wordfence Live over on YouTube, in this time of all of our lockdowns, that we can still remain connected.
Ram:
And seriously, watch me go get socially engineered by Chloe on this last Tuesday’s Wordfence Live. It’s awesome.
Kathy:
It is awesome. We will put a link to that in the show notes, and thanks to all of our premium customers who make those firewall rules possible for the entirety of WordPress community. And thanks for listening. We will catch you again next week on Think Like a Hacker, which will be episode 99.
Ram:
99.
Kathy:
Wow. There’s a milestone coming.
Ram:
I know, right?
Kathy:
Thanks for joining me, Ram, you’re on Twitter at-
Ram:
@ramuelgall.
Kathy:
Awesome, and I am @kathyzant, and follow Wordfence as well. We will talk to you next week.
Ram:
Bye.

You can find Wordfence on Twitter, Facebook, Instagram. You can also find us on YouTube, where we have our weekly Wordfence Live on Tuesdays at noon Eastern, 9:00 AM Pacific.