Episode 106: Admin Password Resets, Blockchain Botnets and a Central Management RCE

WordPress 5.7 is due to be released on March 9, and it will allow administrators to send password reset emails to users. A botnet is abusing the Bitcoin blockchain for command and control, while VMWare fixes a critical remote code execution bug in all default vCenter installations. Android users now have an easy way to check password security. We talk about the ramifications of vulnerability disclosures and how last year’s File Manager vulnerability did not have long lasting effects on plugin installation base or growth. We also discuss how investor data breach fatigue has reduced the stock price impact of cybersecurity failures.

Here are timestamps and links in case you’d like to jump around, and a transcript is below.
0:41 Wordfence/Defiant is hiring, and we’re offering a $500 gift card for anyone who refers a successful candidate
2:30 The Wordfence K-12 site cleaning and site audit program continues to help schools around the world
3:00 WordPress 5.7 will allow administrators to send password reset emails
6:20 This botnet is abusing the Bitcoin blockchain to stay in the shadows
9:52 VMWare fixes critical RCE bug in all default vCenter installations
11:53 Android users now have an easy way to check password security
14:40 Investor data breach ‘fatigue’ reduces Wall Street punishment for cybersecurity failures

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 106 Transcript

Ram:
Welcome to Think Like A Hacker, the podcast about WordPress, security, and innovation. I am Ram Gall, threat analyst at Wordfence, and with me is director of marketing, Kathy Zant. Kathy, how are things?

Kathy:
Things are very, very good compared to last week. It’s almost like Texas has somewhat recovered. At least the weather’s recovered. I think people here-

Ram:
Do have power and water now?

Kathy:
I have power. I have water. The skies were blue yesterday. We have ping pong ball sized hail coming, apparently. What is with Texas? I don’t know. It’s interesting, though. Got to keep-

Ram:
Everything is bigger in Texas, even the hail.

Kathy:
Even the hail. It’s a crazy place. Anyway, all is well. And we have some interesting things, some big things happening with Wordfence.

Ram:
I hear we are hiring.

Kathy:
We are hiring. We’re hiring for four specific roles. These are senior roles. So we wanted to sweeten the pot for all of our listeners who are out there listening who… Come on. You guys know someone who’s amazing. Someone who’s looking for-

Ram:
And you like free money, too, right?

Kathy:
And you like free money. So we thought we’d put all of those things together, and we want you to refer someone that you think would be exceptional in one of these roles and that would enjoy the fun, fast-paced environment we have here at Wordfence.

Kathy:
We have a security operations role. We want someone who’s up on the AWS scene. We’re looking for a couple of senior PHP developers and a senior researcher who is very interested in website performance. If you know someone and you refer someone, we will give you a $500 gift card if you refer a successful candidate. And if you think you might be a successful candidate, we would love to talk to you. There are links in the show notes for these job descriptions so you can get the full details about what these jobs entail and the benefits of working here at Defiant. Benefits that even include a week off between Christmas and New Year’s, which is always a nice time. Don’t you love that, Ram?

Ram:
Yeah. Yeah. Honestly, the last few years we’ve been doing it, but they finally made it official policy instead of just a cool thing we decided to do at the last minute.

Kathy:
Yeah, exactly. It’s a nice way to end the year. Just kind of think back over the previous year and plan for the future. Always a good time.

Kathy:
We also have our K-12 school initiative, site cleaning and site audits available for any government or state funded school in the United States, in Canada, in Mexico, anywhere in the world. If you know of a school that could use some security support, send them our way. We are cleaning and auditing those sites for free, and educating the educators. That program is continuing and continues to be a success, so we just wanted to mention it. We would love your referrals. Just send those schools our way.

Kathy:
Now, we saw some interesting stuff coming in WordPress 5.7. Ram, what do you know?

Ram:
WordPress 5.7 is actually fulfilling a sort of long-requested feature to let administrators send password reset links. And this is very cool. I mean, there is some potential for abuse via social engineering, but I mean, if you think about it, an attacker can already request a password reset for a user if they know or can guess the username or email address, so it’s not like attackers can’t send password resets to people anyways.

Kathy:
Sure, sure. Now this feature is rolling out in WordPress 5.7, which is coming up pretty soon. This has been a five-year-old ticket that has been in the trac system, and it’s going to allow administrators to manually send a password reset link to users instead of having to instruct a user about what to do, how to go about doing it. The administrator can just say, “Okay, let me just send that to you,” rather than trying to explain something to maybe a user who’s just a subscriber or a user who is a student in a learning management system, to basically get that lost password link to them so that they can go ahead and reset that password.

Kathy:
But obviously that send password reset link is going to be in several places, and with anything that sending to a user, there’s a potential if that site ever is hacked that that could trigger something that an attacker could use to basically trigger a user to perform some actions.

Ram:
I mean, I’m not really worried about that. WordPress now has fairly strong cross-site request forgery protection. I think, realistically, the only potential problem we could see is that now there’s this expectation that you could get a legitimate password reset email sent by an administrator without asking for it. So, I mean, it’s conceivable that these could be spoofed and used in phishing attacks.

Ram:
You send someone something that looks like a password reset link and say, “Hey, I’m the administrator for your site. It looks like your password might’ve been compromised so I’m sending you this link,” and then get them to fill it in on a phishing site. There’s still some caveats with that, where if they log in with their new password and find it doesn’t work, will they then reset it again to the same password? I mean, I could see this being abused. I could see it being fairly difficult to abuse, but there’s always the potential.

Kathy:
Sure. Mostly we just want people to know that this new feature exists, and with any new feature that shows up there’s the potential for it to be used in a unique and never-seen-before way, so just to be aware that that feature exists. That if a password link shows up in a user’s inbox, that that user should definitely look at that if it’s unexpected and investigate further before they go haphazardly clicking links and traversing the internet, right?

Ram:
Yeah. I mean, it’s just like receiving a weird request, like something that could be a spear phishing request in your company email inbox. If you get a request for something that you weren’t expecting from someone, just verify with them via another channel. If you get a password reset link from an admin, maybe you get in touch with them and say, “Hey, did you send this on purpose?”

Kathy:
Exactly. All right, let’s move on. Let’s look at this botnet that we saw abusing Bitcoin blockchains to stay in the shadows. Now, Bitcoin is crazy in the news.

Ram:
Your favorite. That’s your favorite. I know it is.

Kathy:
It’s everywhere. Everybody’s talking about Bitcoin. I mean, when an asset performs in ways that people weren’t expecting or predictable ways, everybody starts talking about it. As soon as cryptocurrency starts increasing in value, we start seeing attackers trying to leverage any technology they can in order to either mine that cryptocurrency, to ransomware people out of cryptocurrency. It just becomes another way that we see attackers trying to monetize attacks, right?

Ram:
Yeah.

Kathy:
What are we seeing with this one?

Ram:
Okay, so one of the things about the blockchain is that effectively, it’s an immutable record of things that have happened. This is actually kind of interesting. The botnet that was using it as actually a skid map malware, which is actually used for mining other cryptocurrency. In this case, Monero, which is popular amongst threat actors, because it’s untraceable or at least it really hard to trace. And by the way, these guys aren’t actually doing a great job. Apparently, they’ve mined like $30,000 in Monero, which is not really a lot considering.

Kathy:
Yeah, come on.

Ram:
Anyways, it looks like what they were doing is the malware that was looking for C2 instructions … So here’s the thing about command and control systems, it’s they’re really easy to disrupt. If your malware is asking for new instructions from so-and-so domain or so-and-so IP, then it’s fairly easy for the hosting provider or the domain registrar to take those down at the request of governments or security researchers once they figure out there’s something malicious happening there.

Ram:
So, a lot of malware that relies on this command and control infrastructure needs a way to figure out, okay, where should I ask for instructions next, because of my current instruction feed has gone down?

Ram:
What they did was they basically added an algorithm that looks at a particular Bitcoin wallet and checks how much had been sent to it, and it used that number in Satoshi’s, which are, I forget if it’s a hundred thousandth of a Bitcoin, but very small amounts of money. It uses that number and basically breaks it up and parses it into an IP address, and that IP address is the IP address of the next server they should check.

Kathy:
That’s crazy.

Ram:
Yeah. Since it’s pretty much immutable, you can’t really shut it down, but what you can do is you can send money to that and mess up the IP address.

Kathy:
Hack the hackers.

Ram:
Pretty much. And that’s cheaper than fixing the IP address back to where it was, but the attacker probably controls that wallet. Giving them money seems like a not great way to get them to stop, especially if they can just give themselves more money to undo what you just did.

Ram:
I think we’ll be seeing a lot more of this in the future, just because it’s a novel command and control method. We’ve seen this in Twitter feeds. We’ve seen this in Instagram feeds. We’ve seen all sorts of C2 methodology happen in the past few years that’s just kind of wild.

Kathy:
Yeah, interesting, because whatever is written into the blockchain, it’s there. It’s not something that can be erased or undone, it’s just there. This’ll be interesting to watch and see how other people are using blockchain technologies in novel ways to, I don’t know, be stinkers on the internet, I guess.

Ram:
Pretty much.

Kathy:
Yeah.

Ram:
Speaking of stinkers on the internet, it turns out there was a VMWare bug, a critical remote code execution bug in all default vCenter installations. So, vCenter server is basically a central management solution for virtual machine hosts.

Kathy:
Okay. So kind of like ManageWP would be for WordPress, this is for a centralized server for VM hosts, right?

Ram:
Kind of, yeah. Yeah. Basically, it manages all the virtual machines in an organization’s network that they’ve set it up to actually use virtual machines. Anyways, the vSphere client, basically it had a remote code execution vulnerability. It was in one of the vCenter server plug-ins related to something called vRealize operations, but the thing is it was vulnerable even if you weren’t using that particular plugin.

Ram:
An attacker with network access to port 443, which is just the standard SSL port or TLS port, could exploit the issue to execute commands with unrestricted privileges on the underlying operating system that hosted the server, which would probably give them control of all the VMs it was managing, too. Which, for some organizations, would be all of their servers. Apparently, they’ve already seen this being attacked in the wild in several thousand vulnerable servers exposed on the internet. So yeah, I feel bad for those organizations. If your organization is running this, then please update.

Kathy:
Yikes. That just sent chills down my spine. Very, very frightening. So definitely update if you have anything going on with VMWare and vCenter server. Scary.

Ram:
If you’re managing multiple VM hosts using vCenter server, then this is definitely something to be aware of. If you’re just on a desktop or running VMware to run a virtual machine, you’re probably okay. I mean, you’re definitely okay, but yeah.

Kathy:
Wow. Well, it looks like Android users now have an easy way to check password security. What’s going on with this?

Ram:
I don’t know if you’ve heard of Have I Been Pwned-

Kathy:
I have.

Ram:
Which is a online service that you can use to see if your password has been exposed in any data breaches. Which is a really good thing to do, because so many data breaches are the result of passwords exposed in other data breaches, that it’s just not even funny anymore. So yeah, use a password manager with unique passwords for each service you use, please.

Ram:
Anyways, this works really similar to Have I Been Pwned. It basically uses cryptography to ensure that the password checking service never gets your password that you’re checking. Not even just the hash of the password that you’re checking. Which, if you want to know more about password hashes you can listen to our previous podcast and our Wordfence Live show on encryption.

Ram:
Anyways, basically what it does is phones or device sends the first part of the hash of a password to the service, and the service sends back an encrypted set of breached hashes and it compares them without either side ever knowing the full hash you’re checking or the full hash of the breached passwords. It’s pretty cool. If you can turn it on, please do, because that way it’ll let you know if you’re using a password that’s been breached in any of your Android apps. And most of them, if you’re not signing in directly with Google or Facebook OAuth, you probably have an account set up with a password that you’ve probably used somewhere else, too.

Ram:
I remember I got breached in the GrubHub breach a while back because I was reusing a password for that, so this is kind of important.

Kathy:
Very important. So this is resident within all Android phones.

Ram:
If you’re up-to-date, yeah.

Kathy:
It’s a project by Google. Let this be a reminder to you that you should be using a password manager. Most of the major password managers, they have both a desktop as well as a phone, iOS or Android version, and always kind of these tools have ways of letting you know that you are using passwords in multiple places, password checkups, types of features. Always good to have this running in your apps, as well, just across the board. You can’t just have the one password anymore.

Kathy:
Hey, do you want to hear the worst story? One of the first companies I ever worked at in the networking department, and one of our server passwords was Flowbee.

Ram:
Oh gosh. It sucks, and it cuts.

Kathy:
It sucks and it cuts. That should have not been a password, but back in the day you could reuse passwords and do dumb, funny things like that. No longer.

Ram:
No longer.

