Tag: security

The Security of a Lifetime License

A few years ago, before I started working for DreamHost but after I decided I wanted to do WordPress all the time, I bought the StudioPress All Themes Package. For $500, it gave me a lifetime access to all their themes, all their future themes, support, and more. So I tucked away all my ad and ebook income for a while and bought it the day before a 50% deal hit. Of course, right? Brian being a wonderful guy, saw my amused tweet and credited me the difference.

Since then, I’ve pretty much been a nothing but StudioPress shop. Almost every site I run on WordPress is using StudioPress themes. I’ve gotten free upgrades for all their themes, free versions of the ‘pro’ themes (all the HTML5 friendly ones), and it’s very much been worth it to me.

But licensing is a strange subject. Chris Lema recommends charging annually (instead of monthly). And while I have a lifetime subscription, the unlimited free support will be leaving this world soon. From what I’ve heard, this only impacts support. To be honest, I’ve filed less than ten support tickets in five years. And it’s not because I’m savvy. There’s very little that I need help with to use Genesis themes. They have pretty darn good directions on how to reproduce their demo sites, they have code snippets, and they have a friendly self-help forum.

Basically, this code is tight. Right now I’m using the Generate Pro Theme on this site, but I also bought Utility Pro theme from Carrie Dils (worth it). The child themes rarely need updating, and all I ever have to worry about is the parent Genesis theme being updated, which is easy as pie. They have their own updater.

My friend Amanda Rush (also a StudioPress fan) wonders if this heralds the end of days of unlimited forever support and licenses. I suspect so. Will I be annoyed if I have to start paying for updates? Maybe, but mostly because I have a serious concern about security.

Let me paint a picture for you. I get a free parent theme or plugin, it could be Genesis (the StudioPress parent theme) or WooCommerce (a popular ecommerce plugin), and I purchase an ‘add on’ of a child theme or an extension plugin. I pay for a year, and I’m happy. The add-on does what I wanted, I get my updates, and everything’s cool. Then one day, 370 days later, there’s a major issue. A massive security hole and suddenly my site is vulnerable!

My license has run out.

Do I get the update or not?

Do I get notified of the update or not?

I’ve seen this play out over and over again with sites like CodeCanyon and ThemeForest. How do people who have purchased a product get alerted properly and given the ability to update? We’re spoiled because if Jetpack or WooCommerce itself has a critical hole, those plugins are free in the WordPress.org repository. And I know, from working on that team, that if there’s a big enough issue, then the free plugins get updated and the update is pushed out to everyone. It’s rare, but when it happens, it’s for the benefit of everyone involved.

The sad truth is most one-off shops can’t do that. WordPress.org can update all branches of your plugin. If you’re properly using versions for your plugins and themes, then you can release version 2.3.1 to fix a bug, but also fix that bug on 2.2.4 and 2.1.9 and so on. And yes, WordPress can push those branches (2.3 and 2.2 and 2.1) so even people on older versions can get fixed.

To the best of my knowledge, no one else does that yet.

And, perhaps worse, some won’t even consider letting you have the security update because your license isn’t up to date.

All that said… Should you buy it, knowing you may not get support and updates forever? Yes. Right now, the StudioPress Pro Plus All-Theme Package is on sale. $262.46 for every theme plus third party themes. The sale goes on until the 16th, so grab it this weekend.

It’s an investment I’ve never regretted.

13 November, 2015
HTTPS and WordPress
Really there’s a right way and a not-quite-as-right way to handle HTTPS on WordPress. It’s not that hard to do, and if your whole site is going to be HTTPS, then the easiest way is to change your home and site URLs to be https://example.com/ and put define( 'FORCE_SSL_ADMIN', true ); in your wp-config.php file. Then you should (if this is an existing site) search your database for the old HTTP url and change that to HTTPS.

