WordPress released a couple of quick changes, one to fix some things and one to fix something the earlier one broke. Continue reading “Updates take two”
It has been nearly a year since an updates post has been made; here are the highlights of the past year: Continue reading “New Year”
On 7 Mar., WikiLeaks released documents reportedly stolen from the Central Intelligence Agency of the United States (CIA) which provide evidence the CIA knows of, and uses, zero-day exploits in iOS and Android operating systems, as well as other platforms. The agency has chosen to leave their citizens vulnerable to hackers and spies so they may use these exploits to hack and spy.
Of particular importance to understand, as regards GenWeb.Io, is that these vulnerabilities and weaponized software to exploit them were stolen from the CIA. This means the digital thieves already have, have had for some time, and are likely using these tools. The CIA hired firms and individuals to develop these weapons in some cases, and in others developed them in-house or in collaboration with other US intelligence services such as the FBI and the NSA.
WikiLeaks chose to suppress the release of the source code and compiled tools, but did release information describing at least some of the exploits, presumably in the interest of forcing a response from the producers of the vulnerable platforms and devices.
What we did about it
We had previously instituted what we believe to be best practices for an amateur managed server. We are monitoring, on an ongoing basis, server security communications channels and querying software providers for guidance, if they have any.
What does this mean for GenWeb.io sites?
- We use encryption, primarily to provide visitors with protection from man-in-the-middle attacks. We cannot guarantee, now or in the near future, that our ssl is protecting visitors because their device may have been compromised.
- If you host on GenWeb.io, there is little other change from prior to the confirmation of these actions by the CIA. However, it is likely many platforms, including those used in the stack of the GenWeb.io servers, will receive expedited security-related updates. This may possibly involve brief service outages for unplanned maintenance; we just do not know.
We will keep you posted if there are developments.
Often amateur genealogists are looking to find a family member, and turn to GenWeb coordinators for help. And, in order to help them, they need to share a bit, or a lot, of quite private information – possibly about living persons (like themselves!)
We need to make available a secure, private channel of communication. One simple method of doing so is to set up your genweb.io website to transmit e-mail which is encrypted. Here is a simple tutorial which will walk you through the process – it assumes you have an e-mail service provider (such as GMX Mail, Zoho, or Gmail) and you are using some form of PGP/GPG e-mail encryption (there are many many many tutorials on this, just search for e-mail encryption with the name of your preferred e-mail client.)
Using three different WordPress plugins you will lock down all e-mail communications from your GenWeb.io project, and give your site a beautiful form system which you can use for more than just a “contact form”.
GenWeb.io provide many plugins which can help with various aspects of managing an internet website. The three we will be working with in this tutorial are WP-Mail-SMTP[WPP], WP PGP Encrypted Emails[WPP], and Contact Form 7[WPP].
The first step will be to send e-mail from your GenWeb.io project through your e-mail service provider. This prevents GenWeb.io from knowing what you and your users are doing via e-mail. Without this step e-mail first goes through our server’s system before being forwarded to the internet, which is just one more place it could be logged and tracked (this is not something we do, but you should not just trust us.)
The second step is to install a tool which encrypts e-mails which originate from your site. This, again, is to ensure that GenWeb.io cannot log your or your user’s e-mails, and it also prevents anyone snooping on the traffic from being able to know anything more than the sender and the intended receiver. Incidentally, it also prevents your e-mail service provider and the receiving e-mail service provider from knowing the contents – GMail, for example, is known to use the contents of e-mails to build your advertising profile.
The third step is installing one of the most popular form-managing tools for WordPress – Contact Form 7. This tool can help you build almost any kind of form you might want, from a shopping cart to research survey. But we will only use the tiniest fraction of its abilities – a shortcode which lets you add a feedback/contact form anywhere you would like in your project.
Setting up SMTP
The de facto standard for sending e-mail is the Simple Mail Transfer Protocol, SMTP. This is what your e-mail client uses to talk to your e-mail service provider, and the same information you used to set up your client is going to be necessary for setting up WP-Mail-SMTP: you will need the name of the server, the port number it communicates on, the type of security layer used (if any), and the type of authentication your service provider uses.
The first thing to do is activate the plugin: Dashboard -> Plugins and click the activate link for WP-Mail-SMTP. This will add a new menu item, Dashboard -> Settings -> Email, which is our next click.
The first setting is the e-mail address. If you plan to use the same e-mail address as you used when setting up your GenWeb.io project you can leave this blank and it will use that address.
The second setting is for the From text. You may want to put the name of the region you are coordinating – for example “Marshall County, Minnesota”. This will show up in messages sent from the site as “Marshall County, Minnesota <email@example.com>”
The third setting is a radio button. We are setting this up to use SMTP, so it does not need changing. The other options are a service which can deliver mails for a fee, or the normal WordPress delivery method. (Using the normal WordPress method will currently result in all e-mails from your site being discarded as spam by most e-mail services.)
The fourth setting allows you to decide to use a Return path. If you are using a different address than the default for your site you may want to set this.
Below this are the SMTP settings, which are the items provided to you by your e-mail service provider. These need to be entered exactly the same as when you were setting up your e-mail client.
For example, if I were setting up to use a gmail address I might used the following values:
- SMTP Host: smtp.gmail.com
- SMTP Port: 465
- Encryption: SSL
- Authentication: Yes, use SMTP authentication
- Username: Example@gmail.com
- Password: MySecretPassword
Note: The password will be displayed in plain text. This is not insecure! you are already working via SSL. But it makes me nervous, too.
Click to save your settings, then type in your e-mail address in the Send a Test Email box, and click send test. This will display the results of talking to the mail server, and hopefully will be successful immediately. The test e-mail should arrive at your inbox nearly immediately; make sure all of this is working before the next step.
Setting up PGP Email
Pretty Good Privacy is a very nifty and light way to reliably encrypt and decrypt e-mail using public-private key sets. Activate the WP PGP Encrypted Emails plugin: Dashboard -> Plugins WP PGP Encrypted Emails, click on the activate link.
The plugins page will reload, with a button at the top in a notification box “Generate PGP signing key”. Clicking this generates a reasonable key, so go ahead and do so. It also raisess the General Settings screen (Dashboard -> Settings -> General), where this plugin’s settings are now available to be edited.
Scroll down to Admin Email PGP Public Key. This is where you need to paste your public key. The website will use your public key (not your private key!) to encrypt e-mails it sends to you, so it stands to reason you need to enter it here.
Encrypting an e-mail is like putting it inside an envelope: the only thing visible should be the address of the receiver, and the address of the sender. The next setting, Always empty subject lines for PGP-encrypted emails, moves the subject line to the inside of the encryption envelope. Other wise your e-mail is sort of like a postcard: anyone can read what it is supposed to be about, even if they cannot read what is inside.
You will probably want to download the newly-generated public key to your computer, and then import it into your e-mail encryption system. This will let you actually read the e-mails sent! The public and private keys can also be manually set – if you have generated keys yourself – and can also be re-initialized.
For other people who are going to receive e-mails from the site, they may be out of luck being able to decrypt unless you set the next setting: Sign email sent to unrecognized addresses. This will include the public key signature on each e-mail. Note the word “unrecognized”! Enabling this plugin allows each user to store their public key in their account on the server allowing encrypted communications.
Finally, ‘Delete the PGP signing keypair on uninstall’ will completely delete the keypair when you disable this plugin. It is good practice to delete unused keys, however archived encrypted e-mails will become impossible to decrypt without the key. On the other hand, if you never disable the plugin you will never need to worry about this.
Now go back to Dashboard -> Settings -> Email and send yourself another test e-mail. Everything on the server side should be completely unchanged. You should get an encrypted message, and you should be able to decrypt and read it. Make sure this works before moving on!
Creating an e-mail form
This is by far the easiest step. Dashboard -> Plugins and click on the activate link for Contact Form 7. When the plugins page reloads there is now a link to the Contact Form 7 Settings. Clicking this will show you a page indexing all the contact form templates, at the moment there is only one entitle Contact Form 1. The next column over is the shortcode column; it should look something like
[contact-form-7 id="401" title="Contact form 1"]
If you click the shortcode it highlights so you can copy it.
Now create a new page: Dashboard -> Pages -> Add New. Give it a name like “Contact us”, and then in the body paste the shortcode. Click the preview page to see what the form will look like. You will probably want to write a brief introductory sentence/paragraph.
Please use this form to send us a private e-mail.
[contact-form-7 id="401" title="Contact form 1"]
When everything is working, add the contact page to a menu and/or link to it somehow. It may not be the main way people will get in touch with you, but it is an important tool to keep handy.
As we the end of the year draws close, and we look ahead to the coming year, it is time to assess where we are at and where we are going.
The past six months have been challenging – new server equipment, moving the server hardware to a new hosting location, new ISP, and dealing with physical issues (one of which is ongoing.) We have just upgraded to the latest stable release of WordPress, and a dozen or so of the opensource and commercial plugins, themes, etc. We have added a Piwik server for counties which wish to monitor their site traffic, and increased storage for all sites dramatically.
In the next six months we hope to add an installation of WebTrees, a collaborative genealogy presentation and management software, and an authentication platform which will work across our primary services (but has yet to be determined.)
There has been another security update, so here is a brief run-down (this one is simpler than the previous one:)
What we did about it
We have installed the upgrade, which updated the two third-party libraries which had newly-discovered vulnerabilities.
What the vulnerability was
There were two, separate, vulnerabilities; both were in third-party tools used in WordPress.
The first issue was in Plupload, a tool used for managing file uploads, which in certain circumstances could allow a remote person to perform actions on the site which the user did not initiate. This is called a Same Origin Method Execution (SOME) vulnerability. In this case other security measures in WordPress limited the risk, and it only affected the 4.5.1 release, therefore not a high-profile (but still high-priority) issue.
What this means for you
Nothing, as far as we are aware. The issues are completely fixed.
However, it exposed that WordPress is not strictly using HTML5 audio and video. Everyone on the internet should be using a modern browser which supports HTML5; there are inherent risks to older browsers which simply cannot prevent certain types of internet security and privacy attacks which have been resolved in newer browsers. By supporting old, vulnerable browsers (by using MediaElement.js) WordPress is enabling users to continue being at risk rather than encouraging them to update/upgrade.
What we did about it
GenWeb.io has upgraded to the current stable version (we always do, usually within minutes of the release.) We have also addressed the so-called “ImageTragick” vulnerability in the ways currently suggested by the ImageMagick developers. But, just for your own peace of mind (and ours!), please ensure that your regional site does not allow users, forum posters, or commentors to upload photos. Also, please do not ‘upload’ images using urls as this is another vector for this exploit to be used. If you are using the PressThis tool to republish articles from the internet, this is another way to infect your site.
What the vulnerability was
The issue addressed by WordPress potentially allowed someone to run a script in a visitor’s browser when displaying/streaming certain kinds of media. Obviously could not directly affect your website, but it could get your site blacklisted as a source of malicious scripts even though it wasn’t really your site doing the harm to the visitor. This is completely fixed by the security update.
The issue with ImageMagick potentially allowed remote code execution (RCE) on the server. When images are used in WordPress they are processed in various ways using ImageMagick – to create thumbnails, or change a photo’s dimensions, or in other ways – and during that processing ImageMagick could be convinced to execute instructions on the server. This could in theory do almost anything the webserver has the ability to do, including severely harming your site or the webserver itself. This is not completely fixed by the security update from ImageMagick, and so the vulnerable portions of ImageMagick have been disabled. Most likely this will not affect your site, but be aware of possible issues if you use .svg or .mvg graphics. There are known attempts to use this exploit in the wild, but GenWeb.io sites should no longer be vulnerable.
What this means for you
Nothing, as far as we are aware. When a more-complete fix for ImageMagick is available we will re-enable the possibly vulnerable portions again. In the meantime, if you have any issues with any media on your site (especially media which do not resize correctly) please use the secure contact form to get in touch with us immediately.
Well, it’s always frustrating when there is unplanned server downtime.
Today we upgraded the operating server operating system, and most of the server stack as well. This was expected to be a relatively brief outage after making backups of everything. Unfortunately the system upgrade took more than two hours, and another stretch of time for the 800+ packages involved. There are still a couple of sites offline awaiting non-essential manual over-rides.
For which I am deeply apologetic. I plan to address this over the next couple of weeks, developing an alternative model for system upgrades.