Category Archives: Security

WordPress automated upgrades

Blogging, Security, WOU website

When we upgraded to WP 3.8 right around the new year, I noticed that it promised to automatically apply security updates.  Sure enough, we now have 3.8.1 without any of us having to lift a finger.  It’s always nice when something works like that.

If any of you still have WordPress sites on our server that are not part of the main install at wou.edu/wp, please be certain that they are upgraded to the latest version!  Un-maintained WP sites are a serious security hazard, and unfortunately we’re going to need to be a little tighter about separate WP installations.  If you have a site like this and want to move it to the central installation, we can help you with that; just contact me at swartzer@wou.edu.  Also, if you know of one of these separate WP sites that isn’t needed anymore, let me know and I’ll remove it for you safely.

Not to toot my own horn or anything…

Programming, Security, WOU website

Yeah, whenever anybody says that, they actually mean they *are* going to brag about something, I know.  I think I just did something kinda cool, though.  See, one of the departments has a few pages of their website on a third-party webhost, due to a long and complicated story that I’m not going to get into because this is already going to be a long explanation.

This hosting company is flexible enough that Danielle could make our template work over there, but there really wasn’t any way to include the departmental navigation files from our site.  They’d just have to edit both the local copy for their pages on our servers, and the hardcoded version on every page on the other web host.  Making it worse was the fact that the webhost only allows a certain number of edits before they start charging every time a file is changed (which still boggles my mind.)

Ordinarily we could just use curl() or the like to fetch the file from our server, but this company doesn’t use PHP.  They still run ColdFusion, of all things.  If ColdFusion has a way to fetch and include offsite files, I don’t know it. But I figured out a way to use jQuery and JSONP to have the pages on the other host talk to our webserver and get the sidebar include file they need.  They just need to source a JS script from our site, and it reads variables from the page to know which navigation files to include.  I could’ve hard-coded it for this one department, but I hate doing that when I can make a tool that can be used again.

But, security! I hear some of you saying.  You’re right that it’s a bad idea to let people fetch files off your site based on javascript code; anybody can mess with it using Firebug or some such, and change the variables.  That won’t work too well here, though; it’s locked down to specific folders and filename patterns (no slashes or .. for instance) plus there are a couple more secuirty features I’m not going to talk about.

If you want more detail, email me.  That’s all for now.

SSL certificate weirdness

Explanation, Security, WOU website

Recently we moved the WOU forums server to a better machine, but then we noticed that Internet Explorer was no longer accepting the server’s SSL certificate, so it couldn’t make a secure connection. Firefox, on the other hand, was perfectly fine with the cert and established a perfectly valid SSL connection.

Those of you who are all up on modern web security practices probably recognize this problem already, but I didn’t have the relevant information and was completely boggled.

When I looked at our certificate vendor’s support site for the third or fourth time, I found a certificate installation checker. It was right there on the support homepage all along, but I guess you tend to miss things if you’re only focusing in on your latest guess rather than keeping the main problem in your mind.
Anyway, this checker lets you enter a hostname and port and it will tell you if the cert on that connection is valid, and if not, what’s wrong with it. That told me that the forums server was missing two intermediate CA certs. I didn’t understand what was up with that, but it gave me the certs to install, so I shrugged and dropped them into the webserver’s cert DB and voila– IE quit complaining and reported a valid secure connection.
I still didn’t understand what was going on and why that solution worked, so I did a bit of digging around.
Apparently in recent years, certification authorities have moved from signing customer certs directly with a root certificate, to signing them with an intermediate certificate which is signed by the CA’s root (or possibly by a higher-level intermediate cert that is signed by the root). All modern browsers come with root certs from many different certification authorities, but that is no longer enough by itself because most site certs are no longer directly signed by the CA root.
Firefox has a bunch of intermediate certs installed in it by default, so it can validate certs from sites that don’t provide the whole chain. IE on the other hand only has the root certs, so unless a webserver provides the intermediate certs, IE users are out of luck (insert obligatory firefox-is-better assertion here.)
I suppose at some point I could explain about SSL and certificates and signing and all that, but maybe later.

Creating a Google Docs account

Accounts, Explanation, Google Apps, Security

This is part of an occasional series of instructional posts on various topics.