Seriously, that’s it. That tells WordPress to be HTTPS all the way and you’re done. Of course, that doesn’t actually work 100% for everyone, because there are some silly plugins and themes that do things like this:
```
add_action('wp_enqueue_scripts', 'enqueue_google_maps');
function enqueue_google_maps() {
  wp_enqueue_script('google-maps', 'http://maps.googleapis.com/maps/api/js?&sensor=false', array(), '3', true);
}
```
The problem there is they’ve defined the script as HTTP and if your site is HTTPS then you’re going to get mixed content messages. And the real issue here is that means your connection is only partially encrypted! That non-encrypted content is accessible to sniffers and can be modified by man-in-the-middle attackers. This, clearly, is not safe anymore. The right way to do your enqueues is with protocol relative URLs:
```
  wp_enqueue_script('google-maps', '//maps.googleapis.com/maps/api/js?&sensor=false', array(), '3', true);
```
Alternately you can just use the HTTPS url, because that won’t break HTTP visits and it won’t make anything less secure.

But. Since you really can’t go in and edit all your themes and plugins, the plugin WordPress HTTPS is the way to go. That can force everything around. I know it’s not updated in a long time, but it still works. I keep thinking I’ll fork and clean it up… Well in my free time. The point of that plugin is that it lets you force everything to HTTPS, and will rewrite things on the fly. It’s a good idea.

Instead of using the plugin, I’ve seen a lot of people do this in their .htaccess:
```
RewriteEngine On 
RewriteCond %{SERVER_PORT} 80 
RewriteRule ^(.*)$ https://example.com/$1 [R,L]
```
In and of itself, this isn’t wrong. This forces everything HTTP to redirect to HTTPS. The problem is you’re still actually sending data from WordPress over HTTP first, and you’re right back to opening up to man-in-the-middle attacks because the data from WordPress goes from HTTP first and that’s, say it with me kids, insecure!

Now that said. This should be okay for most things. The POST calls should be sent securely, and all you should see on the return end is everything after that 301 redirect, but we can’t be absolutely sure about this. My buddy Jan used mod_substitute to force HTTPS (back before he moved to nginx). His code looks like this:
```
<Location />
 AddOutputFilterByType SUBSTITUTE text/html
 Substitute "s|href="http://example.com/|href="https://example.com/|"
 Substitute "s|href='http://example.com/|href='https://example.com/|"
 Substitute "s|src=\'http:|src=\'|"
 Substitute "s|src=\"http:|src=\"|"
</Location>
```
In doing this, he doesn’t need to worry about the HTTPS plugin I mentioned, because it forces everything with a src attribute to be protocol relative. He also doesn’t have to search/replace his content if he doesn’t want to, which makes switching back easier. If you wanted to do that. But as Jan pointed out to me, he switched to nginx because it’s easier and supports variable substitutions.

Should you use .htaccess or nginx to force https instead of a plugin? That’s totally up to you. I use the plugin since I trust it to only mess with WordPress and not anything else I may have lying around. Also since my domains are often more than just WordPress, it’s a little easier for me to segregate their control. The flip side to this is that WordPress doesn’t redirect http traffic.

By this I mean if you turn your whole site to HTTPS properly, you can still go to http://example.com/this-is-a-page/ and WordPress will load it as HTTP. This is and is not a bug. WordPress is (properly) trusting your server to tell it what it should be. Your server is saying “Be HTTP or HTTPS! Whatever!” Now there is a trac ticket to have FORCE_SSL really force SSL but that’ll be a while because there are a lot of complications in that change.

So yes, for now, I would use .htaccess to add an extra later of SSL forcing, but with a bit of caution. If you’re proxying HTTPS (like you’re on a Varnish cache behind something like Pound or nginx) then you may need to use this code for your .htaccess redirect.
```
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
```
The reason for this is Apache can’t always see SSL if it’s not in charge of it (because it’s proxied or handled by a load balancer), and to teach it where it really lives. The trick there is the code I just showed you may not be right because every server’s a little different. There’s a great StackOverflow post on the problems of redirect loops while forcing https that you should read.

Good luck, and safe HTTPSing!
9 September, 2015
Encrypt My Site, Please!

By now everyone running a website has heard about how Google gives sites running SSL a bit of a bump with search rankings. It’s been a year since they started doing that. The bump is not significant enough to impact most people, but making all the things HTTPS is still a good idea.

It’s really all about security. I personally use HTTPS for the backend of my WordPress sites. Logins and wp-admin are all secure. The same is true for my MediaWiki site and my ZenPhoto gallery. I access things securely because the data I transmit could be important. Sure, it’s just passwords and such, but then you look at my site where I sell eBooks.