Kathy:
Yeah. So, let’s talk a little bit about this article you found, Ram, about data breach fatigue. What does that mean, and what does it mean for … I mean, you and Chloe and our threat intel team are constantly finding vulnerabilities and working with plugin developers, theme developers, anybody in the WordPress space, helping them to patch their code and to write more secure code. But then, of course, there comes a point once that’s patched and once firewall rules and updating has occurred, you have to publish details about what you found for educational purposes, for keeping your certifications up. And a lot of, I think, plugin developers and whatnot, is it painful for them when you guys are publishing?

Ram:
We have heard some concerns expressed that publishing the vulnerability will reduce the plugin’s market share. And, you know what? We have seen that happen in the very short term, but they almost always recover. Even the File Manager vulnerability, the one last year-

Kathy:
Yeah, that was a bad one.

Ram:
That was really bad. That was hugely impactful. That was almost a worst case scenario in everything except how they handled it. They handled it pretty quickly, but it was already a zero-day. It was already being exploited by the time it got found out and it had a lot of installations and there were a lot of sites impacted by it. Our site cleaning team is still cleaning sites that were impacted by that and didn’t have Wordfence at the time.

Ram:
So, yeah, it was a huge thing. And you know what? Their install growth dropped. It went negative for about a month and a half, and then it came back. The growth is not back to where it was, but the install count is right where it was, and growth is still positive and growth went positive again about a month and a half after it got disclosed. So, yeah, if you’re worried about the impact of vulnerability in your plugin, don’t be. It’s much better to fix it than to have people impacted and to not fix it.

Kathy:
Right. Well, there’ve been some major … I mean, Target. When was that? 2013 when Target had all of their point-of-sale cash registers basically compromised and credit card data was compromised. I didn’t stop shopping at Target, and Target’s recovered quite well. It didn’t ruin them completely, right?

Ram:
Yeah. IBM’s done some research on the cost of a data breach report, and I mean, yeah. This is outside of the WordPress plugin ecosystem, mind you, so this is a completely different context. If you’re talking how much a database breach costs a large company, enterprise sector can expect an average bill of like $3.8 million, and some of them can rise up to like $392 million to actually remedy the breach.

Ram:
But they did a study on the stock prices of companies that disclosed breaches, and back in, say 2013, there was a massive impact, but even in 2019 stock prices would drop by like maybe 7% after a data breach was disclosed. Now, it only drops by like three and a half percent. So people are getting used to data breaches just kind of happening as a cost of doing business. That doesn’t mean they shouldn’t be addressed, because they absolutely should. If they’re not addressed, then that leads to much more severe long-term consequences.

Ram:
It only took like a 100 days for prices to recover, apparently, according to this research, and general performance was only slightly poorer in the six months after a breach. So, breaches happen. Address them, fix them, take precautionary measures if you can, but the response is really one of the big things that matters.

Kathy:
Right. Well software, to me, and I think to all of us, is about trust, right? Your WordPress site, you are trusting that a plugin developer has done a good job creating not only the functionality, but the security of that code and you trust it so you install it on your site. Trust comes in a lot of different ways, right? So if you have a vulnerability and you patch it and you don’t disclose that you’re patching it, or you don’t disclose what’s happening in the next version of a site, or you don’t disclose that something might have gone wrong, that destroys trust. That secretism … That’s not the right-

Ram:
Secrecy.

Kathy:
Secrecy, that’s the word.

Ram:
Trying to hide stuff, being sneaky and shady, and “No one will ever know that I was breached.” Yeah, that’s also … In a lot of cases, the law requires you to disclose a breach. If you don’t actually take appropriate action, that’s when you run into trouble. I mean, it’s still expensive. Transparency is good.

Kathy:
Transparency is the best. So when you’re evaluating a plugin to put on your site, that’s a factor that goes into, “Am I going to install this on my site? Do I trust this developer?” You go look at their change log, and if they’ve had a celebrity bug known as a vulnerability … Mark likes to call them celebrity bugs. If they’ve had it, how did they handle it? Did they disclose that in their change log? How was it fixed? How did they work with security researchers that may have disclosed it with them? If there was a zero-day in the past, how did they handle it? You make your evaluations of whether or not you trust someone based on how their past performance has been when they’ve had to deal with anything. Celebrity bugs, functional problems? That transparency really says a lot about a plugin developer. So it’s, I think, a factor when you’re evaluating a plugin.

Ram:
It really does. If you see in someone’s change log, at least look for security issue fixed. If the change log has never fixed a security issue, then I don’t know if I would trust a plugin that’s been around for a while and never fixed a security issue.

Kathy:
Right. Everybody has celebrity bugs at one point or another, don’t they?

Ram:
Pretty much, yeah.

Kathy:
So it’s just how do you handle those issues and how do you communicate about them, which is critically important. To all of the security researchers out there, and to all of the plugin and theme developers who we work with, we’re just really excited when we see plugin developers who have a security policy on their site. Makes it very easy for us to contact you. That you work with us, share information freely so that we can help you get things fixed quickly. Proof of concepts, all of that fun stuff is incredibly important in this disclosure process.

Ram:
Yeah. If you have a security contact, that means that we can send you the full disclosure right away instead of having to go through your support department and having to wait 24 to 72 hours for them to get back to us and say, “Okay, yeah. This is totally the right place to send security issues,” or, “No, here’s who you should send it to.” So that could save you one to three days in fixing something.

Kathy:
Right. And the faster you get it fixed, the faster and better it is for your customers. That’s all I’ve got, Ram. How about you?

Ram:
That’s all I’ve got. It was great chatting with you again, Kathy, and I will see you next week.

Kathy:
See you next week. Thanks, Ram.

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.

The post Episode 106: Admin Password Resets, Blockchain Botnets and a Central Management RCE appeared first on Wordfence.

Read More

Episode 104: Cryptography Demystified

This week, the Wordfence team discusses cryptography in depth, including the basics, a brief history, hashing, and the Crypto Wars. We also go over current news, including 2 new findings by the Wordfence Threat Intelligence team, a new milestone for WordPress, and a recent attack on a Florida Town’s water supply.

Here are timestamps and links in case you’d like to jump around, and a transcript is below.
0:17 New findings by the Wordfence Threat Intelligence team
1:08 New Milestone for WordPress
2:40 An attack on a Florida Town’s water supply
5:52 Introduction to Cryptography
7:49 History of Cryptography
13:45 The Crypto Wars
24:30 Hashing
37:26 Symmetric Cryptography
39:26 Asymmetric Cryptography

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 104 Transcript

Ram:
Hello, and welcome to Think Like a Hacker, the podcast about WordPress security and innovation. I’m Ram Gall, threat analyst and QA engineer at Wordfence, and with me is our CEO Mark Maunder. How’s it going, Mark?

Mark:
Pretty good, Ram. How are you doing?

Ram:
Not too bad. It’s been a long day, but I feel like it’s been pretty productive.

Mark:
Yeah. Didn’t you just find a bug?

Ram:
Actually, Chloe and I both published a couple of critical vulnerabilities in some fairly popular plugins. Chloe found a couple of file upload vulnerabilities that could be used for remote code execution and the responsive menu plugin and a CSRF settings update. I also found a couple of CSRF… That stands for cross-site request forgery, it’s where you trick someone into clicking a link, and then the attacker can basically make them do whatever they want on their own site.

Mark:
Very cool. Vulnerabilities, which are really just celebrity bugs, right?

Ram:
Pretty much. Yes. I mean, they’ve gotten a decent amount of coverage. Mine was in NextGEN Gallery, which is a fairly popular image plugin for WordPress. It also allowed file upload, but yeah, I think we’re doing some good research. We’re keeping up the pace in the new year.

Mark:
Yeah. Most definitely.

Ram:
Something else that came up is that WordPress now officially accounts for 40% of the top 10 million sites on the internet, according to a new study by W3 Technology Surveys.

Mark:
I remember, I think it was earlier today, our team was chatting about that. I was just remembering what that 40% number means. I guess it’s the top 10 million as defined by… Was it Alexa combined with some other lists or cross-referenced?

Ram:
Yeah. Yeah. It was mostly the Alexa top 10 million. They’ve been keeping track of internet statistics for quite some time now, so.

Mark:
Yeah, but I mean, Alexa, not to go and excavate this from ancient history, but they used to have really accurate traffic on sites based on a browser tool bar that was in… I think it was like back in IE6 or something, and then those toolbars went away, and somehow they still have data. I’m just curious how accurate it is.

Ram:
Apparently, they’re fairly well-trusted by most of the organizations that do internet research, but it would be fun to look into at least.

Mark:
Yeah, for sure. One of my favorite resources is BuiltWith that we’ve been playing with, and I think you might’ve as well.

Ram:
Yeah. Yeah. I’ve played with BuiltWith a little bit. It has given us some interesting data on some topics that we’ve been researching, like nulled plugins.

Mark:
Definitely.

Ram:
But we don’t want to get too far off of track, but we’re going to be discussing one of the most important technologies to the internet’s continued existence today. We’re going to be following up on our Wordfence Live show this week. Just wanted to cover one of the biggest things in the news this week, which is that an attacker gained access to a computer controlling the water treatment plan for Oldsmar, Florida. I guess they tried to dump a bunch of lye into the water supply.

Mark:
Yeah, I commented about that on Twitter, but I don’t know about you, Ram, but I don’t remember a kinetic attack that targeted civilians that has had this much impact. When I say civilians, I’m thinking of Natanz, the Iranian uranium refinement plant that was targeted by the U.S. military cooperating with the Israelis. I also think about the Israeli F-15s that targeted a facility after the Israeli cybersecurity team disabled the radar system that would have detected the attack.

Mark:
Those things have happened, and they’re kinetic and they’re exciting and that kind of thing, but this is hackers going after a civilian facility dumping orders of magnitude more lye in the water supply than should be there and an operator seeing it actually happen and catching it just in time, which is very lucky, I think.

Ram:
Yeah, well, they were using TeamViewer, weren’t they? Apparently, this was a fairly low-sophistication attack. They believe that it was credential stuffing that lead to it.

Mark:
Oh, wow. No, I didn’t read the details on this. What is TeamViewer exactly?

Ram:
TeamViewer is basically a remote desktop management application, something where if you want to help someone out on their computer, you can get an invite to take actions on their computer using TeamViewer. It’s a lot like remote desktop Microsoft bundles, or with Windows server.

Mark:
Some attacker… and you said it was credential reuse?

Ram:
That’s the running theory. Yes.

Mark:
Oh, wow. Oh, man. I think that’s by far the most common vector for just about everything these days is password reuse, something gets breached, the list of hashed passwords gets out on the internet, someone cracks the list or as many of the hashes as they can, they make it available to everyone else, and you’ve got the username/password combination, and the username’s usually an email address, and so once that’s out there, they just reuse that credential somewhere else and get in, and Bob’s your uncle, huh?

Ram:
Pretty much. Yeah. That’s one of the reasons why cryptographic salts are so important, which is something we are actually going to get to a little bit. Apparently, the operator caught it because the attacker moved the mouse. That’s kind of eerie if you see your mouse moving on your screen and you’re not the one moving it. I feel like that speaks to the relatively low sophistication level of the attacker.

Mark:
I just hope it wasn’t some kid. Was this done in Florida where this happened?

Ram:
Yeah, this was in Florida.

Mark:
Oh, man. There’s something about Florida. We have a mutual friend who you know of, and we’ll chat about that after the podcast, but he got prosecuted when he was much younger for making silly choices and going after government websites. I hope this isn’t the same thing, some teenager who’s gone exploring and made some really bad choices because it’s not going to turn out well for them.

Ram:
Definitely not, especially not with something that could have impacted that many civilians.

Mark:
Yeah. Yeah. For sure. All right. Should we talk crypto?

Ram:
Yeah, let’s talk crypto. I guess the question is what is cryptography?

Mark:
Just some background here, as Ram was saying, we had a really nice chat on Wordfence Live, which feels like it was last week for both of us because so much has happened since then, but it was actually yesterday morning on Tuesday morning. We’re recording this on a Wednesday evening, February 10th. Wordfence Live is every Tuesday around… Is it 9:00 a.m. Pacific, Ram?

Ram:
I know that it’s noon Eastern, so.

Mark:
Yeah. Yeah. All right, so 9:00 a.m. Pacific, we did a segment yesterday on cryptography, and we wanted to do that on the podcast as well. I’m going to condense this so that it’s a little bit less in-depth and kind of like a compact introduction to cryptography for most folks. If you’re a little more technical, I suspect there’ll be some fun items in here for you as well.

Mark:
But my goal here is really to get our listeners thinking about cryptography in a way where they have an understanding of some of the basics. By the basics, I really mean where cryptography comes from, why it’s useful, the history of the crypto wars, what is a hash, what symmetric cryptography, what is asymmetric cryptography, what is key escrow and why is it problematic? Then we’ll talk about the future.

