Tag: security

Making a Stand Alone SQL Account

One of the ways to secure your web apps is to limit the damage they can cause. When you create a database for a webapp, you have to provide a user ID and password to connect to the database, logically enough. Illogically, most people just use the same username and password they use to SSH into their server. After all, it works.

The obvious problem with this is that if someone gets access to your files (via a security hole in your webapp or your webhost), they now know your server password and ID, and can get in and cause serious damage.

But what if instead of using that normal ID and password, you made a special one that only was used for SQL. You couldn’t log in with it, you couldn’t FTP or anything except play with SQL. Then, even if they got in, they couldn’t delete your files! That’s really simple.

cPanel

If you’re using cPanel, just go in to the MySQL Databases screen and add a new user. I like to use something totally obvious, so I can remember it, like ipstenu_sql.

For those passwords, I tend to use the generator to make something like m}+akwQN=&)!, not because I feel they’re more secure (I prefer pass-phrases, like ‘donkeyvanillatapdance’), but as a reminder for me not to use it for anything but SQL. Hang on to the password right now, though, you’ll want it in a minute.

Then you add the user to the databases. Back on the main MySQL page, there’s a little selection to Add User to Database which is really obvious to use. Pick your user and your database.

Clicking Add will take you to the privileges screen:

Give the user ALL privileges, as you may need this later on.

Plesk

It’s just as easy in Plesk. Once your new database was created you, were automatically brought to the area to create the New Database User. If you didn’t do that, it’s okay, just go back the main database page and find the datase you want to add the user to (in this case, it’s LovePlesk_NewDatabase). Click on the Add New Database User icon, fill in the information (remember to save your password!), and click okay.

Plesk should automatically grant the user ALL privileges.

Updating Your WebApp

Once you have the new user made, all you have to do is edit your config file (i.e. wp-config.php for WordPress) to use the user and password, and hit save.

Now you’ve made your install a little more secure.

3 May, 2012
Phishing Games
One night, not so very long ago, I got a scam email that reminded me how few people actually pay attention to these things. It’s funny, but we’re all pretty lazy about these scams. You rarely get them from your real banks and money places anymore, or they’re very obviously not real, so you ignore them. Far more people fall for cold-calls on their cell, you know, like ‘This is Mary from Cardmember Services, calling about…’ And I always just hang up. But with so many emails, a lot of us blindly follow them. We click a link, we go to the site, and we don’t think.

This not thinking lead to a few WordPress developers being phished. This is not being ‘hacked’, this is a simple ‘You accidentally gave someone your password’ type mistake. While sites do the best they can to protect you from yourself, we can’t stop you from posting with your real name and not your handle (someone did this recently and asked me to remove the post, which I did), and we can’t stop you from not paying attention.

So we repeat this over and over again. Read the email, look at the site you end up on, use your brain.

Here was the email I got (one of three copies, from two separate email addresses):

Dear WordPress Plugin Developer,

Unfortunately, a plugin you are hosting has been temporarily removed from the WordPress repository. We’are going to manually review your plugin because it has been reported for violating our Terms of Service. If your plugin is not approved by this review then your plugin will be permanently removed from the WordPress repository.

You can check if your plugin has been approved or rejected at

http://wordpress.org/extend/plugins/my-plugins-status/

Four things were wrong with this.
1. The email did not come from plugins@wordpress.org – the only official email for plugin yanks.
2. The email didn’t come from someone I know on the pluginrepo ‘team.’
3. None of my friends who work for WP poked me directly (and I’m fairly sure Otto, Nacin or Mark would have).
4. The email source showed the wrong URL.
I quickly did a few checks on the email source, traced it back, verified it wasn’t WordPress, posted on the forums, and alerted the masses. Because ignorance is where this sort of thing festers. I’m a little impressed, though, since I’ve not seen a phishing attempt aimed at WordPress like this before.

Clearly it’s time to go over a quick reminder about what phishing is, it’s goals, and how it works.

