Category Archives: WordPress

Panama Papers breach

The Panama Papers data leak has already snared many rich and powerful folks who have been using questionable means to hide wealth beyond taxation and scrutiny. However, that’s not what I want to write about here. I certainly find the abuse of wealth and power to be an issue, and much ink is being spilled on this. I want to focus instead on information security, and in particular, the vectors likely used to extract the data from the law firm Mossack Fonseca. What happened here was not some sort of uber-secret hacking, but was a simple process of exploiting well known vulnerabilities in WordPress plugins and in a particular version of Drupal core that was found to have severe vulnerabilities in October 2014.


WordPress and Drupal are both extremely popular content management systems (CMS). Your correspondent runs several websites using both these systems, and this blog runs on WordPress. Both systems are robust, reliable, and have huge ecosystems of “plugins” or “modules” that can be used to extend basic functionality of the system in a myriad of ways. These extensions provide visual appeal (image sliders and other tools), spam control, and even database functions for storing information about the user community.  If you can imagine it, someone out there has probably written a WordPress Plugin or Drupal Module that can help you bring that functionality to your site. However, with great power comes great responsibility 🙂 .

One of the banes of any technology system is maintenance and patching. This can be to fix bugs, to add functionality, or, increasingly, to patch the seemingly never-ending list of security holes. WordPress and Drupal are no exception, and in fact, both are big targets. Of the two, WordPress is far more prevalent, with over 75 million sites and growing rapidly. Drupal runs one million sites. From a security exposure perspective, WordPress is in my opinion a bigger problem. WordPress is extremely easy to install, and takes much less study to create interesting sites than does Drupal, and as such, many sites are set up by individuals and groups who don’t appreciate the rigor of site maintenance.  I’m not writing this post to favor WordPress or Drupal.  I like both, and both have strengths and weaknesses. This brings us back full circle to what happened with Mossack Fonseca.

In a word, the problem was maintenance. The likely vector that lead the Panama Papers hackers to Mossack Fonseca’s email servers was thru unpatched and well-known vulnerabilities in WordPress plugins. The Drupal exposure likely led to client documents, and could have been a bit more forgivable from an IT perspective, as the exposure was from the core weakness in Drupal versions prior to 7.31, a part of the “Drupalgeddon” exposure of huge numbers of Drupal sites…except that Mossack Fonseca is still (at the time of this writing) running Drupal 7.23 from August 2013!

Wordfence, an organization that provides security plugins and services for WordPress, has done an excellent writeup of how the Panama Papers hacks unfolded, and it’s well worth a read, especially if you are responsible for either doing website maintenance or if you are concerned about the security of the sites you or your organization run.

The sad fact is that it’s just so easy to do maintenance on both WordPress and Drupal that not maintaining sites is highly unprofessional. Wordfence provides an excellent plugin  that notifies you when a monitored site needs a core update or plugin update. Many updates can be configured to run automatically. Running manually is a simple matter of logging in and then doing a couple of clicks! Drupal is just about as easy, though a Drupal core update is a bit more involved than a WordPress core update, currently needing a separate program (Drush) to handle the core update.

Maintenance of websites is a necessary job, just as is maintenance of any other technology asset. Think of it as changing the oil and checking the tire pressure in your car. If you know how, do it yourself. If you need to hire someone else to do it, then do so…but ensure that it is done, or you and your company may wind up in the news one day…

More fun with WordPress (Participants Database)

As I wrote back in December, I’ve been working on setting a WordPress instance for the Emerald Isle Parrothead Club. One of the things we wanted to do was to move the membership roster of nearly 400 club members from an Access database (that obviously only one person could use at a time) to a system that was web-enabled so that we could have distributed maintenance. Also, if we could enable web-based membership applications, produce a membership list and other such things, all the better. I decided to see what I could find.  I discovered several software packages (some open source) that worked for clubs, but most of these seemed to be focused on sports clubs with court reservations, etc. Seems that “club” was not a good keyword. Then, I said let’s just see what sorts of WordPress plugins might be available.  I quickly stumbled onto Participants Database, which we’ve now implemented on our test site.  This is a most excellent plugin! The description is:

Build and maintain a fully customizable database of participants, members or anything with signup forms, admin backend, custom lists, and CSV support.