If you want to use Google Docs but don’t already have a Gmail or Google Docs account, you’ll need to click the “Create an account now” link below the login box, which will take you to the account creation form. There, you need to enter the following:

  1. Your current email address. This does not need to be a gmail address, but must be a real address where you can get a confirmation email. Your wou.edu address is OK to use here. Note that this entire address will be the login name for your Google Docs account.

  2. A password. For security reasons, you should NEVER use your WOU password on a non-WOU server. Please create a password that you can remember; it must be at least eight characters long and ideally should include at least one number and punctuation mark. It is OK to write down this password as long as you keep it in a safe place, such as with your credit cards.

  3. Re-enter the password to confirm that there weren’t any typos the first time.

  4. If you are likely to use publicly accessible or shared computers to log in to Google Docs, uncheck the “Stay signed in” checkbox. Otherwise, it is OK to leave it checked so you won’t have to log in as often.

  5. Uncheck the “Enable Web History” button, unless you are comfortable with Google tracking and remembering searches that you make even when you are not logged in. Click the “Learn More” link for more information about this.

  6. Choose your location from the dropdown menu; if you are in the US, the menu will probably already be set to “United States”.

  7. Enter your birth date. Make sure to use a four-digit year.

  8. Type in the verification word. This is necessary to show that you are a person and not some computer program trying to automatically create an account for some sneaky purpose. Unfortunately, their verification words are rather hard to read, because Google is attacked often by hackers and they have to be very sure you are indeed a human. Sometimes the letters are extremely narrow and squashed between two others, but luckily it doesn’t matter whether you type them in capitals or lowercase. If you have trouble with the visual verification, turn on your speakers and click the handicapped icon. After a few moments, you will hear three beeps followed by a slowly spoken series of numbers with a computer-generated random muttering in the background. Sometimes you will hear non-number syllables like “oway”, “no”, or “yow” in the foreground; ignore those and pay attention to the numbers alone. You will hear the words “once again” and the code will be repeated.

  9. If you are so inclined, read the Terms of Service. A more readable version may be found at “http://www.google.com/accounts/TOS?hl=en“. Here are some important points:

    • You agree to do nothing illegal, nor attempt to hack or otherwise mess up any of Google’s services.

    • You agree that Google can change the features of their service without notice.

    • You agree that Google isn’t legally responsible for what you do with your account, and that you can’t blame Google if you see anything objectionable.

    • You agree that Google does not guarantee that their service will be available 100% of the time

    • Google agrees that you retain any intellectual property rights to content you upload.

    • You agree that Google has a license to display your uploaded content as part of its services, i.e. if you share content with anyone, Google is legally allowed to show it to them. This is the infamous “Section 11.1” which looks very scary when read by someone not versed in legal technicalities; you can find more information at “http://docs.google.com/support/bin/answer.py?hl=en&answer=82366“. The key point is that the license granted in Section 11.1 is limited by the Google Docs Privacy policy which states that your information is only shared with people whom you designate. Click here for an independent opinion. Further information can be found by doing a web search for “Google Docs Terms of Service Section 11.1” without the quotes.

  10. Assuming you are satisfied with the terms of service, click the button below them that tells Google that you agree and want your account created. You may need to retry once or twice to get the verification text right.

Once you are done with the form, you will get a confirmation email at the address you gave in step one. The subject line will be “Google Email Verification” and it will be sent from “account-verification-noreply@google.com”, so make sure your spam filters are set to allow the message through. You should save this message, because you may need it again if you forget your account name or password. Consider saving it as a file in your home directory, so you have a backup in case the email is accidentally deleted.

Click the verification link near the top of the email. You’ll be taken to a page that confirms that your account is now active and gives you several options and informational links. It is not necessary to link your account to a gmail address or a mobile phone, but you can do so if you want to. However, instructions for those actions are beyond the purpose of this document.

The “Click here to continue” link will take you to Google Docs itself, which I will cover in another document.

Email scams again

Security, Spam/Scam

People keep reporting emails that say something like:

Dear network user,
Your account has violated a quota and will be turned off.
To avoid this, email your login name and password to
somebody@somewhere.com.

Signed, wou.edu administrator

To us geek types, this is obviously a scam. I just keep getting reminded that other people don’t instantly spot this for what it is, even when it tells them to send their info to a non-WOU address. It can be even harder to spot when the From: address on the email is something like admin@wou.edu, or the message tells you to go to a link that looks like it’s on our website but actually goes elsewhere.

So really what we need are some general rules of thumb. The first and most obvious is never, ever, ever, EVER put your password into an email message. Never. And did I mention never? Of course this means we UCS folks should never ask someone for their password except in person — we really don’t even want to get users in the habit of saying their password over the phone.

Another rule of thumb would be never trust emails from generic addresses. When we send messages out, they’ll have a specific name on them, not just “admin@wou.edu” or some such.

If we agree on this among ourselves and communicate it to users, hopefully that’ll help everybody.