That site is on the same server, the same account, and the same WordPress install as this one. You bet your ass I’m making it all secure. But this comes at a cost.

The invention of SPDY aside, HTTPS is rarely as fast as HTTP. It can be difficult to set up caching or implement terminations like via Pound or Nginx in order to cover for the fact that Varnish doesn’t cache SSL. These things aren’t impossible to do. They’re just harder. And they’re generally going to be slower than plain old HTTP.

The question has never been if they can or cannot be done, but if they can by entry-level people. Certainly we can say “If they’re not using SSL for all the things, they’re not ready for a great volume of business” and use it as a demarcation for things. And when we’re communicating our private lives, we should certainly consider this. But then, this site, where only I log in?

Do you need SSL? Would it make you feel better or more secure? All you can do is comment. Do you need the feel-good? Do I need the extra security? If I decide yes, then I have to consider the weight this puts on my site. I have to consider how best to cache the content.

I also have to think about how to get a certificate and SSL certs can be the biggest Internet scam out there.

It’s how much for a multi-domain, including subdomain, SSL cert a year? A few hundred? It’s a bigger hassle than the EU Vat drama. It’s expensive, it’s a hassle to get set up, and install. Now thankfully, next month we’re expecting Let’s Encrypt to show up and they’ll make the cost less prohibitive. It doesn’t make the drama of installing the certs any better, but it’ll lower the bar for people who are trying to make things secure.

Yes, you can get StartSSL for free, but it’s not as simple as all that. When all you need is one certificate, it’s only about $10 a year and that’s fine. When you start getting into the need to secure all the things, it’s a mess.

What has to happen next, though, is for sever software to step up. Apache and nginx are both far faster now than they have been, but they’re our ultimate breakpoint. PHP has to push itself to handle things better and faster, lest we run over to HHVM. We are getting better of course, but if we want everyone to be on HTTPS, we have to make it easy.

Not easier.

Easy.

The bar is still too high for the majority of people, and that’s a problem. Either we start offering hosting services to handle this or we start making the software easier. But we can’t just say “Oh, it’s simple to make your site HTTPS and fast.” because it’s not.

12 August, 2015
Everything Is Vulnerable

Every other day we hear about a tool that has a vulnerability. It’s been the servers we use, Flash, or Silverlight, or the Jeep that was hacked.

This Is Not New

The idea that hacking like this is new or novel is, let’s be honest, naive. In the 1800s, people used to hack into the newly born telephone system. Before that, we didn’t call it hacking, we called it conning. Yes, the confidence games people played to get others to trust them and then rip them off is the same idea as a hack.

A hacker is someone who finds a weakness in a computer system and exploits it to some benefit. Early bank penetration tests, the ones to see if they could get at your money, were as much social engineering as technical skill. A ‘hack’ is simply something taking advantage of an exploitable weakness. This is not new to anyone or anything.

The Scale Has Changed

The primary difference between the hacks of old and the ones today is the scale of those hacks. Hacks used to be very personal for a reason: there was no world wide network. Your hacks had to be local and careful, because no one trusted the stranger. You can to build up credibility before taking your win. Of course, now we have near instant communication with the entire world. That means it’s milliseconds to access the server of someone in Africa, all from your happy NYC Starbucks.

The difference is that now, when someone says “And Flash has a security vulnerability” the number of people impacted is in the millions. And the number of people who can be hurt by it is, similarly, high.

We’ve spend years trying to create a global internet, and in doing so we’ve quickly shared communicable internet diseases with each other.

Nothing Is Unhackable

My boss and I were chatting about the ways one might hack the stock exchange, and he pointed out that one of the ways they slowed down trades was by having a really long cable.

Credit Stefan Ruiz for The New York Times

This cable, and yes it’s real, is literally used to create a small delay in processing of orders, to level the playing field with traders. In short, it makes sure that the trades from across the ocean run at the same speed as the ones for the people in the room of the New York Stock Exchange. Each additional mile of fiber-optic cable adds 8 microseconds to a transaction, which adds up to 304 microseconds. Among other things this is hard to hack. You can’t send a software signal faster than it goes (physics being what it is), so it made things harder to hack.

The next Mission Impossible movie will involve Tom Cruise being slowly lowered into the box with that cable in order to shorten it invisibly. Only Cruise can do it because only he is small enough.