Phishing is when you try to get someone else’s login credentials by mimicking a real site, so you can log in as them and do naughty things. It works by having people not pay attention to a URL when they go to a site. PayPal was an early hit on this, and they finally said “We will never send you an auto-login link or a link to our site in our emails. Just go to paypal.com and log in.” I don’t know if they still do it, but it was a very smart idea.

Too often we blindly trust our emails. The email appears to come from our bank? We click the link, log in, and … hey, it didn’t work? Banks are a huge target for this, and as I work for one, I’m very familiar with making sure we’re not phished. I mean, an email like this looks pretty safe right?

That link, if you’d clicked on it, would take you to a fake site. Now some of those fake sites are smart, and when you enter your ID and password, will redirect you to the real site’s bad password page! That would make you think you only typoed, which happens to all of us.

You may have noticed that most banks and money-type places have you enter your username and then take you to a page with a picture and a passphrase. As long as those are yours, you know you’re on the right site. That helps take care of a lot of attempts, but when you’re faced with something like a phishing attempt on WordPress, there’s less security because there’s less at stake. A bank can make it annoying and inconvenient to log in and get your money and you’ll put up with it because, well, it’s your money. You’ll put up with a lot to get to your money.

But if you have to jump through the same hoops to log in to a forum, or check in code to open source, you’d probably walk away. This is a complicated problem, trying to balance out the needs of the many and the protection of all. I’m not going to delve into possible answers, since they’re always going to be specific to your community.

Also, you can usually easily spot the fake emails. Here’s one I got today:

This came from “Delta Air Lines – support_8312@delta.com” which looks ‘legitish’, but as soon as you look at the email body, it seems weird. No real airline sends out your tickets in a ZIP file for one. Without looking any further, I know this is fake and I can delete it. But what if they’d sent a link? Would I have clicked on it? Again, no, since I’ve only been to Newark twice in my life, and I know I’m not going any time soon, but that’s not the point. The point is the email would have been less off if there’d been a link. If I’d really been concerned, I would have looked at the email headers, but before we jump into that, let’s review what you can do!

The rules to not be phished:
1. Look at the URL before you enter your password and ID.
2. Copy and paste those URLs, never click.
3. If the email looks ‘off,’ don’t click.
4. If there’s an attachment and there isn’t normally, delete the email.
That’s really the best you can do for most people. The rest of us, though, can go the extra level. When you get that weird email, the one that looks just a little off and hits your spider sense, view the email source, which looks like this:(This is the actual header from the phising email, by the way. You can see the whole thing here)
```
Return-path: 
Envelope-to: ipstenu@ipstenu.org
Delivery-date: Sat, 24 Mar 2012 18:14:57 -0500
Received: from blu0-omc4-s14.blu0.hotmail.com ([65.55.111.153]:4132)
	by gamera.ipstenu.org with esmtp (Exim 4.77)
	(envelope-from )
	id 1SBaAh-0001wn-Sk
	for ipstenu@ipstenu.org; Sat, 24 Mar 2012 18:14:56 -0500
Received: from BLU0-SMTP348 ([65.55.111.135]) by blu0-omc4-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);
	 Sat, 24 Mar 2012 16:14:54 -0700
```
By the way, notice how this came from Hotmail? 1990 called, it wants Nirvana back. WordPress emails don’t come from Hotmail, and I really hope that I’m not about to get a comment from someone at Automattic about how they still use it. Hotmail is like an AOL account. You’re not old school, you’re living in the icky past.

