Tag: security (page 1 of 2)

September 2, 2017

WordPress Is About Responsibility

Your WordPress site (or any web site you put on the Internet) has value. Take care of it, it is your front yard and what the neighbors see. It’s your front office where you invite people to talk or do business with. Own it and take responsibility for it.

Recently on the WordPress support forums, I (not wisely) got into a security conversation. No great minds were changed, nothing new was discovered and nothing was accomplished.

In the hundreds of words exchanged, there was one tidbit sent my way that caught my attention.

Do you really think that it makes sense to expect these people to know/care about — and stay on top of — new/old security risks, manual plugin updates, manual core updates, etc.?

Yes, I do. 100%. Unequivocally.

I didn't reply there as the topic dissolved into a conversation about "blame".

I don't do blame, I'm about responsibility. Blame is for children, blame is for "It's not my/their fault" comments. Blame isn't about taking ownership, it's not a reason for something that happened. Too often blame is about excuses.

This isn't a new thing for me, I blogged about it 9 years ago. There's no shame in not having the technical ability to to maintain your site.

Software is a moving target

I recently went to a work event and one of the things repeated often was that security isn’t a state that you achieve. It’s a posture and is a response to a moving target.

WordPress powers over 28% of all web sites and that number is growing. Just as it is with popular office software and home PC operating systems, that number makes WordPress sites a very attractive target to go after. That’s why WordPress takes security very seriously.

But it’s a less than perfect world out there. Plugins and themes may not get the scrutiny that the core WordPress does. Patches happen all the time. When a minor number release of WordPress is pushed out, unless you or your host did something to prevent that, your site will update without you having to do anything.

Plugins and themes don’t update automatically, that’s turned off by default. That’s also where many sites get exploited.

Learn how to maintain your site

It’s still not a big list.

Learn how to schedule backups and store them off of your WordPress site.
Routinely log into your site to update plugins and themes. Or add a plugin to do it for you.
Learn how to restore backups onto a blank installation.
Or consider paying your host or a service to do these things for you.

Many hosts support WordPress and (for a fee) will do that maintenance for you.

Take responsibility but ask for help when you need it

I’ve not seen any surveys but I would guess that easily 80% of WordPress users don’t know how to do steps 1 through 3 above. I would also wager that half of those users rely on their host provider more than they realize.

That’s fine because most of those users may not lose sleep if they lose their blogs. People start blogs and forget about them all the time. For companies and organizations, a lost or compromised site can hurt their reputation.

If you need help or Very Bad Things™ happened, then you’ve got some options.

See if your host can help you. Many host providers do offer WordPress support, sometimes for a fee.
Hire someone, but be wary. I personally like companies that have real people, who interact and have a real reputation. WP Site Care is one such company, there are others. Don't just use Google, ask people who may know. Go to a local WordPress meetup and ask around.
Post a support topic at the free, 100% staffed by volunteers, support forum. Notice that I put this one last?

Here’s why I put my favorite one at the end. There are no customers there, only users. If your site is on fire and you need it back ASAP then that’s just not a good option. I’ve been supporting and helping to admin those forums for years and they are top notch.

Those forums are staffed by unpaid volunteers working on their free time out of the goodness of their own hearts. Would you tell your CEO that’s your support model? You could do that. Some people have that misunderstanding and it often ends poorly. They don’t get the support they need and sadly, WordPress loses a user who didn’t realize what they were getting into.

A little self-education goes a long way. Don’t be afraid to ask questions about your WordPress site. At the end of the day it’s your responsibility. Learn and create a plan to maintain it and keep it running.

Don’t accept blame for what happens to your WordPress site. Take responsibility instead.

January 2, 2017

Tin Foil Hat Gravatars

Sometimes I do overthink things. I wrote a plugin to protect Gravatar image URLs.

April 13, 2010

Yes, but how does Matt really feel?

It reads a little like a rant, but you really can’t blame him.

I’m not even going to link any of the articles because they have so many inaccuracies you become stupider by reading them.

If you’re a web host and you turn a bad file permissions story into a WordPress story, you’re doing something wrong.

via WordPress › Blog » Secure File Permissions Matter.