As you can see, that pretty well covered my use case 🙂 So, we’ve set it up, we have our database schema defined, and have demoed to the Club administrative folks, who’ve enthusiastically endorsed it. My next task is to import existing membership info, make a few more configuration tweaks, get all to give the “thumbs up” and then implement on our production site.

The only thing that didn’t work quite like I wanted is that it’s set up to allow only users with an “administrator” role to export data extracts to a CSV file, though it allows (by default) an “editor” to update data.  I wrote the author on the support forum, and he said the next version would allow what I wanted (the editor to be able to export a CSV). However, I’d already figured out how to patch the plugin to do what I wanted.  Patched one line of code in each of two files, and it works.  I’ll regress those changes when the update comes out…

The bottom line is that if you have a club or organization that has a WordPress website and you want to set up member/participant info, you should check out this plugin.  It’s very flexible about letting you create whatever fields you need to track things, display the things you need, manage administratively, and expose the info you want to the public.  It even has the ability to allow participants to maintain their own info through a “token” rather than a password, to make administration easier…

Playin’ with WordPress

My standard volunteer niche is to be on the technology committee for the organization. Something about 35 years in IT is hard to run away from 😉 . Anyway, I’m on the tech committee for the Emerald Isle Parrothead Club. For several months, we’ve been in the process of visioning a new website that was easy to use, supported distributed editing, and lots of folks know how to use it…hmmm…sounds like WordPress! I’d previously set up a prototype site on my personal ISP space, and everybody was happy with the look and feel.  I didn’t do much but set up the shell, and others on the committee added content and structure, but I was the one in the sysadmin role. The time came to move it to its new home, and an additional complication was that the club domains were on GoDaddy, not 1and1, the ISP I’ve used for years, so I had to learn to speak GoDaddy.

We switched from a domain-only account that had pointed elsewhere to a Linux hosting account, and with that came a new “free” domain. So, I decided that we needed to do things right and have a test/validation site and a prod site, using the new domain for “test.” I use Updraftplus for backups so I transferred the backups over to the new site. I first created a new virgin site, installed the Updraftplus plugin, and then restored the backup. I knew I needed to patch some things in the wp_options table, so I did that first with PHPMyAdmin, but I wanted to do a better job, so I Googled up a really nifty tool, Search Replace DB which had some great features (like an audit mode) so I gave it a whirl. It found quite a few places to fix, albeit most in areas that would have never been a problem like spam comments. Got the prime site working, though I knew I still needed to move it again before finishing, as I’d intentionally put it in an experimental location. I then cloned the database for my validation site, patched the URL’s, copied the directory, and set up the validation site. Then moved the production site again to its final location, patched the database again, fixed the DNS entries, and all was well.

Fun stuff!

An exemplar of the “assembled web”

I spotted an article in Forbes by Dries Buytaert, the creator of Drupal, in today’s scrolling twitter feed. I’ve dabbled a bit in Drupal, creating a few sites, but aside from looking at the PHP to debug a few things and trying a few patches, never really got technically below the level of installing and configuring modules. Even some of the more technical things in Drupal GUI configuration, such as creating content types and views to retrieve and present that content, are still done with boxes, radio buttons, checkboxes and lists. If you think about it, you are dealing with something that’s close to the MVC paradigm without having to write code. Buytaert says an individual without coding experience can “…use an open source CMS to assemble a site by simply snapping modules together…” That’s the essence of the assembled web. We know, in a fairly intuitive manner, how to create a personalized experience on our smartphones and tablets by selecting and configuring apps from an app store. This is really the same philosophy, just rendered on a server to allow others to access your content. There’s an app (or module or plug-in, depending on the CMS and its terminology) for that, to allow anyone to create on the assembled web. It really takes the Web back to its roots as a person-to-person sharing service. Berners-Lee envisioned it as a tool for sharing information between researchers, where individuals were creators and consumers.

