Tag: security

Drop DES Ciphers
My (former) coworker read my recent post about the forward secrecy and noted the following:

@p0pr0ck5: you really ought to get rid of the DES ciphers too.

As it happened I was looking into that!

What Is DES?

DES stands for Data Encryption Standard. It’s a symmetric-key algorithm using 56-bit keys, which means it applies its magic to a block of data at once, rather than one bit at a time.

Back in the 1970s, The National Bureau of Standards (in the US) created DES because it occurred to them that secure data was a good idea. A bunch of brains were invited to meet their proposal for a standard, and of them IBM (yes, that IBM) came up with a winner.

What’s the Problem?

It’s 2017, not 1971, and data is bigger and more complex. First off, 56-bit keys are too small. AES, the current standard, uses 128-bit and 256-bit keys. But perhaps more importantly, we don’t do symmetric encryption anymore. Sending the keys over the same channel you’re going to encrypt is dangerous and easy to snipe.

Back in the late 1990s, a big machine could break a DES key in 22 hours. Today, using a cloud network on Amazon, it could be done in seconds, and be worth it.

Oh and if you’ve heard of 3DES and are wondering if that’s better, it’s not. Remember the massive Target hack in late 2013? A bunch of credit cards were stolen and it turned out Target stored their PINs in 3DES. So no. Not safe at all.

Why Did You Have It?

Because Windows XP is a sack of shit and up until last year, I had to support it.

Seriously, that was it. Now that everyone I know who use some XP (and NT) are on modern OS’s (or blocked from the server… or dead) I don’t have to worry so much.

How Do We Ditch It?

Remember, these are the default chiphers:
```
ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
```
In there you have the following: ECDHE-ECDSA-DES-CBC3-SHA, ECDHE-RSA-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, and DES-CBC3-SHA

While I already have !DES in my cipher suite (as I posted a few days ago), I should remove it fully. But that also means in the Pre Main Include section, I need to change my value for SSLCipherSuite to match!

When I tested, I noticed that I was still pulling a TLS suite with 3DES: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA

To fix that, I changed HIGH to +HIGH:+MEDIUM:-LOW and that gave me the following:
```
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:+HIGH:+MEDIUM:-LOW:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4:!DSS
```
The -LOW is the magic sauce to say “Don’t use anonymous insecure ciphers.” when you’re on cPanel, you see.
13 February, 2017
cPanel and Two-Factor Authentication

I’m talking a lot about security. There are reasons for that. If you’re not keeping your online behavior safe, you’re in for some headaches. Two-Factor Authentication (TFA or 2FA) is one of the better solutions as it protects you by requiring you to have a password and a physical object in order to log in.

WebHost Manager (the admin part of a cPanel server) has this.

Let’s Do This Thing!

Go to WHM Home » Security Center » Configure Security Policies and check the box for Two-Factor Authentication.

Next, go to Home » Security Center » Two-Factor Authentication and move the slider to enable:

Click on the tab for “Manage My Account” and set up TFA for your root account.

The Problem….

Oh there’s a problem? Yeah, and it’s the age old problem of TFA. You can’t enforce it. I mean, you can’t turn it on for everyone and walk away singing the praises of your success. You have to turn it on as each user. That means they have to turn it on. You can’t even require it.

None of that means you shouldn’t do it. Everyone should do use TFA for their server connections. I use it for my servers and for my Gmail accounts. Protect yourself.

Extra Credit

Did you know you could turn on TFA for APIs on your server as well? Yeah.

3 February, 2017
SSL Security: Forward Secrecy
Forward secrecy is actually what it sounds like. It forwards on secrecy. This means that the secret keys you have won’t be compromised even if the server’s key gets hacked. The way it works is by constantly changing things. Basically it’s rotating its encryption forever.

“You’re constantly generating new keys for new messages,” says Nadim Kobeissi, the creator of Cryptocat, one instant messaging app that was early adopter of perfect forward secrecy. That means if a user’s device is stolen or hacked and eavesdroppers steal a decryption key, it doesn’t matter. “The latest message gets compromised, but any message prior to that message or after it can’t be decrypted,” Kobeissi says.

This is a good thing to have on your own server, as it means if a secure transaction (like an ebook sale) is compromised, only that one instance is impacted. No one else gets hacked. No other part of the sale is affected. You minimize damage considerably.

Let’s do this thing!