That was my joke. But it’s actually rather demonstrative to the point. You can physically hack things as well.

Analyze The Risk

To quote my father, “What can go wrong? How likely is it? What are the consequences?”

That’s why I don’t own a wifi pluggable garage door or thermostat. Do I think they’re cool? Yes. Do I think they could make much of my life easier? Yes! But they’re new and they’re toys, which means people spend a lot of time poking at them and digging into the underlayer to see how and why they work. Which means people are finding hacks daily.

That means the likelihood of someone figuring out how to use my thermostat to drive my budget through the roof is pretty high. Someone already did that to his ex-wife if that review is to be believed. Of course he had the access in the first place, but it proves one point. If you get access, you can do things.

Change it to my garage door? Or my front door? Say good bye to my things. I know I’d be a target because I’m using the pricy toys to start with.

Educate Yourself

If you can not do stupid things, the odds of you being hacked are low.

By stupid things, I mean using insecure passwords. I mean logging in on public WiFi to do your banking. I mean installing any old plugin on a WordPress site running a store.

The things you know are dangerous.

Don’t be stupid. Make backups. Be prepared for disaster.

10 August, 2015
Trust the Changelog
Recently there were a couple WordPress plugins with fairly major security fixes. But you wouldn’t know it by looking at their changelogs.

The changelog is a section of a product’s readme that describes what changed. For most people, it’s a list of items like this:
- Added feature X
- Corrected typo
- Security fix
The problem many people have is that last one is often left rather vague. I’m guilty of this myself. In a recent fix, I simply said “Security fix: Sanitizing _POST calls to prevent evil.” and “Security Fix: Implementing nonces.”

The primary reason we keep change logs a bit vague is because we don’t want to open the door to alert hackers as to vulnerabilities. People don’t update their code right away, so every time we publicize a security issue, the people who haven’t updated immediately are at greater risk of being hurt.

But if we don’t tell people how important it is to update, how do they know how important it is to update?

There’s the real issue. There’s not yet a proper balance between “You should upgrade as soon as possible” and “You need to upgrade now, or you’re doomed.” My security issue was only accessible by people with admin access. It would be possible to trick an admin, with a cleverly crafted page, but … The effort it took me to apply a nonce check and sanitize things is minimal. From my end, it’s very minor of a fix. From a user’s end, it’s an exceptionally rare hack and unlikely to occur.

The right answer here is “Always upgrade to the latest version of code as soon as possible.” The problem is “as soon as you can” gets bumped out if it’s not mission critical. A patch that adds in a filter? Not a big deal. A patch that secures my site? Should be a big deal. I would argue that any time anyone says “This is a security fix” then you shouldn’t have to concern yourself about how likely the hack is to impact. Instead, security is a watchword to tell you to update the software “immediately.”

Which brings us to two agreements we need to start making with people. The agreement of developers to do things ‘easier’ for users and the agreement of the users to trust developers. If we want people to upgrade, they have to trust us. And if they’re going to trust us, we have to be reliable and consistent.

As developers, we promise not to flag something as a critical security fix that isn’t just security fix. If there’s a major issue with our code, we will push a patch as soon as possible that only deals with that issue. There will be no feature changes, no little fixes, no minor tweaks. A security release will only be a security release.

Furthermore, to enable people to update properly, we will properly use semantic versioning. This will allow us to update minor releases as far back as logical, because you can know that version 1.2.8 is the latest version of the (old) 1.2 branch, and 1.5.3 is the latest of the (current) 1.5 branch. The next time we add in new features, we will properly version our code as 1.6 so that you know what branch is current.

As users, we promise to trust your security-only releases and upgrade our copies of your code when a minor release that is a security issue is released. If you release a version 1.5.4 and not a version 1.4.4, we will trust that either the 1.4 branch is not subject to this security issue, or the fix could not be back-ported. If you inform us that we must upgrade to the 1.5 branch because there’s no way to secure 1.4, we will expedite our upgrade.

In order to enable ease of upgrade, we will not edit our code to make it impossible to change. We will properly use functions and actions and filters and hooks. We will make regular backups as well as immediate ones before upgrading.

Of course… That’s a perfect world. But I’m going to do my part as a developer and start versioning better. If I do that, and if I as a user hold up my other end, then we can get to a place where all disclosures of security issues happen in tandem with a release, as we know that everyone will upgrade immediately.