Now in that email, once you have the raw source, you scroll down to the body of the email and see this:
```
<HTML><HEAD>
<META name=GENERATOR content="MSHTML 8.00.7601.17744"></HEAD>
<BODY>
Dear WordPress Plugin Developer,
Unfortunately, a plugin you are hosting has been temporarily removed from&amp;nbsp;the WordPress repository. We&amp;nbsp;are going to manually review your&amp;nbsp;plugin because it has been reported for violating our Terms of Service. If your plugin does not get approved then it will be permanently removed from the WordPress repository.
You can check if your plugin has been approved or rejected at
<A href="http://wordpresss.comule.com/bb-login.php">http://wordpress.org/extend/plugins/my-plugins-status/</A> 
&amp;nbsp;</BODY></HTML>
```
I don’t know about you, but something’s fishy in that email. comule.com has nothing to do with WordPress, we have a winner.

How do you see your raw source? For most email apps, select the message, go to the view menu and look for ‘message’ or ‘message source.’ If there are further options, like in mail.app, you want ‘Raw Source.’ Outlook has it under options, I believe. Once you get that view, just take the time to look at the ‘content’ of the email. If you’re extra paranoid, you can even turn off your email’s ability to automatically render HTML, so you’d see that right away (I actually no longer do that because of the values in HTML emails).

Now you know how to protect yourself just a little bit more. What are your best anti-phish-tips?
4 April, 2012
Risk vs Transparency
This was written without any special insider knowledge. I’ve simply watched, paid attention, and kept track for the last two years. Often when I report a plugin, Mark and Otto are nice enough to explain things to me, and I’ve listened.

Occasionally a plugin vanishes from the WordPress repository. As a forum mod I tend to see people freak about this more often than not, and the question that inevitably comes up is ‘Why doesn’t WordPress publicize these things?’

Let’s go down the list for why a plugin is removed first. This list is very short, and boils down to three:
1. It breaks the rules
2. It has a security exploit
3. The author asks for it to be removed
That’s pretty much it. The rules cover a lot, though Otto and I have been known to sum it up with ‘Don’t be a spamming dick.’ I actually had the chance to talk to folks about this before the ‘expanded guidelines’ went live, and I think I have a pretty good understanding of what the rules are. The majority of plugins, that I see removed, are done so for the most obvious reasons:
- Phoning home (i.e. sending the author data about you without your permission)
- Forward facing links (i.e. opt OUT links on the front of your site when you use the plugin)
- Affiliate links (i.e. the author gets revenue from the plugin without disclosure)
- Obfuscated code
None of those are security reasons, and most of them are ‘fixed’ by us reporting the plugin, the plugin repo mods contacting the author, the author making the fix, and all is well. When the author doesn’t reply, or in the case of a ‘phone home’, often the plugin is yanked from the repo pending review. So where are these ‘security reasons’ to yank a plugin, and why should WordPress disclose them. Phoning home is, sometimes, a security reason, depending on what’s actually being transmitted.Usually it’s a vulnerability or an outright backdoor that would be a reason to pull a plugin.

There’s an argument that ‘Trust requires transparency’ when it comes to security (see Verisign’s recent rigmarole) and that would mean WordPress needs to publish things like ‘This month, these plugins were removed for this reason.’ Except WordPress doesn’t, and in fact, if you look, rarely do companies do this until they have a fix. The ‘problem’ with WordPress is they don’t do the fix, the plugin devs do, and a surprisingly high amount of times, the plugin author fucks off like a monkey.

On the other side of this argument is FUD(Fear, Uncertainty and Doubt) which is something you never want to feed. Look at the plugin “ToolsPack,” helpfully shown up on Sucuri. Now that was never hosted on WordPress.org, but if it had been, it would have been removed for exploitation. But once the offending plugin is removed, should WP go ahead

In October of 2010, WordPress.org ‘introduced’ a kill switch for plugins. Not really, but kind of. BlogPress SEO was spam. Yoast, one of the few true ‘SEO experts’ I know of, caught it and decided to fix it the best way he knew how. See, this plugin was never on the WordPress repository and so WP could do little about it. Yoast registered a plugin with the same name, gave it a newer version of the plugin, and everyone saw that as an ‘update’ and thus were saved. Sort of. Now, even Yoast admits this is abuse of the system, and I’ll leave the coulda/woulda/shoulda to someone else.