Mark:
If you are less technical and you’re listening to this, I’m going to make this as accessible as I possibly can. Some of those words that I threw out might sound a little bit intimidating, but they’re not. They’re actually fairly easy concepts, and you don’t need to be a mathematician to have some fun with this stuff. I think once you’ve got a basic understanding of what these various things are, you can then listen to news reports about the evolution of policy with regards to privacy and cryptography and even things like blockchain with more of an educated ear. That’s my goal here. I suspect that’s yours too, Ram.

Ram:
That is. Should we dive into the history a little bit?

Mark:
Yeah. Why not? I guess we can go back to the Caesar cipher, which is one of the earlier forms of cryptography, and chat about that. The Caesar cipher, it’s a really basic form of crypto that is just shifting letters by a fixed number, so-

Ram:
ROT13, right? The thing-

Mark:
Exactly.

Ram:
… that people always used to post spoilers on the internet.

Mark:
Yeah, exactly. Now, in the case of ROT13, what they’ve done is they’ve said every letter becomes the letter that is 13 places away. I think A is probably… Is it M or N? B as the next letter on after that. Maybe A becomes M, B becomes N, and so on. When you get the message, all you do is you reverse the process. You shift it 13 letters back or two letters back or whatever you’ve agreed on. What’s interesting about that kind of algorithm is that it’s cryptography where you have a shared algorithm, and all an algorithm means is just a piece of logic.

Ram:
It’s just a way of doing stuff. It’s the way of performing operations, right?

Mark:
I like that. I actually like that better than a piece of logic. It’s a way doing something. In early cryptography, it was a shared algorithm. I’m shifting it forward by 13 spaces, and you’re shifting all the letters back by 13, for example. Then you had other early forms of cryptography, like the scytale where you had a… It’s kind of like a belt, if you can imagine like a belt that you would use to hold your jeans up when you’ve lost too much weight. You wrap a belt around a cylinder so that it covers the whole cylinder, and then you write your message on that. When you unwrap it, what will you see as a bunch of letters when you’re looking at the belt, and it doesn’t really make much sense. The way you decode it is you just take the belt and you wrap it around a cylinder of the same diameter, and you can end up actually seeing the message.

Mark:
Again, it is a shared algorithm that the two people have. I know that I need to wrap the belt around a cylinder of 100 millimeters in diameter and you receive the belt that the courier has transported across the country on their horse avoiding the enemy, and you know that you need to wrap it around a cylinder of 100 millimeters in diameter. We share that logic, and there you go. One of the first kinds of cryptography where it was no longer a shared algorithm or a shared piece of logic, but they actually separated the logic or the algorithm from the key was… What the heck’s it called, Ram?

Ram:
Vigenère cipher. Yeah. That was the one where they basically used every Caesar cipher in a sort of table, right?

Mark:
Exactly. Yeah. Yeah. Vigenère was the first cryptographic algorithm or method that had logic. It also had a shared key between the sender and the receiver. The key is you plug that into the table, as Ram was saying, and you can then decode the message. What’s interesting about that is it begins to introduce this concept of Kerckhoffs’s principle, which is that for any good cryptographic algorithm, that algorithm should… You should be able to make that completely public and make it available to your adversary, your enemy, or the other team, and it doesn’t matter if they have the algorithm as long as they don’t have the key.

Mark:
That’s the importance in cryptography of separating the algorithm or the logic from the key. Kerckhoffs’s principle is used still today by the NSA, and the inside joke at NSA is that if we produce a device that does cryptography, the very first device, the one with serial number one is sent to the Kremlin. What they’re really doing is just illustrating this idea that you can have the device or the algorithm or the logic as long as you don’t have the key. If you have the device or you understand the logic or the algorithm or the math, it doesn’t help you as long as you don’t have the key to unlock the cryptography.

Ram:
Most of the really strong ciphers we use today are very public, aren’t they?

Mark:
Yeah.

Ram:
Like I’m sure the NSA has a few in their back pocket that they’re not sharing, but most of the ones that are considered extremely secure, the algorithms are all public.

Mark:
Exactly, exactly. I mean, it used to be that they try to keep these things trade secret. You know, RC4 was actually a trade secret until it was, it was leaked on a cypherpunk forum. Cypherpunks are, are hackers that are interested in cryptography. But RC4 was actually leaked and it eventually became, you know, public knowledge and so on.

Mark:
But these days when cryptographic algorithms are developed, they’re generally made very public based on Kirchhoff’s principle and debated to death among mathematicians and pounded upon until they’re like, okay, we’re at a good place where it doesn’t matter who knows the algorithm. As long as they don’t have the key, it’s as secure as we need it to be. I’m not using the word unbreakable on purpose for reasons that I’m- I’m, Ram, I’m sure you understand.

Ram:
Schneider said that usually when the NSA tries to break these things, they don’t try to actually break the math. They just try to break the implementation. Right? And that’s, that’s-

Mark:
Yeah.

Ram:
… where it’s usually easiest to go wrong. It’s much easier to find some sort of side channel of like, oh, hey, this chip leaks way more power when, you know, the first few bites are zero of the, of the key-

Mark:
Yeah.

Ram:
That kind of thing.

Mark:
Yeah, exactly. I think sometimes the math is vulnerable. But most often you’re able to target cryptographic algorithms using side channel attacks much more successfully.

Mark:
All right. So we’ve chatted about the, the sort of brief history of cryptography. I’m going to bring us into roughly the seventies.

Ram:
The height of the Cold War.

Mark:
Right? So around the 1970s, in my opinion, and other folks will disagree with me, the, what we call the crypto war started. And that’s where the US government, and the NSA in particular, were doing their best to make cryptography unavailable to the general public and to their adversaries, like other countries and so on. And, you know, as we’re, we’re obviously at the height of the Cold War there. And so the, the big adversary for the US was Russia.

Mark:
And so one of the events that I, I think clearly illustrates the, the Crypto Wars is that IBM in the 1970s was developing DES or the digital encryption standard and they wanted to use 128 bit key. Now in cryptography, the longer the key you use, generally, the more secure the, the cryptography is, the harder it is to break. And so IBM wanted to use 128 bit key.

Mark:
And when I say 128 bits, if you don’t know binary, it just defines the length of a number. And you can have numbers in binary or hex or octal or decimal. In this, in, you know, most cases, that’s what we’re used to. But in binary, 128 bit key is just a number that is 128 binary digits long.

Mark:
And so IBM wanted to use 128 bit key. And the NSA started lobbying them to only use a 48 bit key because they wanted the digital encryption standard that IBM was developing to be more easily breakable. They didn’t want secure cryptography to be available to the general public and to IBM customers, including customers that were overseas. And what they settled on is a key length of 56 bits, which was vulnerable at the time to brute force attack, and to being broken. And, and so that’s kind of the, one of the earlier events.

Mark:
And if we fast forward to 1991, you saw something similar happen where Phil Zimmerman released pretty good privacy, which was an implementation of a public key encryption. And I’m going to explain what that is in a few minutes. but what that did is it made very strong public key encryption available to the general public. And, and he actually used 128 bit encryption. If you remember, the longer the key, the more secure it is.

Mark:
And they actually went after Phil and they tried to prosecute him. And eventually they kind of dropped the case. But what happened was Phil was not able to legally export pretty good privacy because it fell under the ITAR regulations at the time, which were the regulations that export munitions. And strong cryptography was considered ammunition by the US government, the same as missiles and so on.

Mark:
And so he could only export a weak version of PGP. But with the way they got around it eventually was Phil partnered with the MIT press. And they actually printed out the entire source code of PGP as a hardcover book. And you could buy that book and you could take it overseas. And the reason you could do that is because it was protected speech under the First Amendment of the US Constitution. And so they actually managed to export it that way. Someone took the book overseas, they yanked off the cover and they used optical character recognition to scan the code back in and they compiled it. And they had strong encryption that had legally been exported from the US. And that was around ’91.

Mark:
And then just a little, little later that decade, around the mid nineties, Netscape implemented SSL in their browser. And they, because of the ITAR regulations, they had to provide weak cryptography to international users of their browser.

Ram:
That seems like a terrible idea for e-commerce,

Mark:
Right? So Netscape only allowed 40 bit encryption internationally. And you could have 128 bit encryption if you’re in the US. And what the- what happened is Verisign, at the time, was selling all of the SSL certificates. And they were selling 128 bit certificates to US customers and 40 bit for the rest of the market. And a little company in South Africa, where I’m- where I come from called Thawte, which was started by Mark Shuttleworth, started selling 128 bit SSL certificates. Because they could, because they were not in the US, and they were not governed by the ITAR restrictions.

Mark:
And so Mark and, and Thawte cornered the, the other half of the global market in SSL certificates and Thawte ended up owning 50% of the market and Verisign owned the other 50%, which was in the US. And eventually the ITAR restrictions were, were lowered. Verisign bought Thawte for just under 600 million US dollars. And Mark became a very wealthy person and became the second space tourist ever. And then used his hundreds of millions to launch Ubuntu, which is a Linux variant. That is, I think, Ram, the most popular Linux flavor these days?

Ram:
Uh, by quite a bit, I believe. Yes.

Mark:
Yeah. And Ubuntu’s actually brilliant. I mean, everyone uses it, who, who is, uh- everyone sensible uses it. (laughs) No, I’m just kidding. I’m going to get, I’m going to get killed by some of our listeners. Cause there’s a, there’s a lot of other great Linux flavors out there, including Kali, which is used by us penetration testers and security researchers. So lots to choose from. But Ubuntu is, is huge and has made a huge contribution.

Mark:
And that’s the, that is how Ubuntu came about. And you can thank the, the US government and their restrictions on exporting strong cryptography for helping bootstrap Ubuntu Linux into existence.

Mark:
And then, you know, we’re still chatting about the Crypto Wars, right? I mentioned IBM in the seventies, you know, Netscape and the story of Mark Shuttleworth and Thawte and so on. Well, the Clipper chip was developed by the National Security Agency in the 1990s. And that included the, Ram, I think he told me about the Skipjack algorithm.

Ram:
Yeah. I remember there being a controversy about the Clipper chip as well.

Mark:
Yeah. So Clipper included what they call a key escrow, which is this absurd idea that the- a government, in this case, the US government, should hold a key that is a back door to a certain kind of cryptography. And so Clipper was supposed to be used in all phones, cell phones, landlines, that kind of thing. And it would give you the illusion of secure communications. When in fact, someone out there has a key. In this case, it’s the US government. And the idea is that they’ll be able to keep that key secure.

Ram:
They would never ever lose it. Right? That has never happened.

Mark:
Right.

Ram:
Right?

Mark:
Right. Well, so the a- if, if you know anything about the OPM breach, the office of personnel management, which is a division of the US government, holds files on everyone in the country who has clearance.

Mark:
Clearance, if you’re not a, a US person means that you can look at secret government stuff. And there’s various levels. There’s secret, top secret, top secret SCI and so on. And so if you work on a military base in this country, you generally have clearance of some kind, and there’s a process that you go through. They attach a polygraph to you and they ask you a bunch of awkward questions. And there’s a process called adjudication where you’re supposed to tell them that you’re, you know, an alcoholic who dances every midnight when it’s a full moon around the streets naked. And you’ve done all this other naughty stuff. And that way they’ve got all your naughty stuff on file. And no one can blackmail you saying, well, I’m going to tell everyone about the naughty stuff, unless you tell me the government secrets.

Mark:
And so OPM had that data on file along with biometric data for all of these folks with clearance, like fingerprints and so on. And that was breached. And it’s an absolute disaster. In my opinion, it’s one of the most important breaches in the history of this country, anyway, because you don’t get a lot of that data back. And you can’t change a lot of that data. You know, if it was passwords that were breached, sure. You know, change your passwords, no big deal. Biometric data is a password that you can never change unless you somehow are able to change your fingerprints or your, your iris. Uh-

Ram:
It should be a username really.

Mark:
(laughs) Right. And yeah, that’s an interesting idea actually. And then, you know, the adjudication data is obviously very, very sensitive data and, and that’s now out there. And so if, if they couldn’t protect the OPM’s data, the idea that they would be able to protect a key that has- that they’re storing under key escrow is utterly absurd.

Mark:
And it just really highlights the need for strong cryptography that isn’t back-doored in my humble opinion. Ram, what do you think?

Ram:
I definitely agree. I feel like back door crypto is a disaster waiting to happen because as soon as that happened, that escrow key is going to become the number one target of literally every adversary and every light crime syndicate, and everyone who has good hackers who-

Mark:
Right.