On Monday we killed off RC4 by going to WHM Home » Service Configuration » Apache Configuration » Global Configuration and changing the cipher suite to this: ALL:!ADH:!RC4:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP:!kEDH

In order to properly handle perfect forward security, we have to reorder things. Instead of using ALL, which calls everything, we need to put the ciphers in a preference and omit the ones we don’t want. That gives us this:
```
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4
```
Awesome. Once we set that, and restart Apache, we go to Service Configuration » Apache Configuration » Include Editor » “Pre Main Include” and pick ‘All Versions’ from the drop down. I’ve edited this section before, when adding HSTS support. But then I edited pre_virtualhost_global.conf (“Pre VirtualHost Include”). This is just a different section.

In the Pre Main Include section, put this:
```
SSLProtocol all -SSLv3 -SSLv2
SSLHonorCipherOrder On
SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4
```
This forces the SSL protocol to v3 and then v2, but then it demands the order of the ciphers be honored.

Restart Apache and you’re done.

Testing it

If you want to test, go to ssllabs.com/ssltest and you should see something that says A or A+. If you don’t have it right, you’ll max out at an A-.

This site? It’s currently an A+, however that target is always moving. Keep safe out there.
1 February, 2017
SSL Security: Killing RC4

In the middle of debugging what turned out to be an unrelated problem, my friend James pointed out that my server was throwing a warning about the RC4 cipher.

Ciphers?

When you want to transmit secure data, you use a cipher to encrypt the data. RC4 is a (hah) cipher. It generates a stream of random bits and bytes (they’re not really random) and combine them with plain text using a pattern to make an encrypted message. The secure connection unravels the bits because it knows the cipher too.

Ciphers only work if no one knows how to crack them. That isn’t the case with RC4 anymore and it was hacked. Sad news. Time to disable it!

Disable it!

Why was it enabled at all? As it happens, it was enabled on my servers for browsers that can only use it. Old browsers. The funny part is that those old browsers can’t support SNI (which is what lets me have multiple certificates and multiple https sites on one IP address), so the domains were broken anyway.

To disable, I went to WHM Home » Service Configuration » Apache Configuration » Global Configuration and changed my cipher suite to ALL:!ADH:!RC4:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP:!kEDH

The !RC4 is the part that says “Not this one!”

Restart Apache and you’re safe to go!

30 January, 2017
Secure Your Shit

Ignore the fact that Google’s going to downgrade your sites if they’re not HTTPS soon. That’s not what I’m talking about.

I’m a strong proponent of Net Neutrality and Freedom of Speech. I certainly intend to speak up and write and protest in the coming weeks and months, just like I have my whole life. I look at the world and I see things that need changing. So while this blog is about technology and computers and the Internet and websites, it has an impact on my political actions.

Or rather, it’s that my political actions impact this site.

People try to hack me all the time. All the damn time. Within the last 24 hours, over 400 people have tried to break into my ‘root’ account. It’s not named root. Good luck there. But the point is that people do try to hack me. They attack my WordPress install, my server, my email, my social media accounts, and my home wifi. I suspect the last one is my neighbor being stupid.

This means I know that speaking up will make me a target and, because of that, I need to secure the hell out of my stuff. And that means using Two Factor Authentication.

Use Strong Passwords

I use 1Password to both create strong passwords and securely store them. A popular alternative is LastPass, but having used both, I find 1Password easier to use. Regardless, use them. My passwords are things like 4seqKD)CsbG=iQnVoirwZ77+ which I hate typing in when I have to change them, but thankfully with browser extensions I not only don’t have to, but I don’t know my own passwords.

I can just generate and go.

Secure your Email

I know a lot of people use Gmail. I pay them for email right now (long story, tl;dr no one does spam better). That doesn’t mean I fully trust them but, since I pay them, I know I have a different relationship than the free Gmail one. Still I use 2-step verification on gmail.

If you need super secure and private email, ProtonMail is the way to go. Sadly it’d be $30 a month for my multiple domains. I wish they’d charge per email address, but that’s another issue.

Secure Your Panels

Everyone logs into web hosts the same way. We use a panel. It might be Plesk or cPanel or a home-grown system. It doesn’t matter which. Whichever one you use, make secure passwords, don’t share them with anyone, and if at all humanly possible, use Two Factor Authentication. If your webhost doesn’t offer it, leave. I know what I just said. If they don’t offer some method of verification, they’re not safe.