The reason I bring it up is this shows there is a way to handle bad plugins. But it’s not very efficient, it’s not very friendly, and it doesn’t promise that it will work. First off, not enough people run updates, and secondly it’s putting a lot of work on a very small group of people. While the theme reviewers have a lot of folks helping out, the plugins do not. Should they? Yes, but the number of people who understand all the code that could be in a plugin is far smaller than for a theme. I suppose it’s saying ‘plugins are harder than themes.’ I may be wrong, but it’s how I feel.

To fix all this, you’d need to basically reboot the plugins directory, turn them all off, review each of the 18,000+ plugins, and turn them back on. Then you need an Otto or Nacin going through each one to make sure every check in is okay, every update and every change isn’t spamming. Oh yes, that’s what happens to theme devs, didn’t you know? All releases are approved before they go live. Can you see the plugin developers agreeing to that? That’s a nonsense complaint of mine, actually. If tomorrow the rules changed, maybe half the plugins in the repo would vanish and never come back, but most of the rest would be fine. Of course, we would need a dedicated team of people to do nothing but review and approve plugins to keep up with the traffic.

So accepting what we have today, the wild west, why isn’t there a running list of all plugins yanked from the repo, and why? The list itself isn’t a bad idea. Having a list to say ‘This plugin was disabled on this date’ would be nice for a lot of us, and more so, having the plugin page show ‘This was disabled.’ would be nice. I can even think of a couple code ways to do it, but all of them need a full time person to go through the ‘removals’ and put up a splash page with ‘If you used this plugin, please consider alternatives: .’ and ‘If you wrote this plugin, please contact plugin support.’ Also, this would increase emails to the plugins support account, not from the authors, but from people who want to know why a plugin was removed. And what about a day when a plugin is removed because of a bad thing, but the authors fix it? Did we create a false feeling of doubt in a plugin that had a typo?

On paper, it all sounds like we should be keeping a public list for this still, though. Put it all up there for the public, disclose everything.

Every time I write that sentence, I wince.

It sounds nice on paper, and all I can think is about the people who will cry foul, complain, and want to know more. “Why was this plugin removed and not that one?” Well, most of the time it’s because no one mentioned that plugin. Right now, the plugins that get yanked are ones people stumble across or report.

But why worry about a simple list of removed plugins? Because the first thing I would do, if I was a nefarious hacker, would be to script a pull from that list and scan the web looking for sites that use the plugins, thus implementing a vector for attack. See, we already know people don’t update plugins as often as they should (which is why Yoast’s ‘fix’ isn’t as good an idea as we’d hope), but now not only are we leaving people at risk, we’re opening them to even more risk. If we email them to tell them the plugin’s risky, we have the same problem.

There’s no safe way to inform people without putting anyone who’s not up to date at risk. Given that the most dangerous day to have an unpatched system is the day of disclosure, the only way WordPress, or anyone, could keep a list like that would be if, like Chrome, WP auto-pushed updates right away, forcing anyone who opened the site to upgrade. And that’s fraught with it’s own issues.

Until then, I can’t advocate anyone keeping a list of removed plugins. It’s too risky.
22 February, 2012
WordPress, DSO and Permissions
I run my server with PHP DSO.(For the differences between DSO and SuPHP, read DSO (mod_php) vs. CGI vs. suPHP vs. FastCGI) It lets me run APC, and I’ve always liked it. It does have some weird problems, mind you, like a tendency to upload files as nobody:nobody, and more importantly it means that you have to set your wp-content/uploads folder permissions to 777. Thankfully there’s a fix!

If you’re not good with command line, scared by shell, and terrified of chmod, you’ll need to find your friendly neighborhood sysadmin to help you out. It’s okay to not feel up to doing this, and it should go without saying that you should make a backup first!