Ram:
… aren’t interested in the public good.

Mark:
Yep. That’s right. Giant bullseye. And so, you know, the Crypto Wars are still going on. We have a, an act that is the EARN IT Act of 2020, and it provides for a 19 member national commission, which will develop a set of “best practice guidelines” to which technology providers will have to conform in order to “earn immunity” to liability for child sexual abuse material that’s been posted by their users on their platforms.

Mark:
And the thing about that is that earning immunity probably means providing back doors into things like end to end encryption if you’re providing a service like WhatsApp or Signal. And WhatsApp is relevant because it’s owned by Facebook. And so if Facebook wants to “earn immunity” from people posting illegal material to Facebook, they would have to conform to the EARN IT act and potentially back door WhatsApp.

Mark:
And just to be clear, traditionally, content providers, social media platforms, that kind of thing have had automatic immunity thanks to Section 2-30 of the Communications Decency Act. And so they’re kind of like rolling that back and providing a way for the US government to put tremendous pressure on platforms and social networks and so on to back door their cryptography with the threat of well, we’ll prosecute you for child pornography content that is posted onto your platform.

Mark:
And, and so the way that they framed this is this kind of choice between the safety of children or strong cryptography. And it’s a false, it’s a false choice in my opinion.

Ram:
There are very, very, very many legitimate uses for a strong cryptography. Honestly, I feel like it’s a much stronger argument, even than the old VCR debate. If you recall, the main reason VCRs were allowed to have a record functionality is that there were legitimate use cases that weren’t copying copyrighted material, even though that’s what most people use them for.

Mark:
Yeah, yeah-

Ram:
Whereas with cryptography, almost all of the use cases are legitimate, and the illegitimate uses are edge cases.

Mark:
Yeah, exactly. I would say it’s the inverse of that; I totally agree. All right, so let’s dive into some educational stuff over here-

Ram:
Yeah, you were going to talk about hashing, right? Which is pretty big on the blockchain. It’s kind of the thing that makes that work, but-

Mark:
Yeah, so let’s start off with hashing as you suggested Ram. It’s one of the easier concepts. A hash is simply a machine that you can feed data into of any length, it that can be just a single byte or it can be a petabyte, which is a lot. And at the other end, it’ll spit a fixed length number that’ll uniquely identify that data. If you feed the same data and again, you get exactly the same number, and that’s it. Now you know what hashing is.

Mark:
And hashing is super useful for all kinds of things. I was teaching my colleague in our film department the other day about hashing, because what he can do is take a huge film, a complete film that is multiple gigabytes, run it through a hashing algorithm on his Apple computer, which includes the MD5 hashing algorithm, he can get a hash that represents the data. He can then send that huge file via courier, or via network, or via pigeon to the visual effects company that he’s going to be collaborating with, and when they get it, he can also just email them the hash, they’ll run it through the same algorithm, and if it doesn’t generate the same hash, it means the data has been changed in transit; it’s been corrupted, or someone has added a scene into the film that we don’t want-

Ram:
Or the NSA has tampered with the film.

Mark:
Right. For some reason, I thought of Fight Club. If they had hashing then Tyler Durden wouldn’t have been able to put his little little hidden frame into the films, but let’s not go there. This is a family podcast, and we probably shouldn’t go into that territory.

Mark:
But that’s the basics of what hashing is. And it’s used in cryptographic algorithms or crypto systems all over the place to uniquely identify data. And hashing is also used for authentication. So when you register on a website, what it does is you enter your password, it creates a hash of that password to uniquely identify it, and it stores that hash. And the next time you sign in it just hashes the password that you enter again-

Ram:
But not with MD5 anymore?

Mark:
Well hold on, you’re getting ahead of me here. So it hashes your password again, and compares that output with the hash that it’s stored, and if the two match, then it lets you in. And the benefit of doing that is you don’t have to store a plain text password in the database anymore. You can now just store a representation of that password.

Mark:
And the thing about hashes is it’s very difficult, and in some cases impossible, to reverse that hash back into the original data. And so that’s the basic idea there.

Mark:
Now, if you wanted to crack passwords, because you’ve managed to, let’s say hack into some WordPress website and you’ve downloaded all the hashes, and you want to turn them into passwords, well the way you do it is you just take a whole bunch of words, turn them into hashes, compare that list of hashes you came up with the list of hashes that you stole, and ones that match, well now you know what the password is because you used that password to create that hash, and it matches a hash in the database, and so it must be the same word that they’ve used.

Mark:
And so this begins to help you to understand why you want to choose a long password that is not an English word, or made up of English words, and that contains random characters, and that those characters should be upper and lower case, and numbers, and some symbols. Because if I’m trying to crack your password by throwing a dictionary at a hashing algorithm-

Ram:
You’re going to try the easy ones first, right?

Mark:
I’m going to try to use the ones first. And I’m going to try dictionary words first. If I have to do, let’s say 20 character passwords that are completely random, it’ll take me the rest of my natural life multiplied by a thousand to actually crack your password.

Mark:
Some hashing algorithms are a little more computationally-intensive than others, and those are better for this particular application, which is storing hash passwords.

Mark:
Now, crazy story, right?

Ram:
Yeah, yeah.

Mark:
I’m going go on a tangent over here Ram just for fun. This is not something we chatted about on Live yesterday, and I wish we had.

Mark:
Adler-32, does that sound familiar?

Ram:
Yeah, that’s the CRC, cyclic redundancy check algorithm, right?

Mark:
Yeah. And Adler-32 now, the reason I want to go on this tangent is I was saying that if you’re using a hashing algorithm for storing representations of passwords, you want to use something that does actually consume quite a few CPU cycles when you’re generating the hash, because it’s harder to crack. If you do a thousand guesses with that algorithm, it’s going to take a lot longer than with, say MD5, which is incredibly fast.

Mark:
But Adler-32 is funky. It was designed by Mark Adler. He worked at either JPL or NASA at the time, and it was designed for spacecraft. And that is an algorithm that’s designed to not be computationally intensive, because it’s running on a spacecraft that has a limited amount of power available. It’s running off solar cells, and you don’t want to consume a huge number of CPU cycles, and therefore watts when you’re using this algorithm.

Mark:
So it’s actually a very computationally-efficient algorithm. And Matt Barry, who’s our lead developer, our most senior developer here at Wordfence, he discovered a weakness in the wordpress.org infrastructure that would have potentially allowed an attacker to compromise the servers where you download WordPress from, and that send out the plugin updates and all that stuff. And the mistake that they had made is they were using Adler-32 for a certain, I think it was authentication or authorization step.

Ram:
Yeah. They let you choose your own algorithm, right?

Mark:
Right, that was it!

Ram:
And you could even choose Adler-32.

Mark:
Yes!

Ram:
And at that point you can just generate something else, it’s called a collision where you have two values that generate the same identical hash, which can only happen in really small, short hashes, right?

Mark:
Yeah. So that was an absolutely brilliant piece of research by Matt. And you can find that on the Wordfence blog, it’s a few years old now. The WordPress security team managed to fix that quite quickly, working confidentially with Matt. And then we went ahead and published the research when the all clear was given.

Mark:
But that’s an example of why it is very important to choose the appropriate hashing algorithm for whatever your application is. If you’re launching spacecraft, choose something that’s computationally not that intensive to save some power with your solar cells; if you’re doing password hashing, you want to choose something like bcrypt That’s a little bit more computationally intensive than let’s say MD5. How are we doing so far Ram? Making sense?

Ram:
I think we’re pretty good. Yeah, I think we probably want to cover salts, but I’m not going to spend too much time on them. When Mark was discussing about how you can basically just precompute the hashes of a bunch of passwords, that doesn’t work so great if when you’re storing the password you append a random bit of data to it, called a salt, because then that turns it into a completely different hash. Unless the person who’s attacking your database knows the salt, they’re not going to be able to generate a hash that actually matches your password no matter what list they run.

Mark:
Okay, so I’m going to unpack that a little bit because I’m assuming that we’re dealing with folks who are not programmers here and not necessarily mathematicians.

Mark:
So if you are a bad person, and you’re going around regularly stealing databases of hashed passwords, and you want to crack those, and you want to do it in a way that’s computationally more efficient, what you’ll do is you’ll take, let’s say a bunch of dictionaries of words in English and various other languages, and you’ll use that as the beginning of your word list. And then you’ll take some other sources of passwords, commonly used passwords, you’ll take passwords that have been breached, and you’ll dump that all into a long word list. And let’s say you’ve got around a billion words, well you got two choices when you want to crack your breached password database, you can turn those words into hashes, and then compare those hashes against the hashes in the database and where they match you know that you’ve cracked it, and you know what word it was.

Mark:
And you can do that for every single breached password database that you want to crack. Or you can just do the computation once, and store the hashes alongside what the original plain text was, and then just compare the hashes to each hash in your various breached password databases. And that allows you to only do those competitions once, and then just do that comparison, which is much faster than computing a hash every time.

Mark:
And so that attack is called a rainbow table, and a rainbow table is simply a long list of precomputed hashes and the words that that created those hashes. And there’s big lists of rainbow tables that you can download that are precomputed hashes, and they massively speed up the process of cracking hashes.

Mark:
And so back in the seventies already, they came up with this idea of using salts. And what a salt is, is when you take a user’s password and you’re going to turn it into a hash for the first time, let’s say they’re registering for your service, you want to turn that password that they just entered into a hash, you don’t just run it through the hashing algorithm. You actually append, or prepend, a random piece of text to that password, and then you compute your hash. And what you store is the hash, as well as the little random piece of text.

Mark:
And what that means is that whenever someone signs in now, instead of just taking the password that they enter and running it through the hashing algorithm and doing the comparison, you have to take the salt, prepended or appended, to the password that they entered, run it through their hashing algorithm, and then compare it to what was stored.

Mark:
And what that means is it defeats the rainbow tables attack. Because the hacker can no longer use their rainbow table of precomputed hashes, because they’re forced to take that little piece of text and prepend it to every single word that they’re guessing you might’ve used as your password, create the hash, and then compare that. So you’re forcing them to compute the hashes when you use salts. That’s why salts are useful, is because it defeats a rainbow tables attack.

Ram:
That sounds incredibly useful, and WordPress uses them too, right?

Mark:
Yeah. WordPress, when I started coding was using MD5, and MD5 was a fairly computationally-fast hashing algorithm, therefore it’s easy to crack. And so what WordPress did is they, instead of just using straight MD5, they did 8,000 rounds of MD5. In other words, you hash the password the user entered, and then you create a hash, of a hash, of a hash, of a hash 8,000 times, and then look at that output.

Mark:
And so when they sign in and they enter their password, you just do the same process. Again, hash, of a hash, of a hash, of a hash 8,000 times; sorry, I can’t say that very fast. But WordPress also incorporated a salt, so that they could defeat rainbow tables attacks. And that was back in the olden times of 2011, 2012 when I started diving into WordPress security. Now they’ve moved over to bcrypt. And if you have old MD5 hashes in your database, there’s a migration process right Ram?

Ram:
Yep. If you put an MD5 hash password in a database, and that user logs in, then the password will be changed over to bcrypt, I believe, next time they log in. I mean, you have to log in, but yeah.

Mark:
Yeah, for sure. And the reason they have to do the migration when you log in is because they need to actually know your plain text password to be able to do the migration. So they’re authenticating you by taking your plain text password, using the old algorithm, comparing the output with what stored in the database, which is an MD5 hash. And then if they authenticate you, they’ll say, “Okay, now let’s migrate him to bcrypt,” and they’ll take that password that you entered, which is in memory and use bcrypt to hash it along with a salt, and then replace the MD5 password in the database with a bcrypt password. And that’s how the migration works.

Mark:
So chatting about hashing, and hashing is just used with all kinds of things. It is an integral part of what is called a blockchain. You may have heard of a blockchain and hashing as an integral part of that. The chain element of a blockchain is actually created with hashes where you have a series or a sequence of events, and maybe those are transactions in the case of Bitcoin or maybe they are interactions with a file or a journey of a piece of data or whatever, but it’s essentially a kind of ledger or a sequence of events, and that are tied together using a hashing algorithm. I’m not going to dive into it any more than that because that is beyond the scope of what we’re trying to do on this podcast. But let’s chat about symmetric crypto.

Ram:
Symmetric crypto, that’s just where if I want to send a message to you, then we have to establish a single secret key. You were discussing in the history where the algorithm can be public, but as long as there’s shared secret that we both have, we can use it to encrypt and decrypt data very quickly.

Mark:
Exactly. Symmetric cryptography has been around for quite a while. It’s been around since… I keep wanting to say Wassenaar, but of course, it’s a Wassenaar Arrangement. What is the algorithm called again?

Ram:
Vigenère