The catch in all this is that it’s quite promising and almost there, but it’s not quite as seamless for the users as we’d like. WordPress is a bit further along this path than Drupal, I think, especially with the ability of current versions to maintain and update the “apps” (plugins, in WordPress-speak, and even some core updates). Drupal 7 doesn’t auto update, and the upcoming Drupal 8 won’t either, at least initially, insofar as I can tell. Some think that this is a bad idea anyway, in that it could lead to a massive compromise of servers. In my humble opinion, I think that the risk is actually greater of not updating sites, having seen the result of many compromised WordPress instances. It’s a double-edged sword – the easier it is to use a tool and create content, the lower the bar for the technical competency to do that, and the greater need for software that updates itself, as less-experienced (and read less paranoid as well) site owners simply don’t appreciate the need to keep things current. Drupal has a steeper learning curve (it doesn’t do much out of the box, unlike WordPress), thus the folks that run Drupal sites tend by necessity to be more technically literate and are thus more attuned to the need to patch/update (this is not to disparage the many, many very competent WordPress admins doing great things with the software, it just that it’s so easy to use and get started, that it’s an attractive target vector for compromise of less-well-maintained sites; this site runs on WordPress which I religiously patch and update!).

Buytaert is right that the the assembled web is the wave of the future, and he’s also right that it’s not a threat to the livelihood of (some) developers. However, the days of hand-crafting HTML are over, and there is a slice of work that has been squeezed out. Developers and integrators that understand the add-on technology and economy will thrive, just as those that have created apps have helped smartphone and tablet ecosystems to thrive and driven the sales of those devices. The assembled web makes it easier for everyone to share and publish creatively. It’s not quite point & click, but is asymptotically approaching that goal. I think that the tail is still a bit long, however, and getting to Buytaert’s vision of “…a marketer could build a site for a new product launch without relying on the engineering team. An entrepreneur could launch a company site without hiring a webmaster…” will take a while longer yet. That marketer or entrepreneur can get started, but the devil is always in the detail, and it’s not quite “fire and forget” on setting up a site…but it’s getting closer.


After a conversation with some colleagues about WordPress security, I decided to install and activate Wordfence on one of my blogs today. I’m using the free version, but it appears to have some nice features. I’ve just started poking around a bit. Some of the logging features are quite interesting, in particular the human v. computer taxonomy. My scan was clean except for one URL I’d highlighted in a post a couple months ago. I looked at the current info on it and took the option to leave it in the post and ignore it on future scans. Overall, a good first impression for Wordfence. I give it two thumbs up!

Finished recategorizing the blog entries; social network musings…

Well, all 305 blog entries, dating back to 2005 are now recategorized after the infrastructure migration. I know that’s not a huge blog, but it was enough work! I have no idea how close I came to the “old” categorization 🙂 . It’s actually not a bad idea to do it manually, so that I looked at things thru the prism of new blog categories. Anyway, there are now no uncategorized entries in the blog! I’m hopeful that I’ll actually post some more here. I’ve been trying to parse the divide between what goes to Twitter, what goes to FaceBook, and what goes to the blog. The nice thing about the blog posts is that they are mine, with my own “terms of service” and I can do with them what I want. I’m currently cross-posting these entries to FaceBook, and cross-posting Tweets to FaceBook, but am not linking the blog to Twitter. I do have my Tweets displayed on this blog via a Jetpack widget. I guess the question is really what’s of transient value and what might be worth keeping. It’s been interesting reading back to my 2005 blog posts during this recategorization and figuring out what was interesting to me 8 years ago. I don’t know that I have quite the same level of attachment to my FB posts or my Tweets. I could send my blog entries to Twitter and not loop Twitter back to FaceBook. I’ve resisted sending any status updates to LinkedIn, keeping that for connections and a resume presentation. I’m thinking I’m going to do more via WordPress now that I can use the iOS apps for posting. That might mean that I want to reconfigure the direction of Twitter updates…sounds circular to me!

New blog infrastructure

I decided that I needed to update the platform for this blog.  It had lived under a WordPress instance that was managed by my hosting provider, and I kept it there due to simple inertia.  However, I’m going to upgrade my hosting package, and that meant I needed to address the old blog platform, as that’s an option that was being left behind.  So, I’ve migrated (mostly) the blog to an up-to-date WordPress platform that I’m managing.  I’ve still got some link and image issues that didn’t come across cleanly, and I need to clean that up.  However, I think I got all the posts, though there were some glitches with the import.  I was getting an error, but found this post that described how to take care of it.  I think I’m going to declare that this is the new production version.  Onward!