It’s not rocket science and the real problem is explained in detail elsewhere but can be summarized as “It’s the hosting company, Stupid!”

Which leads me to a posting on another blog. Partial blame is leveled “At WordPress for requiring that the database credentials be stored in clear-text. At WordPress again for not installing itself securely by default.”

The ignorance continues with “I also have to agree with Network Solutions that this problem can happen at any shared host site. Not only for WordPress, but for any CMS out there that store the passwords in clear-text.”

That’s just a stupid thing to say. If you are going to make a statement like that, then you need to back it up with “WordPress should have followed example X for how to store that data securely”. It sure is good to call out from the cheap seats and that’s all that blogger is doing.

The impacted users are on a shared server that’s not setup properly. Users get a pass because, well, they’re users. It’s not really the users responsibility to understand how their self hosted blog works and prevent these compromises from making the neighborhood look bad.

Network Solutions loses any credibility because instead of just saying “Yeah, we screwed up and we’re fixing it” they played the ignorant blame-the-software approach. Network Solutions is not a flash in the pan company and should hire someone who can help them overcome Web Hosting 101 issues.

January 10, 2010

Village Idiot wants to punish the Newark Scare guy

Here we go.

“He’s really an unwelcome guest,” Lautenberg told The Record of Bergen County. “He should be returned to his homeland.”

via Controversy swirls over graduate student who breached security at Newark Airport | New Jersey Real-Time News – – NJ.com.

This translates into

“I’m 85 years old but may want to get re-elected anyway. So I’m going to speak pointlessly and try to make the government looks less-than-idiotic. Hey, did I mention how important a Senator is?”

Later on the Senator toned down the rhetoric but honestly.

A little proportion here. This Great Security Threat walked around an unguarded exit. The big security control was a fabric fence meant for guiding a line. Why doesn’t the airport just install one way revolving doors like you have in the New York subway system? People with wheelchairs can use a locked door that only opens from a security operator, and in case of a fire the doors would open automatically. This is not new technology, the answer has been around for years. It would be inconvenient but what is the TSA trying to accomplish anyway?

The argument against that is probably “that costs too much money” but how much did it cost to shut down the airport for all of those hours? And does anyone actually believe that the bad guys are not aware of this before all the commotion?

I am positive that the Great Government Security Theater will get this poor guy deported just to cover themselves. That really would be a shame but that is just how the system works. Don’t solve any problems just go after anyone who reveals them.

January 9, 2010

Woo, they got the Newark Scare Guy

Nice to see Senator Lautenberg still goes for the sound bite. Is he up for re-election?

“This was a terrible deed in its outcome — it wasn’t some prank that didn’t do any harm — it did a lot of harm because it sent out an alert that people can get away with something like this,” Lautenberg said.

via Police arrest man in Newark security breach – Airliner security- msnbc.com.

My children sometimes see my blog so I’m not going to type what I really think.

This guy went around a fabric barrier just like the ones in your bank line to see the teller. Every time I get off of an airplane and walk to the luggage area, I always think “Geez, anyone could just walk in this way”. And surprise! Someone did. And now he’s faced with a $500 fine. I’m also betting that ICE suddenly decides to deport him.

If ICE does do that, that would be very wrong. This guy’s infraction really is only worth a fine. It’s the TSA that needs to learn from this and buckle up their process. I don’t blame the TSA guard who let this happen for 2 reasons: he’s a only security guard and NOT law enforcement, and it’s not his fault that his managers can’t enforce coverage when one of their guys needs to walk away for some reason.

At Penn Station I see many TSA guards and personally I think that they’re utterly useless. What does cheer me up is that I see the same number of Amtrak police officers in the same area. I expect real law enforcement to keep me safe, I don’t expect much from overworked and low paid door guards. I don’t have a problem with TSA staff but let’s be honest about what they are and what they do.

So the Senator from New Jersey thinks that this revealed some horrible secret weakness in our airports. I’m hoping that the evil people who exploit these things have the same quality of smarts as our elected officials.

November 12, 2009

Get your red hot WordPress 2.8.6

WordPress 2.8.6 is out and it’s a security release so update now.