A place of trust.
24 June, 2015
How Hackers Find You

I made a bold statement that pissed someone off. I told him that hackers don’t use Google to find vulnerable sites and attack them.

They don’t, you know. Sure, they can do that, and I’m certain some of them run scripts to collect a list of people to hit up, but that’s incredibly inefficient. The only kinds of people who do that, who get lists of websites to touch, are people who for good reasons need to do that. Like maybe running a script to ping all your domains and trigger a WordPress automatic update by kicking off cron. And sure, a hacker could use a tool like WPScan to collect all the awesome information. But they don’t.

But like I said, doing that is inefficient. The longer it takes a hacker to find you, attack you, and break you, the more likely it is that you’ll be upgraded. With WordPress in specific, the moment that hacker hits your site, your WP install has probably already begun the upgrade to make you more secure. Assuming that, what a hacker wants, what they need, is to hit you once, hit you right, and hit you hard.

What a hacker really does is use that annoying BotNet to distribute an attack on as many websites as possible in one blast.

Do All Hackers Do This?

I should clarify something. When I say ‘hackers’ I don’t mean a specific person who is out to get you, in particular, and wants to destroy your site. Those attacks take as much tech smarts as they do social engineering. When I talk about hackers who are taking down sites, I mean the ones who know about a plugin or theme or core exploit to your site and are going to en masse blast the hell out of the internet to take ’em all down or leave their backdoors for whatever they do with these sites. Perhaps I should call them script kiddies, since many are.

Why Do Hackers Do This?

I have no idea.

It used to be we hacked sites to prove we could. Then we hacked them to get in and get information we wanted. Then … somewhere along the line we started to hack to deface and leave viagra links. I don’t know what ‘good’ the hackers get out of the end result. It doesn’t make sense to me, but then again, I don’t understand why people buy most ‘as seen on TV’ things.

How Do Hackers Find Your Site?

One (kind of cool) thing they can do is, once they find one site, using a tool like SameIP to collect a list of everyone else on the server. That’s great for attacking people who are on shared hosts because they all have the same IP. And once they have your domain on their own list, they keep it and will hit you forever.

But what if they just want a list of all 23% of the internet running WordPress? It’s not that hard. BuiltWith, for example, has a list of many of the WordPress sites.

Certainly it’s not that hard to do. There used to be a site called Hacker Target that had a list of all WP sites: https://hackertarget.com/100k-top-wordpress-powered-sites/ The URL doesn’t work anymore but the idea is there. One could take such a list and just attack it.

Similarly, if you happen to be on an insecure server, one could hack the server and from there collect a list of all domains (since the server has to know it’s domains) and, in the case of a very insecure server, get all the domains on the network, and attack all of those. The shell commands aren’t all that terrible.

The point is, both of those methods are far, far, faster than just grabbing a google for ‘this plugin’ or even ‘this error.’

How Do Hackers Find Out What You’re Running?

This is where people step in and say “WordPress shouldn’t announce it’s version to the masses!” It should, because of what I say the next section (see “Do Hackers Care What You’re Running?”), but the short is that your site content tells them. They can run scrapers to pull your site data, the layout, the way files are stored, and they can tell. It’s like figuring out what car you’re driving.

In fact… Think about that for a second. What kind of car are you driving? Does having the car logo on the car make it more or less secure? It may, if there’s a specific ‘hack’ for your car, but the trained professionals will still know, even if you pull off the logos, so in the end, you’re not really protecting yourself.

Do Hackers Care What You’re Running?

No, they don’t. Sorry. They don’t. Once a hacker has a list of websites, they don’t care if you run WordPress or Drupal or Joomla or Ghost. They’re going to attack with what they know is vulnerable and keep at it until they have a success. Then they take that success and leverage it to get to the next site. And on and on.

So when you get hit by 100 bot-net computers, being tagged for timthumb when you don’t even have it installed, that’s what’s going on. They do not care what you’re running.

How can you protect yourself?

Use a good host who cares about security. Use up to date versions of all web tools and their extensions. Follow those tools and get updates regularly as to any security issues with them.

WordPress is not “Set it an forget it.” You have to keep paying attention.

3 June, 2015