When you secure your panel, make sure you also secure your billing stuff. For example, I use LiquidWeb. They use cPanel and I activated Two Factor Authentication for that. But they also have a proprietary manage site where I log in for billing and server allocations. That also needs security. Make sure you do it on both.

Secure Your Blog

If you use WordPress.com, Turn on Two Step Authentication.

If you self host WordPress, use a plugin like Two Factor. That’s the feature project’s plugin that hopes to be added to WordPress core, so it’s a little rough around the edges. While I do have fundamental issues with 2FA being enabled by default for all users of a blog, it’s because I understand that most users are not technical.

It’s a double-edged sword. If we don’t teach people to be a little more technical to be a little safer, they won’t become safer. On the other hand, with things like 2FA and WordPress, there’s no real way for them to contact a person for help. If you turn it on, then everyone who locks themselves out gets to either call their webhost (who isn’t responsible for that) or a young relative (who didn’t sign on for that) or post in the support forums (who did sign on for that, but still).

Secure Social Media

Twitter, Facebook, and Tumblr have Two Factor authentication. Use it.

Twitter’s sucks, by the way. It’s text based, which means you can only use it via text-messages. Facebook requires you to use texts, but allows it to be a backup to a code generator like Google Authenticator.

Be Secure

The moral of all this? Be secure.

23 January, 2017
Chronic Infections: Blacklisted

If you use Chrome, you may be used to those warnings about how a site is dangerous (or hacked) and maybe you shouldn’t visit it. If that happened to your site, you’d get an email if you use Google Webmasters (which I recommend you do), and then after you clean it up you can ask for a rescan. Or if you don’t, Google will rescan the site after a while and if it’s clean, carry on.

That ends.

Google found out something we’ve all known for a while, and that’s people can be evil and malicious. And what they’ve done is created a ‘repeat offenders’ blacklist, for sites that clean up only to allow themselves to be reinfected. As they say, “Sites that repeatedly switch between compliant and noncompliant behavior within a short window of time will be classified as Repeat Offenders.”.

This is dangerous for users when a hack is outside their control.

The number one cause of reinfections is not plugging the hole. In the case of things like WordPress, it’s down to upgrading everything, deleting anything with a known hack or backdoor, and locking down users. Hacks like Pharma, where the database becomes vulnerable and repeatedly re-infects a site, are thankfully rare for WordPress, but the same cannot be said of other CMS applications.

And far worse than that is this. By which I mean what happens when your ad network is the cause of a hack?

Recently, a friend of mine was hacked and got upset that his webhost’s scan of his site said it was clean, while Google did not. In looking at the site, I pointed out the hack was from his ads and not the files on the webhost. His webhost’s scanner didn’t hook into Google’s Safe Browsing service so of course it didn’t come up. He was pissed off about the host missing it, but once I explained why, he realized the magnitude of the issue.

By adding an ad service to your site, you’re effectively trusting their behavior. And some ads are pretty scummy. While Google Adsense (and others) are usually pretty quick to kick-ban those idiots, the damage will be pretty hardcode. It takes but a small moment for a high-traffic site to serve up enough malware to make that attacker’s plan worthwhile. And worse, if the same kind of person get in again and again (which happens) and your site is infected multiple times, you will end of on the shit-list.

Thats enough FUD on it. Let’s talk about mitigations.

We’re all going to need to get better at figuring out where the malware is from. All of us. Security companies are going to lose money if they can’t stop repeat attacks, and since even the best firewall can’t stop shitty ads, all our scanner tools are going to need to be better about detecting what the cause is and where it’s from. This is going to be hard, since the ad may be gone by the time the site scan runs.

Google will need to tell us what they know a lot better. I don’t know if they will, but they’ll need to figure something out. At the same time, I get why they may not want to. It tips the hand to tell malicious people exactly how you caught on to them, but at the same time telling people “Your ads are serving up malware” would be impactful and hopefully not too harmful. I’m on the fence there.

Finally, we all know ads on the internet are shit. We’re all barely making money off them. So if you get infected by an ad vendor twice, it’s time to turn those ads off and look for something new. If that ad vendor is Google, open a ticket with them and provide evidence that they’re hurting your SEO and could cause you to get on that repeat offender list.

Yes, this is making a hard decision, but it’s one you must make. If you’re being betrayed by your ads, you need to quit them.

16 November, 2016