Mark:
Vigenère, there we go. So with Vigenère, you had a shared key, and essentially that was a kind of symmetric cryptography where I have the same key that you have, maybe we’ve decided on the name of my dog, and when you receive the message from me, you use that same key to decrypt the message. Now that’s the basis of symmetric cryptography. Symmetric cryptography is very fast, but there’s a major, major problem with it. And that is that if you, audience member, and I want to communicate, and Ram is listening in. And we’re not able to get together, I’m never going to meet you. I don’t know what your name is, maybe it’s John or Mary or whatever your name is, but you and I know each other via this podcast, we chat via DM on Twitter. Ram has managed to hack into a fiber optic cable outside my house and is monitoring everything that we say. We’re on an insecure channel and we want to establish a secure channel.

Mark:
Well, we can’t use symmetric cryptography because I would have to send you my dog’s name as the key over that insecure channel and Ram will get the key, and he’ll just decrypt anything that I send you and vice versa. And that’s the trouble with symmetric cryptography. This challenge had baffled cryptographers for… I don’t know if I’m just making any assumptions about historical cryptographers, but I suspect it baffled mathematicians for a very, very long time. And around the 1970s, there was a major breakthrough in cryptography by RSA, which is the initials of three famous cryptographers.

Ram:
Rivest, Shamir, and Adelman.

Mark:
And what they developed was a way to separate the key that you use to encrypt data from the key that you use to decrypt that data. This is a massive breakthrough, and the reason why is because, again, let’s use our analogy where Ram is sitting outside my house in a van, and he’s got the fiber optic cable running into the van and running back out again, and he’s listening into everything that we say.

Ram:
For some reason no one has spotted me yet.

Mark:
Right. Even though it’s a white van with blacked out windows and all kinds of weird bumper stickers on the back. But okay, moving swiftly on. So I want to communicate with you dear listener, and Ram’s listening in, and the way I do that with asymmetric cryptography, which is this major breakthrough, is that I send you my public key and you receive it. The only thing you can do with that public key is encrypt the data that you want to send me. And the only thing Ram can do with it sitting in his van is he can also encrypt messages and send it to me, but he’s not interested in encrypting messages and sending them to me. He wants to decrypt our stuff, right?

Mark:
So you get the key, you get my public key, you encrypt a message, you send it to me. And I use my secret key, my private key to decrypt that message, and I’ve never sent that private key across the wire. It’s safe in my house. I’m behind locked doors. I know he’s sitting out there in his van, but all my doors are locked. Sorry, Ram. Ram’s actually a really nice guy by the way, but-

Ram:
I promise I’m not actually in a van outside of Mark’s house, listening into, hacking into his fiber optic cable.

Mark:
Or are you?

Ram:
Or am I?

Mark:
All right. So you can use my public key to encrypt data and send that to me and I decrypt it with my private key. And I want to send you some data, I want to send you a reply. So what you do is you send me your public key. I use your public key to encrypt information. I send that back to you across this insecure channel that Ram’s listening in on, and you use your secret key or your private key, those two terms I used interchangeably, to decrypt the data that I’ve sent you. And again, you’ve never sent your secret key or your private key across the wire. Ram doesn’t have it. The only thing he now has is your public key and my public key, and the only thing he can do with those is send me encrypted messages and send you encrypted messages. He can not use those to decrypt messages.

Mark:
And that is the amazing, amazing thing about asymmetric cryptography, is that it provided a way to establish a secure communications channel over a communications medium that’s being monitored by the adversary or the enemy or some hacker. It was a major breakthrough. And so asymmetric cryptography is used extremely widely. It’s used in SSL, now called TLS, which is how we communicate with websites securely. When you’re buying something on Amazon, you are using TLS. And the way that works is that TLS will establish a secure communications channel using asymmetric cryptography, exchanging those public keys, and then decrypting with the private keys that never crossed the wire. Once that secure communications channel has been established, TLS will switch to symmetric cryptography, because as I mentioned, it is more efficient. It’s more computationally efficient that uses less resources. It’s faster in other words. And that is what symmetric cryptography and asymmetric cryptography are, and why they matter.

Ram:
Asymmetric cryptography is kind of one of those world changing things, and it’s kind of something that’s enabled the internet as we know it to sort of flourish, right?

Mark:
Yeah. I mean, for me, I just go back to the wonderful story of Turing breaking the Enigma machine. And of course it was a team at Bletchley Park in the UK and so on, but the Enigma machine was an encryption machine developed by the Germans and used by the Axis powers to communicate with their ships and submarines over an insecure channel, which was HF radio, in other words, shortwave radio. And they would have to set up the shared key before those submarines and before their ships left the Harbor. Now I just think about how excited those, whether it was the Germans, the Axis powers, or the allies, either party, how excited they would have been about a way to establish a secure communications channel over an insecure link. I mean, it would have blown their minds, and that was only invented around the 1970s.

Ram:
It’s a very good thing it wasn’t around back then.

Mark:
Well, it’s interesting, right? Because it really brings up that debate because it is around now. The United States has adversaries around the world. Those adversaries in a lot of cases would consider the United States an adversary. We still have a fair amount of tension floating around the world and the potential for war and actual wars going on. And yet this is now in a world where public key cryptography does exist. You can use key lengths of 2048 bits or 4096 bits which are way longer than 128 bits. That stuff may or may not be crackable by NSA based on the amount of noise that they’ve been making. We think that the stronger cryptographic algorithms with longer keys are actually not trackable by them.

Ram:
Considering they still really, really want that backdoor. Yeah, probably.

Mark:
Yeah. And so, now that everyone out there knows what cryptography is and a little bit of the history, and the crypto wars, and what symmetric cryptography is and what asymmetric cryptography is and why that’s such a breakthrough, and why key length matters, and how NSA in particular has been trying to lobby for smaller key lengths and so on, now, hopefully our audience can think about cryptographic or the cryptography debates and the privacy debate in an informed way. And you can kind of make your own decisions about where you land on it and go from there. And Ram, I think that’s probably a good place to leave it. What do you think?

Ram:
Yeah, I think we’ve covered a lot of ground today. As always, it’s been a pleasure having you on the show. Come and subscribe to us, and listen to us on your favorite podcasting app, whether that’s iTunes or Spotify, or I don’t know what else we have for podcasting.

Mark:
Yeah, absolutely. So Ram-

Ram:
Kathy usually does this part.

Mark:
I know, right. We hijacked her podcast because she’s got the last two days of the week off.

Ram:
Yeah.

Mark:
So hopefully she has a good break there, but Ram, if folks want to follow you on Twitter, what’s your username there?

Ram:
That is Ramuel Gall. I’m pretty boring on Twitter. Mostly all I do is talk about vulnerabilities I or Chloe found.

Mark:
That is definitely not boring. You guys do some amazing research. If you folks want to follow me, I try to stay on message and talk about things Wordfence and security related. My Twitter handle is mmaunder. So you can follow me there. Definitely check out the Wordfence blog at wordfence.com/blog. That is where you’ll find all of Ram and Chloe’s research. And I think you can scroll to the bottom of the page and subscribe to the WordPress Security mailing list, which we run, which has a huge number of subscribers. It’s extremely popular among WordPress site owners. So if you haven’t already subscribed, definitely do that. It’s a very, very high signal to noise ratio mailing list. We don’t spam you with all kinds of product pitches. It’s really just hardcore WordPress Security research made accessible, courtesy of Ram and Chloe. Right, Ram?

Ram:
Yep. Anytime we find a new vulnerability or a find out about a new attack, you’re going to be the first people to hear about it, except for the plugins developer who actually has to fix the plugin.

Mark:
For sure. All right. And then of course you can follow Wordfence on Twitter, @Wordfence. All right, everybody, thanks so much for listening. It’s been an absolute pleasure. Next week, I think we’ll be back to our regularly scheduled programming with Kathy and Ram. Have a wonderful weekend. Bye, everyone.

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.

The post Episode 104: Cryptography Demystified appeared first on Wordfence.

Read More

Severe Vulnerabilities Patched in NextGen Gallery Affect over 800,000 WordPress Sites

On December 14, 2020, the Wordfence Threat Intelligence team finished researching two Cross-Site Request Forgery (CSRF) vulnerabilities in NextGen Gallery, a WordPress plugin with over 800,000 installations, including a critical severity vulnerability that could lead to Remote Code Execution(RCE) and Stored Cross-Site Scripting(XSS). Exploitation of these vulnerabilities could lead to a site takeover, malicious redirects, spam injection, phishing, and much more.

We initially reached out to the plugin’s publisher, Imagely, the same day, and provided full disclosure the next day, on December 15, 2020. Imagely sent us patches for review on December 16, and published the patched version, 3.5.0, on December 17, 2020.

Wordfence Premium users received firewall rules protecting against these vulnerabilities on December 14, 2020. Sites still running the free version of Wordfence received these rules 30 days later, on January 13, 2021.

Description: Cross-Site Request Forgery (CSRF) leading to XSS and RCE via file upload and LFI
Affected Plugin: WordPress Gallery Plugin – NextGEN Gallery
Plugin Slug: nextgen-gallery
Affected Versions: < 3.5.0
CVE ID: CVE-2020-35942
CVSS Score: 9.6 (CRITICAL)
CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H
Fully Patched Version: 3.5.0

NextGEN Gallery is a popular WordPress plugin designed to create highly responsive image galleries. It is clear the plugin’s developer took care to integrate security in the code of the plugin. NextGen Gallery has a single security function, is_authorized_request, that is used to protect most of its settings:

    function is_authorized_request($privilege = NULL)
    {
        $retval = TRUE;
        if (!$privilege) {
            $privilege = $this->object->get_required_permission();
        }
        // Ensure that the user has permission to access this page
        if (!M_Security::is_allowed($privilege)) {
            $retval = FALSE;
        }
        // Ensure that nonce is valid
        if ($this->object->is_post_request() && (isset($_REQUEST['nonce']) && !M_Security::verify_nonce($_REQUEST['nonce'], $privilege))) {
            $retval = FALSE;
        }
        return $retval;
    }

This function integrated both a capability check and a nonce check into a single function for easier application throughout the plugin. Unfortunately, a logic flaw in the is_authorized_request function meant that the nonce check would allow requests to proceed if the $_REQUEST[‘nonce’] parameter was missing, rather than invalid.

This opened up a number of opportunities for attackers to exploit via Cross-Site Request Forgery. One feature of NextGen Gallery is the ability for administrators to upload custom CSS files to be used to style galleries. While the file uploaded had to end with the .css extension, it was possible to upload arbitrary code with double extensions, (e.g., file.php.css). While these files would only be executable on certain configurations, such as Apache/mod_php with an AddHandler directive, this could still result in remote code execution on any vulnerable configurations.

Unfortunately, it was also possible to achieve code execution even on configurations not vulnerable to double extensions. NextGen Gallery has a separate feature that allows users to specify how galleries are viewed via a “Legacy Templates” feature, which also uses the is_authorized_request function for security. Thus, it was possible to set various album types to use a template with the absolute path of the file uploaded in the previous step, or perform a directory traversal attack using the relative path of the uploaded file, regardless of that file’s extension, through a CSRF attack.

This would result in Local File Inclusion (LFI) and Remote code Execution (RCE), as the uploaded file would then be included and executed whenever the selected album type was viewed on the site. Any JavaScript included in the uploaded file would also be executed, resulting in Cross-Site Scripting (XSS).

As a reminder, once an attacker achieves Remote Code Execution on a website, they have effectively taken over that site. XSS can likewise be used to take over a site if a logged-in administrator visits a page running a malicious injected script.

This attack would likely require some degree of social engineering, as an attacker would have to trick an administrator into clicking a link that submitted crafted requests to perform these actions. Additionally, performing these actions would require 2 separate requests, though this would be trivial to implement and we were able to do so during our testing. Finally, the site would require at least one album to be published and accessible to the attacker.

Description: Cross-Site Request Forgery (CSRF) leading to file upload
Affected Plugin: WordPress Gallery Plugin – NextGEN Gallery
Plugin Slug: nextgen-gallery
Affected Versions: < 3.5.0
CVE ID: CVE-2020-35943
CVSS Score: 8.8 (HIGH)
CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Fully Patched Version: 3.5.0

NextGen Gallery also used a separate security function, validate_ajax_request, for various AJAX actions including those used to upload images:

    function validate_ajax_request($action = NULL, $token = false)
    {
        if ($token === TRUE) {
            $token = isset($_REQUEST['nonce']) ? $_REQUEST['nonce'] : FALSE;
        }
        // TODO: Remove !$action condition. Necessary for Proofing at the moment
        return (!$action || M_Security::is_allowed($action)) && (!$token || M_Security::verify_nonce($token, $action));
    }

