Check your SPF records

Not to pile on the STM, but checking my junk folder, I discovered an automated email sent yesterday informing me that my OPUS card registration was being processed. The email ended up in my junk folder because the sending server is not whitelisted in the STM’s SPF records as evidenced by the report that SpamAssassin adds to emails that it scans:

1.5 SPF_SOFTFAIL           SPF: sender does not match SPF record (softfail)
1.5 SPF_HELO_SOFTFAIL      SPF: HELO does not match SPF record (softfail)

Some servers will outright reject email that fails SPF checks, so always make sure you’re either using your domain’s official email servers for outgoing mail or add your server to your domain’s SPF records!

 

Flaws with the STM OPUS card’s online registration system

The Société de transport de Montréal (STM) allows OPUS cardholders to register their cards online so that any remaining fares may be recovered in case of lost or stolen cards. Unfortunately, from a security standpoint, the system is flawed in a number of important ways.

Customers are sent to this website to register their OPUS cards. It uses SSL so data should be protected in transit. So far, so good.

The problem is the SSL certificate contains no identifying information about who obtained the certificate:

STM.info SSL certificate details

A domain-validated certificate is fairly easy to obtain since it only requires that the applicant prove they have access to the domain (in this case, contactstm.info). This can be as simple as uploading a unique file to a website hosted under that domain to satisfy this requirement.

Worse, when I tried digging deeper to find out whether the STM really does manage this domain by looking at its WHOIS info, imagine my surprise when I saw it was not registered by the STM at all, but by a marketing company:

Domain Name: CONTACTSTM.INFO
Updated Date: 2015-08-11T20:16:51Z
Creation Date: 2012-06-21T17:42:47Z
Registry Expiry Date: 2017-06-21T17:42:47Z
Registrant Organization: Extract Marketing
Admin Organization: Extract Marketing
Tech Name: SherWeb HOSTMASTER
Tech Organization: Solutions SherWeb, Inc
Billing Organization: Extract Marketing

It’s probably safe to assume this is the company that developed this website, but the optics are not good. Not only is there no information to conclusively link this website with the STM, worse, it sure feels like my personal information—you are asked for your full name, personal questions presumably used to validate you in the future, postal code, birthdate, and a photo of your OPUS card—is being submitted to a marketing company.

Consequences

The fact that the STM relies on a domain-validated certificate provides no guarantee that the certificate was actually obtained by the STM. A phisher could easily register a domain like registerstm.info, set up a website under that domain, then either get the same RapidSSL domain-validated certificate that the STM uses here or get a free SSL certificate via LetsEncrypt. Throw a few STM logos on the website and profit from users tricked into giving away their personal information. That the STM’s own websites don’t provide any assurances about their relationship to the STM only confuses matters further for those who want to verify whether they’re actually sending their information to the STM or some 400-pound dude.

In fact, the main stm.info website suffers from similar problems:

  • Although the site supports SSL and the certificate they have installed is an extended-validation certificate (good!), users never get to see it because the site inexplicably redirects to a non-SSL (http only) connection;
  • WHOIS info for stm.info shows a private registration at GoDaddy, making it impossible to validate whether this domain actually belongs to the STM. Hint: If you want to keep registration details private, do something like the NYC MTA which at least lists its official name as part of the domain registration; however, to be fair, its website also suffers from the same allergy to SSL as the STM’s.

Where to go from here

Fortunately, fixing these problems is not necessarily complicated or particularly time consuming.

Get an appropriate SSL certificate

Not all sites require more than a domain-validated certificate (this site, for example, uses such a certificate), but if you’re going to collect personal details of any sort, a domain validation certificate isn’t enough.

The easiest way to resolve the issue with the contactstm.info website is to get an extended validation (EV) certificate. These types of certificates currently provide the highest level of assurance that you are dealing with a legitimate business entity.

As an organization, getting an EV certificate typically requires submitting supporting documentation (articles of incorporation, proof of business registration, etc.) as well as fielding a phone call from the issuer to a published phone number belonging to the organization.

As a user, you’ll typically recognize these types of certificates by the name of the organization in green in your browser’s location bar next to a padlock icon or some other symbol indicating that the site is secured using SSL.

Even an organization-validated certificate would be better than a simple domain-validated certificate. But considering the STM is a public corporation and they are collecting personal information, an EV certificate would be preferable and its increased cost is negligible.

Include the STM’s info in domain registrations

Make sure to include some reference to the STM in all of their domain name registrations. Don’t rely on private registrations that mask any relationships between the STM and the domain names it operates. Doing so significantly reduces users’ confidence that they are dealing with the real thing while increasing the chances that thieves can set up lookalike sites to successfully steal information from unsuspecting users.

In addition, they could host all of these micro-sites on stm.info subdomains, like opus.stm.info, which would arguably be a better solution than registering unique domain names.

More transparency

There is precious little information on this website regarding how your personal information is used, what laws govern data collection, etc. until you’ve actually submitted your information. This kind of information needs to be prominent and available to users before they commit to uploading their personal information.

Hopefully, these issues will be addressed sooner rather than later. The solutions are simple but can go a long way to improving their current setup.

 

Poodle and curl

I recently secured a server that was still susceptible to the Poodle vulnerability, which involved configuring Apache to no longer accept SSLv3 connections. However, after several hours, I noticed that a cron job that normally refreshes the contents of the client’s database via a curl command line call every half hour didn’t appear to be running anymore.

This is the command that was being fired off every half hour (URL changed to protect the innocent 🙂 ):

curl -L -s --user-agent 'Database Refresh Cron' 'https://serverhostname/db/?refresh'

Additionally, the requests stopped being logged in Apache’s logs at around the same time that I updated Apache’s configuration against the Poodle vulnerability. Curious about this, I ran the curl command manually and got this somewhat esoteric error message:

curl: (35) Unknown SSL protocol error in connection to serverhostname:443

Turns out, the server’s curl command was defaulting to attempting to connect using SSLv3, which had been disabled on the server. Fortunately, the fix turned out to be simple:

curl -L -s --tlsv1 --user-agent 'Database Refresh Cron' 'https://serverhostname/db/?refresh'

This threw me for a loop so hopefully this tip helps someone out there!

 

Reboot

Retro can be pretty cool, but this was actually pretty sad. That’s a screenshot of our website dating back to 2002 (!), which has finally been replaced with a cleaner, more modern version you are seeing now. Never mind HTML5, responsive design, or embeddable fonts — our original site used tables for layout, query string parameters for language-handling, and a long outdated template engine. In fact, the original project dated back so long that CVS was used internally for source control up until a few years ago, when we finally migrated it, kicking and screaming, into Subversion, and then to Git last year.

Our new site isn’t exactly state of the art, but it’s modern, mobile-friendly, and quick-loading. I’m hopeful our next update won’t have to wait another 12 years…