Tag: security

Posted On

This past Friday, I gave a 20-minute presentation on WordPress security, giving a high-level overview of things you can do to help keep your sites secure.

The Presentation

Here's a SlideShare embed of the presentation deck:

And you can download the Keynote source file for my presentation, including presenter notes.

Twitter Questions

As part of my talk, I asked attendees to submit any questions they might have had via Twitter using the hashtag #wpvipsec. Here are the questions I received, and some brief answers to them as best I can provide.

As we have been transitioning some of the WordPress.com VIP platform to our next-generation VIP Go platform, we've had to reinvent some of this stuff slightly. :) You'll be pleased to know that we have made the mu-plugins we use on VIP Go publicly-viewable on Github, and you can see our custom two-factor module here.

https://twitter.com/NelsonTheFresh/status/936659951711408129

I don't know very much about securing sites via VPN, but I'm assuming here that you have site access (even front-end) locked to internal IPs only based on that VPN connection. That should handle a large portion of your security from outside attack, assuming the VPN is using appropriate security precautions.

At this point, your chief enemy is likely to become human error. This is where portions of the talk surrounding things like limiting user capabilities and access to certain settings pages can really help you out. Making sure your users are following good account security processes for connecting to the VPN is also critical.

As I suggested in the Q&A after the talk, I highly recommend that user roles and capabilities be in your WordPress engineering toolbox. They are enormously useful.

Multisites are interesting because they have additional layers of user access. Let's look at the two admin roles:

Super Admin: This should be as limited as humanly possible. The only users who should have superadmin powers on a multisite IMO are system administrators, your development team, and support users who will be assisting other users with account-level actions regularly. (An additional user or two might be necessary if you have people who need to spin up new sites on-demand rather than contacting your support team.) You should certainly require two-factor authentication here, and if you can require proxy or VPN access at this level, you absolutely should look into that as an option.

Administrator: This is going to be on a site-by-site basis within the multisite. If you can craft custom roles and their capabilities finely enough for your needs so that non-development users who are "in charge" of a site can use those roles instead of full admin, you should absolutely do this. Ideally, this user group and the Super Admin user group are as close to identical (and as limited) as possible.

The remainder of the roles are easier to parse. I'd like to especially recommend here (as I did during the talk) the use of an audit trail plugin; as you will have many users working on sites, and some with superadmin powers, the helpfulness of knowing which users performed which actions increases.

Additional Questions?

If you have any questions that haven't been covered above or in the talk, please send me a reply on Twitter and I'll be happy to drop them in the post and let you know when I have updated it.

I'll be updating this post occasionally with new information, as well as a link to the talk's video archive when it's available. To be notified of this, please either follow my blog or follow me on Twitter.

Posted On

It’s time to look forward to WordCamp US at the end of the year: seeing lots of familiar faces, attending fantastic sessions by creative and knowledgeable people, and volunteering to help create a great event for every attendee.

Last year, I gave a lightning talk on code review that I thought went very well; it was an adaptation of a talk I gave earlier in the year at WordCamp St. Louis based on the experience I’ve had with code review as a culture-centric thing at Automattic and specifically on the WordPress.com VIP team.

The deadline for talk submissions for this year is tomorrow, and so far, I have submitted two talks (I’ll bring up the third in a bit here):

Security, the VIP Way

My VIP team colleagues suggested this topic. We deal with some pretty large sites with lots of users, and can be the target of attacks by unsavory people, so we have developed security policies and best practices that we have found to be successful. I think I could relay some of these practices and give good examples in an engaging way.

I submitted this as a 50-minute talk, but it could be adapted as a lightning talk. I think this talk is pretty straightforward and would need some creative slide deck management to make it my particular style of engaging.

User Support: Playing to Win

OK, so this one is a long shot—and to be honest, I haven’t written it yet, but it’s nearly-fully-formed in my head. Support has been my career for over a decade now.

I have also played fighting games for a huge chunk of my life, but only in the last few years have I taken playing them seriously and competitively.

Fighting games are about resource management, spacing, timing, and adaptation. It struck me at one point that a lot of that is very similar to how I approach support interactions. I want to find a way to bridge those metaphors in a talk.

This would almost definitely be a lightning talk, and I submitted it that way. The slide deck would be really challenging and enjoyable to create. I’m secretly hoping this one is chosen.

A Third Talk?

Just a bit earlier this evening, I considered submitting a third talk based on my blog post from last night, regarding advice for applying to Automattic. After I wrote it, it occurred to me that a lot of what I talk about in the back half of the post is less specific to Automattic and more interesting in the context of open-source-related companies, of which Automattic is one.