This function had a similar logic flaw that would allow requests to proceed if the $_REQUEST[‘nonce’] parameter was missing, rather than invalid.

This made it possible to trick an administrator into submitting a request crafted to upload an arbitrary image file. While the uploaded file had to be a valid image file, it is possible to hide a webshell or other executable PHP code within such an image file.

This could also be combined with the previous vulnerability, and the image file could be set as a “Legacy Template”, at which point it would be included and the code within would be executed. Again, this would require some degree of social engineering, as an attacker would have to trick an administrator into clicking a link that resulted in these requests being sent.

Timeline

December 14, 2020 – The Wordfence Threat Intelligence team finishes researching vulnerabilities in NextGen Gallery. We deploy firewall rules and reach out to Imagely.
December 15, 2020 – Imagely replies and we provide full disclosure.
December 16, 2020 – Imagely sends us a patched version of the plugin to review.
December 17, 2020 – A patched version of NextGen Gallery is made available to the public.
January 13, 2021 – Sites running the free version of Wordfence receive firewall rules.

Conclusion

In today’s post, we covered two vulnerabilities in NextGen Gallery, including a Critical Severity Cross-Site Request Forgery (CSRF) that could be used to take over a site via Remote Code Execution (RCE). These vulnerabilities have been fully patched in version 3.5.0, and we strongly recommend that site owners immediately update to the latest version available at this time, which is 3.5.0.

Wordfence Premium users received firewall rules protecting against these vulnerabilities on December 14, 2020. Sites still running the free version of Wordfence received these rules on January 13, 2021.

If you know a friend or colleague who is using this plugin on their site, we highly recommend forwarding this advisory to them to help keep their sites protected as these are critical and high severity vulnerabilities that can lead to full site takeover.

Special thanks to Threat Analyst Chloe Chamberland, who helped analyze this vulnerability, as well as to the plugin’s publisher, Imagely, for their fast and professional response.

The post Severe Vulnerabilities Patched in NextGen Gallery Affect over 800,000 WordPress Sites appeared first on Wordfence.

Read More

The Wordfence 2020 WordPress Threat Report

Over the course of 2020, and in the process of protecting over 4 million WordPress customers, the Wordfence Threat Intelligence team gathered a massive amount of raw data from attacks targeting WordPress and infection trends, in addition to the malware samples gathered by our Site Cleaning team. Attacks on WordPress can be categorized in three major categories, with malicious login attempts and vulnerability exploit attacks predictably leading the way. In a surprising trend, nulled plugin malware also staked its claim as a prominent intrusion vector.

In this report, we provide an overview of the primary threats targeting the WordPress ecosystem as well as recommendations for effective mitigation.

90 Billion Malicious WordPress Login Attempts

Over the course of 2020, Wordfence blocked more than 90 billion malicious login attempts from over 57 million unique IP addresses, at a rate of 2,800 attacks per second targeting WordPress.

Malicious login attempts were by far the most common attack vector targeting WordPress sites. These attempts included credential stuffing attacks using lists of stolen credentials, dictionary attacks, and traditional brute-force attacks.

Key Takeaway: Use Multi-Factor Authentication to Protect WordPress

While the vast majority of malicious login attempts targeting WordPress are destined to be unsuccessful, it only takes a single successful login to compromise a WordPress site. The brute-force mitigation provided by Wordfence is very effective, and using multi-factor authentication adds another layer of protection to WordPress logins.

Multi-factor authentication can completely prevent attackers from gaining access to a site via automated login attempts. This holds true even in unfortunate cases where user accounts on a WordPress site are reusing credentials that have been exposed in a data breach and haven’t yet been updated.

Wordfence offers free login security options within the full featured Wordfence Security plugin. We also offer free login security, including multi-factor authentication, via the standalone Wordfence Login Security plugin.

4.3 Billion Vulnerability Exploit Attempts Targeting WordPress

Wordfence blocked 4.3 billion attempts to exploit vulnerabilities from over 9.7 million unique IP addresses in 2020. Here were the five most common attacks over the course of the year:

Pie Chart showing attacks by type

  1. Directory Traversal attacks, including relative and absolute paths, made up 43% of all vulnerability exploit attempts, at 1.8 billion attacks. While the majority of these were attempts to gain access to sensitive data contained in site wp-config.php files, many were also attempts at local file inclusion (LFI).
  2. SQL Injection was the second most commonly attacked category of vulnerabilities at 21% of all attempts with 909.4 million attacks.
  3. Malicious file uploads intended to achieve Remote Code Execution(RCE) were the third most commonly attacked category of vulnerabilities at 11% of all attempts with 454.8 million attacks.
  4. Cross-Site Scripting(XSS) was the fourth most commonly attacked category of vulnerabilities at 8% of all attempts with 330 million attacks.
  5. Authentication Bypass vulnerabilities were the fifth most commonly attacked category of flaws at 3% of all attempts with 140.8 million attacks.

Key Takeaway: Use a WAF to Protect Your WordPress Site

A Web Application Firewall, such the Wordfence WAF, is absolutely critical to keeping your WordPress site secure. Nearly every one of the 4 million sites in our network experienced at least one of each of these attacks over the course of 2020.

Wordfence is the leading WordPress firewall solution and is continually updated to protect against existing and emerging WordPress attacks. In 2020, we deployed 108 new rules to the Wordfence firewall to protect our customers from unique exploits.

Wordfence Premium customers also benefit from our IP blocklist which is extremely effective at blocking known bad actors. While the Wordfence Premium blocklist generally consists of 15,000 to 40,000 unique IP addresses at any given time, the list is continually updated as new attackers emerge and as infected servers are cleaned. For the entire year, the Wordfence Premium blocklist prevented 2.55 billion attacks from 628,564 unique IP addresses, each of which spent some time on our blocklist in 2020.

Malware From Nulled Plugins and Themes Is the Most Widespread Threat to WordPress Security

The Wordfence scanner detected more than 70 million malicious files on 1.2 million WordPress sites in the past year. The vast majority of these sites were cleaned by the end of the year. Only 132,000 sites infected at the beginning of 2020 were still infected by the end of the year, many of them likely abandoned.

The WP-VCD malware was the single most common malware threat to WordPress, counting for 154,928 or 13% of all infected sites in 2020. Overall, the Wordfence scanner found malware originating from a nulled plugin or theme on 206,000 sites, accounting for over 17% of all infected sites. Other obfuscated PHP backdoors made up the remainder of the top 5 most widely detected threats.

Key Takeaway: Educate Yourself and Your Organization About WordPress Security

Policy controls are just as important as technical controls, because insider threats capable of bypassing technical controls can cause immense damage to an organization. This applies to a WordPress site just as much as it does to a Fortune 500 company.

While insider threats are often portrayed as malicious, the vast majority of them are accidental, from clicking a phishing link to installing nulled plugins. Much like phishing links, nulled plugins are specifically designed to take advantage of naive insiders.

The best way to avoid making this kind of mistake is to educate yourself and everyone else in your organization. While a plugin like Wordfence can detect malware originating from a nulled plugin or theme after it has been installed, only proper training can prevent a misguided administrator from accidentally installing it in the first place.

Conclusion

In our review, we identified the three most widespread threats faced by WordPress sites in 2020: malicious login attempts, attempts to exploit vulnerabilities, and malware originating from nulled plugins and themes.

We also explored key takeaways from these threats and how to most effectively mitigate them. While technical controls such as Wordfence can dramatically improve your WordPress site security posture, the human element is always the weakest link in any organization. Education is the best way to make sure your site is secure.

As such, Wordfence is committed to educating the WordPress community about security via the official Wordfence blog, our Think Like a Hacker Podcast, and Wordfence Live which is broadcast every Tuesday, in addition to our presence at many WordPress events. Our Threat Intelligence team works hard to protect every one of our users, and it’s all thanks to the support of our Premium Customers, who make it possible for us to help keep WordPress safe.

The post The Wordfence 2020 WordPress Threat Report appeared first on Wordfence.

Read More

Episode 101: Supporting Remote Students with Free Site Audits & Cleanings

Wordfence announces a new program offering free site cleaning and site audits to public schools in the United States. We talk about why we’re offering this program and how to help schools take advantage of it. We also talk about the growing prevalence of WordPress as a content management system and how the incoming administration is using WordPress. We also talk about two unpatched Windows 10 denial of service vulnerabilities, a breach affecting over 1.9 million Pixlr users, and phishing kits exposing stolen passwords via Google search.

Here are timestamps and links in case you’d like to jump around, and a transcript is below.
0:30 Announcing Free Site Cleaning & Site Security Audits for K-12 Public Schools
3:49 Preventing Carding Attacks: Thwarting Credit Card Fraud on WooCommerce
6:49 WordPress Powers 39% of the Web; Biden Administration sticks with WordPress
9:21 Windows 10 Denial of Service Unpatched Vulnerability
11:14 1.9 Million Pixlr User Records for Free on Forum
14:40 Phishing Kits Expose Stolen Passwords via Google Search

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 101 Transcript

Ram Gall:
Hello, and welcome to Think Like a Hacker, the podcast about WordPress security and innovation. I am Ram Gall, Threat Analyst and QA Engineer at Wordfence, and with me is our Director of Marketing, Kathy Zant. Hi, Kathy. How are you?

Kathy Zant:
I’m doing great, Ram. How are you? Welcome to 2021.

Ram:
I know. It’s pretty exciting. This is my first podcast this year.

Kathy:
Yeah. You’ve had a bit of a break, almost a month off from podcasting. How did you ever survive?

Ram:
I don’t know. I missed it terribly. I did. It’s fun to get to chat with you every week.

Kathy:
It is a lot of fun. I know we’ve been keeping you pretty busy in threat intel. Every time I wake up in the morning, it’s like, “Oh, well, Ram’s going to have a busy day today.” It’s been a busy start to this year, hasn’t it?

Ram:
It has a bit, yeah. I know that you’ve been working on some pretty impressive stuff lately, too. What’s this I hear about site cleans for K through 12 schools?

Kathy:
Yeah, yes. This is an interesting little offering we have. Obviously, in the past year things have gotten a little crazy with the world and education in general because of the pandemic that has hit. A lot of schools have gone to remote learning and are leveraging technology, including WordPress, in order to connect educators with students. And because of that, we wanted to do something to help some of these schools. A lot of them have been financially strapped and challenged because of these new challenges that are on their plates, and they’ve had to ramp up into a new mode of education. So we wanted to help, and the best way that we can help is to provide services to schools. So we’ve limited it right now to public K through 12 schools in the United States. That may change in the future, not sure yet. We’re just launching that now.

Kathy:
So if you are an administrator, a teacher, even a parent and your kids are in a K through 12 school, and that school is using WordPress, we want to help you. We want to ensure that your students are safe, that malicious actors are not targeting schools that may not have security personnel on staff. So we’re helping you not only with cleaning up hacked sites. If you have a site that has been attacked and has malicious code on it, we will help you get that cleaned up and get you secured with Wordfence, but we will also help you with some proactive security measures, namely security audits.

Kathy:
Now, security audit at Wordfence goes through almost 60, I think it’s about 60, different factors that they look at in a WordPress site to look for any types of vulnerabilities, any security best practices that aren’t being followed. And we basically become the security expert for your school to make sure that your school’s WordPress website is as secure as it can be. So it becomes an educational process, not only for those who are using WordPress, but it becomes a process for everybody at the school. So that kind of trickles down into the classroom, and we think everyone should learn more about security. What do you think, Ram?

Ram:
I think that educating the educators is a great way to go about things.

Kathy:
I think so, too. We like to give back where we can and obviously, we can’t help everyone in the whole world, but we think education, especially public education, is incredibly important, giving opportunities to everyone. So we want to help those educators and help those institutions. So if you want more details, there’s links in the show notes. If you know of a school that could use our help, please definitely send that link to them. We would be happy to help them right now. There’s just a queue and we will let you know where you are in that queue, and we’ll get to work helping you get secured. So, that’s the deal with that. Now I wanted to talk to you, Ram, about our next… How’s Wordfence Live going? That’s been a lot of fun lately, hasn’t it?

Ram:
Well, yeah. Well, speaking of educating our users, we have been doing our weekly livestream on YouTube. Next week’s is going to be pretty exciting. We’re going to talk about WooCommerce security, and specifically we’re going to talk about carding attacks. Now-

Kathy:
Carding attacks. What is a carding attack?

Ram:
Carding refers to more or less the entire process of stealing credit card data and testing out those credit cards to see if they can be used and using it to purchase stolen goods. And as you might understand, if you’ve got an e-commerce solution like WooCommerce installed on your site, any step in this process is probably a concern for you.