Project Honeypot

Security, Spam/Scam

A couple years ago I signed up for Project Honeypot, which is a distributed network of fake email domains set up to catch spam for research purposes. All I had to do was create a subdomain off of a domain I already had (I didn’t use any WOU resources for this) and set it up to point to the Project Honeypot servers, and then forget about it. They don’t even need access to my site or anything.

So anyway, I hadn’t thought about this in a while, but this morning they sent me a notification that they’d caught their one billionth spam message (which happened to be an IRS phishing scam, in case you’re curious.) They also included some statistics (Quoted from their email:)

  • Monday is the busiest day of the week for email spam, Saturday is thequietest

  • 12:00 (GMT) is the busiest hour of the day for spam, 23:00 (GMT) is the quietest

  • Malicious bots have increased at a compound annual growth rate (CAGR) of 378% since Project Honey Pot started

  • Over the last five years, you’d have been 9 times more likely to get a phishing message for Chase Bank than Bank of America, however Facebook is rapidly becoming the most phished organization online

  • Finland has some of the best computer security in the world, China some of the worst

  • It takes the average spammer 2 and a half weeks from when they first harvest your email address to when they send you your first spam message, but that’s twice as fast as they were five years ago

  • Every time your email address is harvested from a website, you can expect to receive more than 850 spam messages

  • Spammers take holidays too: spam volumes drop nearly 21% on Christmas Day and 32% on New Year’s Day

You can find lots more here.

So how does the Web really work, anyway?

Blogging, Explanation, Security, Spam/Scam

I’m always fascinated to learn how things work, especially stuff we completely take for granted, like for instance how electricity gets from a power plant to your house. So in the hopes that there are others like me out there, I’m going to describe the inner workings of something most of us take for granted: the World-Wide Web.

Naturally this is going to take more than one post, since I’ll try to start from fairly non-technical concepts, and use analogies. Those of you who already know most of this may find the explanations not quite accurate, because I’ll leave out a lot of the nitpicky details, especially at first. I don’t have an outline in mind, so I can’t say exactly how this is going to go, but here’s a basic idea of what I’ll try to cover:

  • Internet 101

  • What is a protocol?

  • Before the Web was born

  • HTTP vs. HTML

  • Why are there different browsers?

  • What’s a URL and how do I read it?

  • What is actually happening when I click that link?

  • How does the page get to me?

  • What if there’s a problem?

  • How forms work

  • Secure connections (HTTPS)

  • E-commerce and shopping carts

  • Web video

  • More security concerns

  • What’s “Web 2.0”?

Hmmm, OK, just off the top of my head I came up with a lot more than I thought I would. And there’s a lot more where that came from! So we’ll see how far I get, and how many entries it takes.

Adobe Flash security hole

Blogging, Security

This is sort of scary.

For those not familiar with security terminology, this article states that websites which allow uploading of Flash files are vulnerable to a security hole that lets bad guys run code that has all the security accesses of the webserver combined with those of the unsuspecting person who runs that file.

For instance, an attacker could send a specially coded Flash attachment to their victim in a gmail message. When the victim loads the attachment, it gets to do anything the gmail server could do with the victim’s account; reset the password, delete messages, send messages (spam!), etc.

The scariest part is that there’s not really a fix without significantly changing the way Flash works behind the scenes. In the meantime, you should avoid flash that isn’t directly provided by the website you’re going to. For instance, the Flash slideshow on the WOU homepage is OK because we wrote it, but if you go to somebody’s personal website like “https://wou.edu/~joeblow” then you should be careful unless you personally know that Joe Blow isn’t the kind of person to play nasty tricks.

Actually that’s not really the best example, because even if Joe Blow has one of these malicious Flash files on his webspace on our server, it wouldn’t profit him much because there’s nothing much our webserver can do other than show you web pages. The WOUPortal and the Sun Java Email system are on separate servers, so they wouldn’t be vulnerable to Joe Blow’s attack. Of course, Joe Blow could send you a Flash attachment in an email, and if you open it in the Java email system, it could do nasty things to your email account.

This security hole isn’t easy to exploit, but it is theoretically possible. I recommend limiting the Flash files you run on the Web; there are browser extensions to help you do that. If you use Firefox, an extension called NoScript can block Flash files (and malicious javascript code as well) on all sites except those you designate as safe. If you use Internet Explorer, you can install Toggle Flash, a toolbar button that lets you turn Flash off and on whenever you want. Instructions for both are available in (ironically enough) a flash video on the page I linked at the top of this entry. Don’t worry; Foreground Security is a reputable company, so the video is safe to watch.