To step back, someone’s going to ask “Why is 777 bad?” Unix permissions are complicated. Every file in UNIX has an owner user and an owner group, and most of the time they’re the same. Mine are ipstenu:ipstenu (which means owner ipstenu, group ipstenu). Now another account on this server, conrel, has conrel:conrel. The groups ipstenu and conrel are both in the same webmaster group, which gives them special permissions. It’s confusing to a lot of people that most webhosts use the same name for the user and the group, but it’s just what we do.

Now for every file, there are three types of ‘ownership’:
1. User ownership – i.e. the user ipstenu
2. Group ownership – i.e. the group ipstenu
3. No ownership – i.e. you who are reading my site
There are also three types of permission levels”
- read (r)
- modify/edit/write (w)
- execute/run (x)
This all works out so when you go in via unix shell and look at your files you see soemthing like this:
-rw-r--r-- 1 ipstenu ipstenu 203789 Oct 5 19:30 stevejobs.png

This means the owner (ipstenu) has rw permissions (which are read-write). The group (ipstenu) has r (read-only), and the world (i.e. everyone else) also has r (read-only). This is an image, no one needs to execute it (which would be an x).(The “1” before ipstenu is for the number of files. “203789” is the size of the file. “Oct 5 19:30” is the day/time I uploaded the file, and “stevejobs.png” is the name of the file.) These rwx letters correspond to numbers. r = 4, w = 2 and x = 1. So when you see ‘rwx’ that equals 7.(There are also options o (other), u (user), g (group) and a (all)… and s … but I’ll spare you that right now. Suffice to say, you can use what you’re comfortable with. I use the numbers most of the time.)

So why is 777 dangerous? 777 means ‘everyone has full access to this file.’ Yeah, that sounds dangerous! I don’t want that! The only person who should have full access is you! But DSO doesn’t like to upload files without 777 permissions. In part, this is WordPress’s fault, but really it’s an unholy combination of things. Alex King explains why it happens, and as of WordPress 2.8, you can fix this yourself.

Just override the default file permissions. It’s genius! I tossed this into my wp-config.php file and I was good to go!
```
define('FS_CHMOD_DIR', (0755 & ~ umask()));
define('FS_CHMOD_FILE', (0644 & ~ umask()));
```
No, the 0 in front is not a typo. 0755 is an octal value. Octal values must be prefixed with a 0 and are not delineated with single quotes (‘). It’s just how it works.

There is a catch, though. My uploads folder had been set to 777, which meant /wp-content/uploads/2011/10 (this month’s folder) was also 777, which totally invalidated my test. That’s easy enough to go back and fix permissions on your folders. I did it this way because I have some caching plugins that I do not want to screw around with:
```
find /home/foobar/public_html/wp-content/uploads -type d -perm 777 -print -exec chmod 755 {} \;

find /home/foobar/public_html/wp-content/themes -type d -perm 777 -print -exec chmod 755 {} \;

find /home/foobar/public_html/wp-content/plugins -type d -perm 777 -print -exec chmod 755 {} \;
```
That code says “Find all folders (-type d) and if they have permissions of 777, change them to 755.” There are more variations on that.(I got the code from NixCraft – Linux / UNIX: Change File Permissions Recursively ( conditional )) If you want to change files, it’s -type f and you’d want something like this:
```
find /home/foobar/public_html/wp-content/uploads -type f -perm 777 -print -exec chmod 644 {} \;
```
That will turn all your images back into permissions 644, presuming they were 777 to begin with. Mine were 755.

The last step I had was chowning the folder for uploads and 2011 to nobody:nobody. That was so on month end, I would be able to create folders (like uploads/2011/11 today) without any issues. The other folders, as they already existed, didn’t need the permissions changed. Honestly, I’m not sure if I needed to set the uploads folder to that. I didn’t set blogs.dir for my MultiSite install, and just did the files folder within, since it had created other folders correctly. It’s a hassle, unraveling years of ‘Did it wrong!’ and when you add in that we’re using different tool sets to upload files versus upgrade and all that … well. It works now.