I’m expecting the usual complaints on the support forum but so far it’s been pretty sedate. I’ve been using WordPress since version 1.5.2 and I’ve never had a bad upgrade. Of course, I have a good idea what I’m doing and have never used the automated upgrade process, so your mileage may vary.

As is usual, using SVN only took me a few minutes to upgrade 6 blogs on 3 different machines.

July 10, 2008

DNS excitement! Panic at the office!

Well not really panic, just your usual vulnerability patching day at the office.

When I saw Dan Kaminsky demonstrate voice over DNS, I was convinced that he dreams in BIND source code. It was a neat demonstration.

Now he has uncovered another vulnerability in BIND regarding UDP source port prediction. It’s causing some excitement in the work place as to what the impact could be and how soon our vendors can release patches.

I’ve had to do some explaining as what it means; see Matasano’s blog for more information. Thomas Ptacek sums it up really well here and states the impact more here.

You’ve got to love someone who can explain the seriousness using a movie quote from Jack Black.

June 16, 2008

WordPress file monitoring

Over a week ago I complained about WordPress users crying security wolf and not being able to recover their blog when the “Bad Thing(tm)” happens.

Since then a real brawl developed on the support forum that could be summed up like so:

One or more users is insisting that there is an XMLRPC exploit in 2.5.1.
The same one or more users refuses to back this claim up with data, or apparently send the WordPress security e-mail alias any info (maybe, how would other people know what was sent via e-mail?)
Many people tried to reasonably explain that such an exploit may exist but without data there is nothing to solve.

This discussion was just plain nuts and went around in circles. Complaining about a problem without providing any proof and then getting all pissy about it is totally useless. It is entirely possible that such an exploit exists and many people replied so. But without any providing data other than saying “I can assure you that the hack occurs via XMLRPC”, then everyone’s time gets wasted.

Fortunately, Donncha provided a page that covers the issue succinctly and today he added another post on setting up aide. His two posts are good and anyone considering monitoring their WordPress files for modification should give this a try.

Aide will let you see if your installation files and directories have been tampered with. It won’t protect you against HTTP POSTS or database attacks but it’s very good if someone succeeds in modifying your files.

There are ways to log what’s being sent via an HTTP POST and examine that information; if (or even when) I get hacked, I’ll try to start looking at that data. MYSQL database monitoring, that could be interesting but for now I’m not aware of a good tool to do that.

On my OpenSuSE installation, installing aide is simple. As root run

zypper install aide
aide --init
mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db
aide --check
cp /usr/share/doc/packages/aide/examples/etc/cron.daily/aide.sh /etc/cron.daily/

All of which I just did. I ran the check option to make sure I did not create any issues with the aide.conf file. I’ll play with the aide.conf file and see what kind of output I get when the daily cron job gets run. If I add and modify files and I set it up correctly then I should see that in daily cron job’s output.

Update: this worked but in /etc/aide.conf change the line verbose=1 to verbose=5. That will get you a useful output of which files and directories changed.

June 3, 2008

Sigh, WordPress users and hacking

If you are not running the latest version of WordPress and you get hacked, don’t go to the WordPress forum and tell the world. Odds are you invited the disaster yourself.

When WordPress 2.5 came out I was disappointed to find that the old version 2.3.x was basically abandoned. There would be no more planned patches for 2.3.x just the current 2.5. The 2.0.x branch would continue to be supported as part of the commitment to the Debian version model.

So as of right now versions 2.0.11 and 2.5.1 are supported. If you are running 2.2.x, 2.3.x, 2.5(.0), or any other version then you run the risk of being exploited.

So why do users continue to use the old versions? Everyday there are posts in the support forum that (so far) always deals with someone’s blog getting hacked and they are not using the current 2.5.1 version (as of this writing). Eventually someone writes “I’ve been hacked” and some other user writes “Is this a vulnerability of insert current version HERE?!? Why are the developers not doing SOMETHING?!”.

It’s like there is some axe to grind and the first one to find the axe gets 1000 gold points. The moderators usually show great patience; I’d get ticked if I were them. These users seriously should just avail themselves of WordPress.com and stop trying to self host a blog.

