Category Archives: Drupal

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…

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.


There have been several updates to Drupal core since the first of the year. I did a round of maintenance for my sites in February, but I’d skipped Drupal 7.21 since it was not a security update. Then, on April 3, 7.22 was released. Like 7.21, it’s not a security release but I thought I ought to upgrade. I ssh’d to my hosting service, and in turn, backed up each site, switched to maintenance mode, and did the module+core+database update with drush. Ran like a champ. I’ve only been doing Drupal for a couple of years, and I didn’t use drush at first. In fact, I only started using it when the web-based updates started throwing PHP errors on one of my sites. I’m happy I installed and started using drush, ’cause it sure does make maintenance easier.

Trying to get smarter about HTML5 and CSS

It’s been a cold, wet day here, with big snowflakes and 33 degrees. Not much accumulation of snow, but what little there is will freeze up hard tonight. Basically not a great day to go outside so I’ve been reading up a bit on HTML5 and CSS. My thoughts are that I’d like to try some Drupal theming. So, I’ve been doing a bit of reading. I’ve been doing HTML for a long time. It was 1993 when I wrote my first HTML pages. However, while I did a lot of early web apps, including Java and Javascript, my HTML skills didn’t progress much beyond 1990’s techniques. I’ve never been strong in design, anyway, and better in coding. However, in order to work on Drupal themes, I needed to get up to date on HTML and CSS. I found what so far seems to be a pretty decent book, HTML5 for Masterminds. I’ve gotten thru a couple of chapters, and it’s making a lot of sense so far. Will continue to read more tomorrow.

A-drupaling I shall go…

I finally quashed (more or less) a couple of issues that had been nagging me with the website that I created and maintain for Orange District, Occoneechee Council, BSA. I did some maintenance this weekend, upgrading Drupal core as well as some modules that needed updates. The web-based module updater broke when I switched to PHP 5.4, as my ISP is deprecating PHP 4 and 5.2, and I needed to do manual module updates. Hopefully the web module updater will get fixed in Drupal 7, but some of the things I read made me think it won’t be until Drupal 8. Also, I’d been having a problem with the calendar view throwing lots of warning errors and I’d not been able to find out what was causing it. Seems to have varied causes with module/database dependencies but predominantly in Views and CTools. This also started when I went to PHP 5.4. I was able to figure out what to back out to get the warnings to stop (a Google calendar overlay), but I’d like to get that functionality back. I opened up an issue on the FullCalendar module to see if anyone has ideas.

Also, I spent some time this weekend working up a website for a friend who’s a local farmer. We found a nice Drupal template and have a skeleton set up


Drupal is one of the most common content management systems (CMS) on the web today. Well, they actually call it a content management “platform” and I guess that given the extensibility (>13,000 modules that can be added in), that’s an appropriate description. I’d wanted to get more familiar with it, at least from the standpoint of building a site, so in the summer of 2011, I set up a skeleton (very easy if your ISP supports PHP and MySQL) and had my son Jeff, home from college for the summer, help me with building a new site for Orange District, Boy Scouts of America. He set up some directory views for me as we both fumbled through the paradigm. Once you realize that you have content, and you have views (a module) that display that content, and other modules that are like “apps” for the environment, you begin to see the beauty and flexibility that’s inherent in the platform. I picked up a book, “Beginning Drupal 7”, from Amazon that was pretty helpful as we started out.

One thing that really drove home the data/display (view) design was work that Jeff and I did on setting up a calendar. He created a data type for events and a calendar view last summer, but it broke after an upgrade this fall. I found a calendar module I liked better (Fullcalendar) and set that up. I had it query the old event data type, and it worked like a champ. Also, used the ability to bring in a Google Calendar (the US Holidays calendar) so I didn’t have to set those up.

Drupal has all the features you’d expect. Granular permissions for managing content and the ability to extend the model. Distributed content creation. Effective indexing. Easy to patch/update. Diversity of themes to alter the appearance of a site, w/o changing the underlying content. It’s got a huge and dynamic developer community. I don’t know if I’ll ever do any coding on a module, but it’s nice to know I could if I wanted to.

I’m just scratching the surface in terms of what Drupal can do, but am very pleased with the look and feel and ability to present distributedly-generated content that this tool affords. If you are looking for a platform for a webstite, take a long look at Drupal.