I also kept the upgrade folder with permissions 777, since that just did not want to work any other way. It flat out refused to upgrade any plugins. I’ve yet to try upgrading WordPress itself with this setup, but I suppose I’ll find out soon.

And that’s it! It’s not 100% painless, and it’s much easier if you start out ‘doin’ it right’, but even after you’ve been doing it wrong for over 5 years, you can fix it.
7 November, 2011
Request: Multiple Domains, One IP SSL Certificates

This is actually a request. The server that runs Ipstenu.org hosts three other domains. I set up my self signed certificate just fine for *.ipstenu.org, but I want to add on the other domains. For some reason I seem to be failing.

I somehow managed to get it half-baked. If you go to https://otherdomain.com it kicks you to https://ipstenu.org/wp-signup.php?new=otherdomain.com which isn’t what I want at all.

I’m using WHM on CentOS 5.6 and I’m a total newbie when it comes to all this! Links to tutorials with pretty pictures, advice, or directions are all welcome!

18 October, 2011
SSL Self Certification and WordPress
I wanted to lock a single-site WordPress install down to use SSL admin because I’m a tin-foil hat wearing nerd. Or more to the point, I detest the idea of clear-texting passwords! Most of my problem was finding directions. See, I knew I had to add define('FORCE_SSL_ADMIN', true); to my wp-config.php file, but when I did that, I got an error:

Turns out I’d never turned on SSL for my server! My problem then became that I don’t want to shell out $100 a year for SSL when it’s just me no my server, no one else. Once I determined all I wanted was to create an SSL Self Signed Certificate on my server, which has WHM, it got a lot easier!

There are drawbacks to self-signing. Firstly, every time I login on a new browser, I have to tell it ‘Yes, trust me!’ That’s annoying. If I was using this for other things, I’d have to remember to type in httpd every time, but WordPress is smart enough to redirect that for me. Also, back in the day, Chrome was an idiot about them and wouldn’t let me use them! but I use self-signed without knowing it for ages, because my host set that up for cPanel and WebMail. I’m not a business, it doesn’t bother me. If I was, I’d charge more and shell out.

All that error means is that “Hey, ipstenu.org signed this, and I don’t know who that is!” If you read further on that page, there’s a link to ‘Help me understand!’ and it explains:

In this case, the certificate has not been verified by a third party that your computer trusts.

Which is 100% true. By self signing, I’m skipping 3rd party verification and telling you to trust me. Looks scary, it’s really not if you know what you’re doing. If you’re willing to deal with this error every time you login on a new computer, then you too can SSL yourself to a little more safety!

These directions will only help you if you’re using a VPS or dedicated server. You’re going to do all the work in WebHost Manager.
1. Go to Main >> SSL/TLS >> Generate a SSL Certificate and Signing Request
2. Fill in the fields – the passwords have to be alphanumeric, and remember to use the right domain. If you use www.example.com as your default, use that. I use just example.com for all my sites so I did that.
3. Save the data to a text document.
4. Go to Main >> SSL/TLS >> Install a SSL Certificate and Setup the Domain
5. Import your certificate data (or paste in from text)
6. Select Submit
If it works, Apache will restart and you’re done! If not, you have to read the error. My problem came with the domain details:

I was able to skip steps 1-3 and just go right to ‘browse’ since, apparently, at some point I’d done them before. The problem was for my second site, it’s on my shared IP, which meant I had to put in the User of ‘nobody’ instead of the user name. Not a big deal.

After that, I was done and could log in to my site via SSL!

But wait… What about MultiSite? Well if you’re using subfolders, this is great. Subdomains, however… See the host name has got to be the domain name: halfelf.org in this case. So if I wanted to make one for all my subdomains… Owch.

Then I thought that maybe, just maybe, the computers were smart enough on their own. So I did this:

And then this:

Now, since I already had an ipstenu.org cert, I had to delete that one first. But once I did it, I was done. I turned my multi-site into something a little more secure!

And now you can too.
20 September, 2011