Kathy:
Definitely, and especially with the challenges of everybody working remotely. A lot of people have lost their jobs in the last year, and so their side hustle has become their main hustle. And a lot of that is using things like WordPress and using WooCommerce in order to get e-commerce set up and going. So a lot of these people who are rather new to the e-commerce space are dealing with carding attacks. So we want to help people who are using WooCommerce, and there’s millions of sites using WooCommerce, understand where these attacks are coming from and some strategies to cope with them. Did you have some statistics on how many attacks like this are actually happening?

Ram:
So these statistics are actually from the FTC and these are only self-reported statistics or reported by law enforcement. So this is really only a drop in the bucket, probably, of the actual number of attacks. But apparently in 2019 there were 650,000 reported identity theft attacks, $325 million lost in fraud via website. 135 million of that was credit card fraud. But again, a lot of this information is self-reported where people just say, “I lost it on a website,” but they don’t necessarily specify the method, or they say, “I lost it via credit card,” but they don’t necessarily specify how. So either way, it’s a big, expensive deal, and that’s just with these limited statistics.

Kathy:
Yeah, it sure is, and it’s only going to get bigger. So we’re going to dive deeper into this. This is just a taste of why we’re diving into this next week on Wordfence Live. So if you’re running a WooCommerce site or if you know someone who is, send them over to Wordfence Live on YouTube, there will be a link in the show notes for that as well, because we’re going to show you how you can make things very difficult for cyber criminals who are doing carding attacks. That’s our favorite thing to do, make things difficult for the attackers, right?

Ram:
Yes. There is no such thing as perfect security, but if you make it hard enough, if you make it difficult enough, if you make it enough of a pain, then all the attackers who are motivated by profit, which is pretty much all of them these days, are going to find an easier target.

Kathy:
Definitely. Well, we had an article that we saw on Search Engine Journal talking about how prevalent WordPress is these days on the wide interwebs. What’s the number now, Ram?

Ram:
WordPress is a fairly dominant content management system. I think it was 35% of all sites on the internet last year. Now it’s 39.5% of all sites on the web, and it is 64.1% of sites with a content management system or CMS. That is to say that it’s almost two thirds of all the sites that weren’t basically coded, built from code rather than in a site management system.

Kathy:
Well, every site is built by code, but who’s throwing all that code together, I guess is the question?

Ram:
That’s really what I’m saying. It’s two thirds of the sites that weren’t custom coded.

Kathy:
Gotcha. Okay, great. And there’s a new site out on the web. Well, it’s an old site for a new site.

Ram:
It’s a site that’s been around for a while, but it’s using a new CMS and guess which CMS. That’s correct. Whitehouse.gov is using WordPress.

Kathy:
It is using WordPress, and this was written about on January 20th on WP Tavern as well as a number of other sites, where they were taking a look at what whitehouse.gov, what the new administration is using. And of course, I poked around in the source code too and saw an interesting note, comment in the source code. Basically, the USDS or the digital… Is it the digital service? They’re looking for people to work with them in order to bring communication to more people and to make government more accessible. So we’ll have a link to that in the show notes as well. I think it’s pretty interesting. Onward and into the future, eh?

Ram:
I mean, WordPress is, in a way, the future.

Kathy:
And the past, but it’s even more the future.

Ram:
The WordPress is all. WordPress is the past. WordPress is the future. WordPress is the present. WordPress is all.

Kathy:
Yeah, WordPress is everywhere. It’s definitely become a big player not only with people putting up blog sites, but WordPress is powering more and more very complex sites, not only with WooCommerce, which has really staked its claim as one of the leaders in e-commerce, but learning management systems, membership sites. There are so many different things that you can do with WordPress, and I think that is really the key to its success and why it’s become such a dominant player in internet development.

Ram:
I know we haven’t covered all that much security yet in this podcast. And I think part of that is just because everything was SolarWinds forever.

Kathy:
And SolarWinds is still going on, isn’t it?

Ram:
It is still going on. It is still a dumpster fire that is still burning.

Kathy:
It is.

Ram:
But we have some more lighthearted, I guess you could call it, security news this week.

Kathy:
What’d you find?

Ram:
A security researcher, Jonas Lykkegaard, discovered two Windows 10 denial of service vulnerabilities, effectively. One was a single line command that can corrupt an NTFS formatted hard drive by referencing basically one of the drive indexes.

Kathy:
Oh my gosh. That doesn’t sound fun to me. And this article states that it is still unpatched.

Ram:
Apparently, yeah. I mean, bear in mind that patches typically come out on Tuesdays. So hopefully, we’ll see something this coming Tuesday. But, yeah, that’s not the only one he found. He found another thing where you can just paste the link into your browser and it’ll give you a blue screen of death and also potentially put your computer in a boot loop. That’s basically the path for a kernel connect device. I guess it expects an extra parameter and if you don’t supply that parameter, it just boot loops your computer, which is, again, not something that should happen.

Kathy:
Wow. Okay. Well, we will probably see a patch for this sometime in the near future, but that is a very frightening vulnerability. I mean, it’s one thing to have malware on your site. It’s another thing altogether to have your computer basically locked up like this.

Ram:
Yeah. I mean, it is frightening. The good news is that these are not things that you know an attacker can reach into your system and do, unless they have another intrusion vector. So don’t paste these commands into your browser, don’t type them into your console. You’ll probably be fine unless, of course, someone is already in your system, in which case you’re probably not fine anyways. And they probably have more productive and more profitable things to do than exploit these vulnerabilities.

Kathy:
Yeah, definitely. All right. So we found another story about a hacker posting almost two million user records for free on a forum. What’s the story here?

Ram:
So that was Pixlr, which is an online photo editing service. But I mean, pretty much every time we see a data breach, it’s an unsecured S3 bucket. As to why this keeps happening, it’s because, from what I recall, it’s S3 buckets are unsecured by default and it’s kind of a pain to get them secured. You might not actually know that it’s unsecured unless you check. So AWS is a dark art.

Kathy:
It sounds like it. Wow, that sounds pretty frightening. But I mean, these types of data breaches happen all the time. Is there anything really unique about this one?

Ram:
Unique? I don’t know about that. It did contain email addresses, login names, and hashed passwords. I guess it’s unusual that the passwords were hashed with SHA512, which is a very secure way to hash something so it can’t be reconstructed. But it depends on whether or not the passwords were salted. And that’s what I really want to know is, if the passwords were salted, then it will be very hard to reconstruct them. And just so our listeners know, a hashing is basically where you take any amount of data and run a one-way mathematical function on it and get a fixed length string back consisting of, in human-readable views, zero to nine and the letters A through F. It’ll usually be like 32 characters long, or 40 characters long, or 64 characters long if you’re viewing it human-readable. And it should be unique to that piece of data. I mean, it’s not going to be, but you shouldn’t have two hashes being the same thing.

Ram:
Anyways, I’m kind of getting off track, but you shouldn’t be able to reconstruct what a password was just from its hash, but you can do a thing and it’s called… There’s an technique called rainbow tables, where you just take a whole bunch of possible passwords and you run them through the hash. Then you can just check whatever hash you have and compare them to the stuff you’ve already hashed, and if it matches up, there’s your password. So websites do something called salting, which is adding a random chunk of data to the password before it gets hashed.

Kathy:
That’s something you see in your WP config file. You see salts in there.

Ram:
You do. You do, and that is one of the things that protects your users in case your database ever gets exfiltrated. That is something that generally makes it a lot harder for attackers to reconstruct passwords from data breaches. So it doesn’t really matter which algorithm they used if it wasn’t salted, and we don’t know. So if you were using Pixlr, please change your password. They probably made you change it anyways, but if they didn’t, please change it.

Kathy:
Right. And this is just another reminder that you should always be using unique passwords everywhere, because you never know when a site that you’re using that password on, whatever password that password is, gets into some kind of issue with a breach like this and that password is exposed somehow.

Ram:
I just switched over to a password manager over the holidays.

Kathy:
Did you?

Ram:
So that was one of my big tasks over the holidays was switch to a password manager for everything.

Kathy:
Excellent. Welcome to the future again.

Ram:
I know, right?

Kathy:
Yeah. Now, one thing that is never going to help you, if you’re dumping passwords into phishing kits that are on hacked sites. We saw something happen there. What’s going on with this one, Ram?

Ram:
Oh, so this is fun. A couple of researchers found some phishing credentials that were indexed by Google because, okay, so it’s fairly typical for attackers to take over WordPress sites and to host phishing pages and send links to those phishing pages to victim email addresses saying, “Hey, we need you to sign into Office 365. Here’s a link to this completely trusted website that is totally not a sketchy website because it’s a legitimate hacked website that we hacked.”

Ram:
Anyways, a lot of the time, these phishing kits, they’ll store the stolen credentials in a text log or something for easy access by the attacker. And usually, smart attackers put something in place so that those stolen credentials aren’t indexed by search engines. They’ll put a robots file or a noindex tag or something on there, or even they’ll password protect it. But in this case, they kind of forgot to and Google was serving up all these stolen credentials.

Kathy:
Oh my gosh. That’s crazy. So not only did the hacker get these passwords, everyone did.

Ram:
Yeah.

Kathy:
That’s crazy.

Ram:
Yeah. These were, at this point, public passwords-

Kathy:
Oh my gosh.

Ram:
… and you never want your password to be public.

Kathy:
No, not at all. Interesting. Okay. Well, that’s fascinating. Wordfence has a number of signatures that will detect a phishing kit if your site is ever hacked. And obviously, we’ve talked a number of times on the podcast, as well as on Wordfence Live, on techniques to stop yourself from getting phished. The thing is, is with phishing, it’s never as complex as you think it’s going to be, obviously. I mean, they can’t even protect their own treasure and loot, so to speak. We’re not dealing with SolarWinds types of hackers here, are we?

Ram:
We are not. We are dealing with people who typically go after low-hanging fruit. Unfortunately, I mean, that is where the money is.

Kathy:
Very unfortunately. Well, that’s all the stories we have this week, Ram. We’ll do it again next week, hey?

Ram:
We will, and I’m looking forward to it.

Kathy:
I am too. And if somebody wants to follow you on Twitter, you are at?

Ram:
@ramuelgall.

Kathy:
And I am @kathyzant. We will talk to you again next week on Think Like a Hacker. Bye.

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.

The post Episode 101: Supporting Remote Students with Free Site Audits & Cleanings appeared first on Wordfence.

Read More

Uncovering Potential Issues with the Contact Form 7 Vulnerability: More Data Needed

On December 17, 2020, the Astra research security team disclosed that they had discovered a critical severity Unrestricted File Upload vulnerability in Contact Form 7, the most popular WordPress plugin of all time. The lead researcher, Jinson Varghese, also published a blog post providing limited information about this vulnerability.

The initial disclosure claimed that “By exploiting this vulnerability, attackers could simply upload files of any type, bypassing all restrictions placed regarding the allowed upload-able file types on a website.”

At the time, we were unable to duplicate the exploit and published our analysis based on the best information available, which indicated that the vulnerability would be difficult to exploit and would likely require a very specific configuration, but we wanted to wait until a public Proof of Concept was available.

A minimal Proof of Concept submitted to wpvulndb by the original researcher was made available on December 31, 2020. A separate, unverified Proof of Concept appeared on exploit-db on December 20, 2020. On January 10, 2021, the Astra Security team updated their vulnerability announcement stating that a full Proof of Concept would not be released.

None of our threat analysts were able to use these initial Proofs of Concept or any variants thereof to achieve unrestricted file upload, and indeed we had already attempted several variants of each Proof of Concept when the vulnerability was first disclosed because our analysis of the plugin patch indicated that these might be a viable approach.

We were able to use a double extension plus a unicode character to pass a single security check, the wpcf7_antiscript_file_name function, but this function was only one of several security measures in place for the upload process, and bypassing it did not allow the ability to upload files with extensions that would be executable on any of our test configurations. The most recent of these additional security features, the addition of a randomized directory, has been in place for more than 6 years.

We were not able to successfully upload files ending in a “.php” extension, nor were we able to upload files with double extensions (e.g. file.php.jpg, or file.jpg.php, with or without an invisible unicode separator between the two extensions) that would be parsed by any recent web server configuration we have tested. Configurations we have tested include Apache with a PHP AddHandler directive, Apache with an anchored SetHandler directive, Apache + PHP-FPM, NGINX + FastCGI, Litespeed, and IIS. Additionally, we have not seen any evidence of this vulnerability being successfully exploited in the wild.

We contacted the original security researcher requesting more information, but have not heard back at the time of this publication. We also contacted the plugin developer, who indicated that he recognized the bypass in the wpcf7_antiscript_file_name function as a potential vulnerability but had not been supplied with a Proof of Concept that bypassed the other security measures. We reached out to Astra Security who pointed us to their updated blog post indicating that no Proof of Concept would be released and that they had also not seen any evidence that the vulnerability was being exploited in the wild.