The freely available WordPress from WordPress.ORG is not commercially supported, and commercial support if often not that good anyway. So for anyone who is thinking about using WordPress.org’s software, they should be able to do the following by themselves.

You need to be able to make backups.

Read this Codex article for backing up your WordPress installation.

WordPress uses two components. The easy one is the file system and backing that up should be trivial. I use a shell script that creates a tar.gz archive every night. Another cron job deletes backups that are older than 30 days. Why fill up my disk? The backups are not for historical use, just to get me back to the state I was 24 hours ago if need be. 30 days is too much but hey, disk space is cheap.

The mysql database is the other component. The same backup script also creates a text dump of my entire WordPress database. This copy gets gzipped and added to my file backup. The mysqldump command is your friend and should be used.

You need to be able to know how to restore those backups.

The Codex has a good article on how to restore your blog database here.

Making the best backups is pointless if you don’t know what to do with them when the “Bad Thing” happens. Take your backup and restore it to a WAMP or LAMP installation on your own PC. If you need a Windows Apache Mysql Php setup, use Google and install the one you feel comfortable with. In Linux just add the packages (See this link for Ubuntu).

Once you have the Apache web server, Mysql, and PHP running locally on your PC then start playing. Install WordPress locally, restore your backup and just change the name of your installation in wp-config.php to localhost and test. To adjust your local installation to run on your PC just add these two lines to the copy of the wp-config.php on your PC:

define('WP_SITEURL', 'http://localhost');
define('WP_HOME', 'http://localhost');

Then on your PC point your browser to http://localhost/ and test it. Beat it up; it’s a local copy on your PC. Go nuts on it and confirm that your posts, categories, tags, comments, etc. are all there. Anything on your PC that you mess up in WAMP or LAMP should be no big deal. Just start over if you get lost.

Play with it until you understand what you are doing, because when you DO lose your blog you’ll need to do this for real.

Practice performing an upgrade on your PC’s local copy.

That sounds like a plan right? Some plugins don’t work with the latest and greatest version. If the version you are running is vulnerable to an exploit then you don’t need that plug in.

Security updates are the number one driver for minor number version releases such as 2.5 to 2.5.1. Yes, there are bugs but they usually are tolerable. Exploitable code is serious business and usually gets fixed quickly.

Once you are comfortable with upgrading and testing your local installation, upgrade your real blog. I personally keep good backups and know how to restore them so I never bother with this step.

If you know how to backup and restore your blog, then even if the upgrade is bad, you will be able to put it back the way it was before the upgrade.

July 10, 2007

.htaccess to prevent wp-pass.php redirects

I was checking out my server logs (gripping reading, could not put it down) when I saw these two entries:

208.78.98.108 - - [09/Jul/2007:20:28:07 -0400] "GET /wp-pass.php?_wp_http_referer=http://topnlpsites.com/images/gif/echo.txt? HTTP/1.1" 403 860 "-" "libwww-perl/5.803"
81.169.188.151 - - [09/Jul/2007:20:54:39 -0400] "GET /wp-pass.php?_wp_http_referer=http://doublezer0.free.fr/echo.txt? HTTP/1.1" 403 1032 "-" "libwww-perl/5.69"

File wp-pass.php? Where’d that come from?

See the BUGTRAQ explanation here. By passing arguments to wp-pass.php, the wp-pass.php file will send the requesting browser to the URL that wp_http_refferer points to. By using a simple script the WordPress installation is easily verified as susceptible.

The bad buy sends out a SPAM or bogus link that points to a WordPress installation and that WordPress blog redirects the request to where ever the attacker wants. This is not earth shattering but really annoying.

Luckily Apache’s .htaccess is our friend. In my blog root at the end of my .htaccess file I added the following two lines:

RewriteCond %{REQUEST_URI} ".*wp-pass.php"
RewriteRule .* - [F]

I do not have any password protected posts so I don’t use that file (which is all I gather it is for…) and after implementing this my blog continues to work fine. Any requests that match that rewrite conditions gets a return value of 403: Forbiden.

This is to be fixed in WordPress 2.2.2 says the posting. The BUGTRAQ posting also mentions wp-includes/pluggable.php, wp-includes/functions.php maybe vulnerable due to the use of problematic code.