But when it came time to write the abstract, I couldn’t come up with a good way to frame the talk that wouldn’t come across as “hey, you should come work at Automattic.”

The concept I had: I would talk with some other people at other WordPress-ecosystem and maybe even other OSS-ecosystem companies, and gather some more information from them about their workplaces and what they like to see.

In the end, because of where I work, there are optics to consider. Does it come across as a recruitment effort? Some people might look at it and think that it does, especially since I would be referencing a post that’s specifically advice for people who might want to work here. What I would love to get across is that there are lots of great companies in WordPress orbit people can work for, or could start, and I suspect they share these open-source traits. It’d probably be interesting.

But I won’t be submitting that one. I feel comfortable talking on my own space here about the work culture of Automattic and why I love working there (and I do this often because it’s all true), but I’m not comfortable making that the subject of a talk at one of the two large-focus gatherings of people from all of the WordPress community. It could be interpreted in a way I’d rather not evoke if I can avoid it.

How’s The Third Talk Different from The First Talk?

(Thought I’d address it because I know someone will think it.)

To be concise: I think there’s a big difference between sharing best practices concerning the WordPress software and supporting users and giving a talk where my workplace is a focus. Bonus: at VIP, we work in partnership with various agencies and WordPress users, so many of those best practices have developed in active collaboration. I feel comfortable sharing those practices in a broader arena without making it overly Automattic-centric.

Posted On

I hadn’t heard of the ScreenOS backdoor vulnerabilites, which are CVE-2015-7755 and CVE-2015-7756, until last night when I ran into some tweets about Matthew Green’s exposition on what they are and why they are so crazy:

To sum up, some hacker or group of hackers noticed an existing backdoor in the Juniper software, which may have been intentional or unintentional — you be the judge! They then piggybacked on top of it to build a backdoor of their own, something they were able to do because all of the hard work had already been done for them. The end result was a period in which someone — maybe a foreign government — was able to decrypt Juniper traffic in the U.S. and around the world.

And all because Juniper had already paved the road.

Some of his tweets on the situation explain it in even better terms IMO:

And—back to the article—on why this is important to talk about:

For the past several months I’ve been running around with various groups of technologists, doing everything I can to convince important people that the sky is falling. Or rather, that the sky will fall if they act on some of the very bad, terrible ideas that are currently bouncing around Washington — namely, that our encryption systems should come equipped with “backdoors” intended to allow law enforcement and national security agencies to access our communications.

One of the most serious concerns we raise during these meetings is the possibility that encryption backdoors could be subverted. Specifically, that a backdoor intended for law enforcement could somehow become a backdoor for people who we don’t trust to read our messages. Normally when we talk about this, we’re concerned about failures in storage of things like escrow keys. What this Juniper vulnerability illustrates is that the danger is much broader and more serious than that.

At this point, there’s no two bones about it. We need to be using encryption everywhere. And the encryption we use needs to be open source.

Posted On

Avinash Kaushik:

Adobe was hacked recently and of course someone smart is going to analyze the data to find insights. My favourite one was the top 20 passwords used by Adobe users.

38 million records were lost by Adobe, though the original number was said to be 2.9 million. 1.9 million people used 123456 as their password!

Here’s the image he included with his post:

36

Yes, people are stupid and these are ludicrously bad passwords. Shame on them.

But shame on Adobe for allowing users to set these kinds of passwords in the first place. Regardless of the hack, these are easily guessed passwords and could have led to account compromises without too much work.

Posted On

A lot of digital ink has been spilled regarding the supposedly surprising revelation that there is a concentrated effort going on by an apparent botnet to “hack” into your WordPress installation. Some of the better and/or more interesting writeups have been:

It’s important to think about why this attack is happening, and I don’t mean what the eventual goal of the botnet might be. For this attack to be profitable in terms of time and resources, it needs to be worth the effort that is being expended to create it.

Is it happening because the sites in question are running WordPress? Almost certainly not.

It’s happening because users don’t follow good password practices.

I’ll say that again: it’s not happening because WordPress is inherently insecure; it’s happening because you and I have a habit of creating, picking, and using crappy passwords.

Krebs posted a link to the list that’s currently known to be used in this attack, which you can find here. Take a look at it, because if you have had any experience in dealing with access attempts, it will probably look familiar. The vast majority of the usernames that are being tried are admin, and the passwords are by and large passwords that are among the most common passwords chosen by users across every web service in existence, not just WordPress.com.

As the Sucuri blog points out, there are a couple of passwords in there that don’t make a ton of sense compared to the common password list, like these:

6160 [pwd] => #@F#GBH$R^JNEBSRVWRVW
5392 [pwd] => $#GBERBSTGBR%GSERHBSR
5058 [pwd] => %G#GBAEGBW%HBFGBFXGB
5024 [pwd] => RGA%BT%HBSERGAEEAHAEH
4861 [pwd] => aethAEHBAEGBAEGEE%

What this tells us is that it’s not enough just to have a secure password. You need to have more than one. I’ll illustrate with a short story about this happening to me. Remember last year, when LinkedIn and last.fm had a couple of security breaches and they (or at least last.fm) told people it was possible that username and password information had been stolen?

I know from personal experience that they had, because some of my accounts were accessed by people who weren’t me. At the time, I used a “low security” email and password combination, which was exactly the same and used on sites that I considered to be lower in personal priority. Within a few days of the last.fm breach, I started receiving emails from some other services that I didn’t remember asking for. I looked into it, first logging in to my account with EA/Origin (because I knew it was one of those other accounts that shared that email and username combination).

When I did, I found that my EA account was set to display in Russian. It had been accessed using a reverse brute force attack, where the attackers had my combination of email address and password from the last.fm breach and were trying to use it on every web service they could find. Once they knew the combination was valid, it was dumped into a list and used by who knows how many people, trying to see if it gave them access to other accounts.

After going through this—and the associated panic at not knowing which of my accounts were affected—I no longer consider any service or web app I use to be low priority. You shouldn’t, either.

To protect yourself from these kinds of attacks, there are some very simple, slightly paranoid rules you should follow:

  • Don’t use a common password. A good list of these is in this post about common Twitter passwords from a few years back.
  • Try to avoid using dictionary words in your passwords—or if you are, make a passphrase, which is a very secure option.
  • Use a combination of letter case, numbers, and symbols if you’re not using a passphrase.
  • Don’t use the same password for more than one site. I can’t stress this enough. Use a password storage application that has encryption and passwording of its own, like 1Password or KeePass.
  • Use 2-factor authentication wherever you feasibly can. Google offers this for all accounts. For WordPress, there are a few good plugin options, and on WordPress.com, we offer 2-factor as an option for all users.
  • When you set up a new WordPress installation, don’t use admin as your username. Pick something else.
  • For self-hosted WordPress installations, know what your security keys are and how to change them if you suspect a breach.

Krebs posted a link to the password policy page on the WordPress.com support site (for which I feel a bit of pride because I helped write its current incarnation), which goes into more detail and starts with easy stuff you can do and moves on to more complicated options. If you want more tips, I suggest you check it out.

Remember that the best option for protecting yourself from password-based attacks is simply to have good personal password policies and stick to them. For any service that uses a single authentication factor, it’s your job to make sure that factor is created and maintained as secure.

Posted On

Lex Friedman for Macworld has a report on the in-app purchases hack that’s been circulating. The most amazing part:

iOS users who try the hack may find that, in addition to robbing the developers behind apps that they enjoy, they’ve put themselves at risk. “I can see the Apple ID and password,” for accounts that try the hack, Borodin told Macworld. “But not the credit card information.” Borodin said that he was “shocked” that passwords were passed in plain text and not encrypted.

According to Tabini, though, “Apple presumes it’s talking to its own server with a valid security certificate.” But that was clearly a mistake—“This is entirely Apple’s fault,” Tabini added.

Anyone who has done this is fortunate that the first person who found the hack seems to be a pretty nice guy.

And this being the case is shocking.

Posted On

Rajiv Eranki:

I was in charge of scaling Dropbox for a while, from roughly 4,000 to 40,000,000 users. For most of that time we had one to three people working on the backend. Here are some suggestions on scaling, particularly in a resource-constrained, fast-growing environment that can’t always afford to do things “the right way” (i.e., any real-world engineering project ;-). If people find this useful, I’ll try to come up with more tips and write a part 2.

I don’t understand the majority of the information presented here, but it’s still interesting to read. I was particularly interested in this bit though:

Security is really important for Dropbox because it’s people’s personal files. But all services are different, and many security decisions will inconvenience someone, whether it’s a programmer or a user.

For instance, almost every website has a thing where if you enter in a wrong username OR wrong password it’ll tell you that you got one wrong, but not tell you which one. This is good for security because you can’t use the information to figure out usernames, but it is a GIANT pain in the ass for people like me who can’t remember which username they registered under. So if you don’t actually care about exposing usernames (maybe on something like a forum or Pinterest where they’re public anyway), consider revealing the information to make it more convenient for users.