Open source security research is incredibly important and makes the entire WordPress ecosystem safer. It is critically important that vulnerable configurations are known; any server configuration that allows this vulnerability to be exploited could allow currently undiscovered vulnerabilities in other plugins to be exploited as well. It is also important to the credibility of our industry that this research be independently verifiable. While we realize that there may be good reasons not to make a Proof of Concept public, providing such a Proof of Concept to other security researchers allows the industry to improve its response to known threats.

For these reasons, we are requesting that the Astra Security research team, or anyone else in the WordPress or Security community who is able to do so, provide us more information about this vulnerability, as we would like to be able to independently duplicate the issue in order to confirm its impact, not only for the millions of users of Contact Form 7, but also for the wider WordPress ecosystem. We are requesting vulnerable server and plugin configurations in which it is possible to upload an executable PHP file via this vulnerability, as well as an unabridged Proof of Concept that allows us to duplicate the issue.

The post Uncovering Potential Issues with the Contact Form 7 Vulnerability: More Data Needed appeared first on Wordfence.

Read More

SolarWinds and Supply Chain Attacks: Could it happen to WordPress?

The SolarWinds supply chain attack is all over the news, impacting government agencies, telecommunications firms, and other large organizations. The security firm FireEye was the first victim of the attack, disclosing that they had been hacked on December 8, 2020. On December 13th the US Treasury Department announced that it had also been compromised. At that time SolarWinds Orion was officially reported as the intrusion vector.

SolarWinds has since stated that “fewer than 18,000” firms were affected. Companies impacted by the SolarWinds supply chain attack include Intel, NVidia and Cisco.

What is a supply chain attack?

A supply chain attack involves gaining access to a system by targeting a trusted third party used by that system. This can include any point in the supply chain.

For instance, the 2013 Target data breach, the most expensive retail attack in history at the time, was tracked down to attackers first compromising an HVAC supplier. The attackers used credentials obtained from that supplier to gain access to Target’s internal network.

More recently supply chain attacks have focused on software suppliers. Compromising a single organization can have a much larger impact if the compromised software is distributed to many users. In 2017, attackers spread the NotPetya malware variant and caused billions of dollars in damage by compromising update servers belonging to MeDoc, an accounting software company with thousands of customers.

What about SolarWinds?

SolarWinds Orion is a Network Monitoring and Management product, meaning that it can be configured to have an immense amount of control over an organization’s infrastructure.

A currently unconfirmed nation-state threat actor managed to inject a backdoor, known as SUNBURST, into several versions of the Orion software before they were downloaded by SolarWinds customers.

In this case, SolarWinds was the trusted third party, and up to 18,000 of their customers, many of them large enterprises, downloaded and installed an infected version of Orion as early as March of 2020.

Despite the number of infected users, the attacker appears to have focused on staying hidden while gathering information, focusing on a handful of targeted organizations. The SANS institute has a more in-depth examination of the attack and its mechanism.

A separate webshell, dubbed SUPERNOVA and believed by Microsoft to have been injected by a different attacker, has also been found in Orion, indicating that multiple threat actors realized the value of this type of attack against Orion.

Although the intrusion vector that initially led to the compromise of SolarWinds Orion is currently unknown, in 2019 a security researcher named Vinoth Kumar reported that he had found credentials to the SolarWinds update server in a public GitHub repository, including an incredibly insecure password of “Solarwinds123”. While the SUNBURST malware was cryptographically signed, which would have required the attacker to compromise additional systems, these findings are indicative that SolarWinds may have had a poor security posture in other areas.

Could something like this impact WordPress?

Yes. While the SolarWinds attack itself is unlikely to impact any WordPress sites, a similar attack could be used against WordPress. In 2016, Wordfence Lead Developer Matt Barry notified WordPress about a potential supply chain attack that could have infected nearly a third of the internet by compromising the WordPress update infrastructure at api.wordpress.org, which instructs WordPress sites where to download automatic updates. Thanks to our disclosure, the issue was patched before it could be exploited.

Supply chain attacks aren’t always technical. Between 2013 and 2017, an unscrupulous spammer known as Mason Soiza managed to insert malicious code used to display unwanted spam and ads into at least 9 WordPress plugins, including some with several hundred thousand installations. In most cases he purchased the plugin from the author and included his own malicious code.

Later in 2017 we saw the same activity on three separate plugins that had changed owners, where the new owners included content injection backdoors in the plugins.

The motives for a WordPress supply chain attack may be different from those of the attackers targeting SolarWinds, but the mechanisms would be the same. While many of the attacks against WordPress are not sophisticated, the probability of an attacker targeting a CMS powering over one-third of the internet should not be underestimated.

How can supply chain attacks be prevented?

It is impossible to completely eliminate supply chain attacks, but there are ways to mitigate the risks posed by them. For instance, WordPress introduced support for cryptographically signed updates in version 5.2, though the feature is not yet fully in use. This would prevent WordPress from installing updates that were not signed with the correct keys.

While this might protect against an attacker taking over api.wordpress.org and instructing sites to download updates from a rogue server, it would not protect against an attacker taking over a legitimate plugin.

Additionally, if an attacker was able to gain access to the server or keys used to sign updates, they could still bypass this measure. One of the most troubling features of the SUNBURST malware was that the attackers were able to cryptographically sign the update so that it appeared to be legitimate.

As with other threats, the risk of supply chain attacks is best addressed with a combination of technical and administrative controls, including code signing, making use of the principle of least privilege, and system hardening, so that the breach of a single component doesn’t result in an entire system or network being compromised.

Protecting Against Supply Chain Attacks

As users of software, detecting and preventing supply chain attacks can be extraordinarily difficult. Software and vendor relationships are based upon trust. Software users trust that the software and systems that their organizations use are secured, yet users have little control over the security or processes that develop and distribute that software. This is especially true in closed-source software models, where the responsibility of security is on one organization.

In some ways, WordPress is different from most other software in that there is an active and communicative network of developers who contribute to the project and are invested in the success of WordPress. This community has often been a first line of defense in detecting and disclosing issues so that they can be resolved quickly.

In either case, protecting an organization from a supply chain attack via trusted software can be difficult. It requires attention, testing, and awareness. WordPress has the benefit of a large community of users and developers who have historically shared that responsibility.

While the WordPress ecosystem is not immune to supply chain attacks, its open-source nature means that many potential issues may be spotted and patched more quickly than problems with a proprietary codebase. In many ways the primary challenge in an open-source ecosystem is in making sure that all users are updating to patched software as threats emerge and are mitigated with new releases.

Conclusion

In today’s article, we discussed the SolarWinds attack and the risks posed by supply chain attacks in general. We also covered a potentially catastrophic supply chain vulnerability that was patched in WordPress before it could be exploited, as well as smaller supply chain attacks that had been successfully executed against WordPress plugins. Finally, we went over potential preventative measures, including code signing and community involvement.

Supply chain attacks will continue to be a threat for the foreseeable future. While no single strategy can prevent supply chain attacks, a combination of best practices can reduce their impact.

Special thanks to Director of Marketing Kathy Zant for her assistance with this article.

The post SolarWinds and Supply Chain Attacks: Could it happen to WordPress? appeared first on Wordfence.

Read More

A Challenging Exploit: The Contact Form 7 File Upload Vulnerability

Contact Form 7, arguably the most widely used WordPress plugin, released a security patch for an unrestricted file upload vulnerability in all versions 5.3.1 and lower. The WordPress plugin directory lists 5+ million sites using Contact Form 7, but we estimate that it has at least 10 million installations.

One of the important features of Contact Form 7 is the ability to allow file uploads as a part of a form submission. While uploaded filenames are sanitized during the upload process, reviewing the patch indicates that an attacker could potentially bypass some of Contact Form 7’s filename sanitization protections when uploading files by adding control characters or invisible separators.

There are a number of mitigations in place within Contact Form 7 that would make this bypass difficult to fully exploit:

  • Any uploaded files are stored temporarily in a folder with a random name, and removed immediately after the file is sent to the form recipient. This means the attacker would need to be able to find the random folder name, which would likely require Directory Indexing to be enabled, and they would need to do so before the randomized directory and uploaded file was removed.
  • Contact Form 7 uses an .htaccess file to disallow direct access to uploaded files which would be necessary to execute code. While this would only work on sites running Apache, it would prevent execution of any uploaded files unless a separate vulnerability was present.
  • The filename must end in an acceptable file extension. This means that only certain Apache configurations would assign a PHP handler to any uploaded file using a double extension.

If you are using Contact Form 7 without the file upload functionality, your site is not vulnerable to attackers looking to exploit this vulnerability. However, we still recommend an immediate update to ensure your site is protected.

Wordfence customers, including Wordfence Premium users and those still running the free version, are protected by the Firewall’s built-in file upload protection which will prevent any attempts to upload known malware or executable PHP files.

The patched version was released early today, Wednesday, December 17, 2020. If your site is one of the many sites using Contact Form 7, we strongly recommend that you update to version 5.3.2 as soon as possible.

While this vulnerability is unlikely to be easily exploitable, due to the prevalence of sites using Contact Form 7, attackers may still end up targeting this vulnerability. Given more time, or published proof of concept code, attackers may find that exploitation of this vulnerability is much easier than is readily apparent now.

Special thanks to Lead Developer Matt Barry and QA Lead Matt Rusnak for their assistance in investigating this issue.

The post A Challenging Exploit: The Contact Form 7 File Upload Vulnerability appeared first on Wordfence.

Read More

The NoneNone Brute Force Attacks: Even Hackers Need QA

For the last few weeks we’ve seen and blocked an increase in brute-force, credential stuffing, and dictionary attacks targeting the WordPress xmlrpc.php endpoint, on some days exceeding 150 million attacks against 1.9 million sites in a 24-hour period. These attacks attempt to guess the password of an authorized user on a site, and some of our users have noticed an odd phenomenon:  brute force attacks with the username and password set to “None” or “NoneNone”. Since these requests are targeted against xmlrpc.php, changing the admin URL won’t prevent attackers from sending these requests.

What’s going on?

Because these attacks are attempting to login with unusual credentials, we’ve had curious site owners reach out to ask what might be happening. We’ve determined that the attackers are generating lists of domains to attack complete with credentials to attempt and that there is likely a flaw in the code of this target generation program.

In addition to reviewing our own attack data, we were able to find logs and domain lists that appear to have been used by the scripts performing these attacks.

A log file displaying an xmlrpc attempt with NoneNone as the username and password

These domain lists appear to have been generated programmatically and include a target to attack, a username to attempt, and a password to attempt. In the domain lists we found, “NoneNone” was frequently used as a username in cases where a real username was unknown to the attacker. In some lists, this was paired with a nonsense password such as “qwe123”, while in others the password would also be set to “NoneNone”.

A redacted list of domains to target including username NoneNone and password qwe123

It’s likely that the script used to generate these domain lists are written in Python, a language that has a “None” type that is equivalent to “Null” in other languages, and which is printed out as “None” when cast to a string.  As such, a script to generate domain lists to attack could have set the username and password variables to default values of None (or concatenated multiple default values, resulting in “NoneNone”) when provided with incomplete information.

What should I do?

If you’re using Wordfence, our built-in brute force protection will protect your site against XML-RPC attacks. This is important because some of these attacks will be trying real usernames and passwords from credential breaches rather than invalid values. Additionally, sites running Wordfence Premium will automatically block any requests from IP addresses that have been attacking other sites in our network thanks to our real-time IP blocklist.

For an extra layer of protection, both free and premium users can disable attempts to authenticate via xmlrpc.php requests entirely by going to Wordfence->Login Security->Settings and clicking  Disable XML-RPC authentication.

A screen sht showing the "Disable XML-RPC" setting in Wordfence Login Security

Please note that this can prevent certain plugins that rely on xmlrpc.php, such as Jetpack, from functioning properly.

Conclusion

Although we’ve seen a very large number of these attacks, the vast majority of them are unlikely to threaten sites unless the site administrator is using credentials that have been compromised. Nonetheless, this goes to show that scripts used for hacking can have bugs and unexpected behavior just like any other software.

Sites running the free version of Wordfence are protected by our built-in brute force protection, and sites running Wordfence Premium are additionally protected by the real-time IP blocklist. Both free and premium Wordfence users can disable XML-RPC authentication for full protection against attacks against this endpoint.

The post The NoneNone Brute Force Attacks: Even Hackers Need QA appeared first on Wordfence.

Read More

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.

The post Episode 98: How Application Passwords Work in WordPress 5.6 appeared first on Wordfence.

Read More
Page 1 of 512345»