The idea of the generator is along the same lines of the original generator posted on the GRC website, but has been done as an implementation example of Bart’s perl library xkpasswd — the “xk” being a reference to the xkcd comic which discussed the same subject around the same time as the Security Now episode talking about password haystacks.

The general theory behind haystacks is that you take an easy-to-remember password like monkey (or m0nk3y) and bury it an easy to remember, but very long “haystack” of other characters. The sheer length of the password makes it orders of magnitude harder to guess than the original password.

Example: !@#$1234-Monkey-1234!@#$ and just like that you have created a 24 character password with upper case, lower case, numbers and symbols which (if you look at it for a minute) is going to be really easy to remember — especially if you recycle the “haystack” portion and pair it with other simple words to create a multitude of never-have-to-write-em-down passwords.

So what about xkpasswd? Well the idea is this, the tool will generate for you a list of easy to remember words buried in a haystack of simple padding characters. He has also added a number of presets for things like an Apple ID, WPA2 wi-fi security key and web sites (short and long) in case you do not want to tweak the raft of available options.

It is a great little tool for generating passwords that adds some intelligence that you do not get from the typical random password generators like the ones built into LastPass, 1Password or SuperGenPass. I highly recommend you check out xkpasswd if you are looking to augment your password arsenal. If you are a developer, check out the library available from Bart’s website if you want to include this functionality in an application that you are developing.

The Problem

In retrospect I can see five things I did wrong, and all of them can be traced back to laziness or perhaps, to be less forbidding, they can be traced back to actions taken (or not taken) for the sake of convenience.

Error #1 – Out-of-date Software

Many of us take the time to make sure our operating systems and browsers are up-to-date and fully patched; but do we take the necessary time to make sure that all of our software is patched? Particularly things which don’t reside on our home computers? If you run your own blog, forum or other website and are responsible for your own updates can you say unequivocally that you are currently running the latest and greatest version? Software that is out of date by as little as one revision may have critical vulnerabilities which could allow for disruption of your site, or even execution of commands on your web server.

([aside: If you don't use Secunia's PSI product on your home PC at least once a month, you should.])

Error #2 – Abandoned Web Properties

This goes hand-in-hand with the out-of-date software but is, in some ways, a bit trickier to prevent. It is far easier to remember to update software on sites which you update and monitor on a regular basis. It’s far more difficult to monitor sites which have been, for lack of a better term, abandoned. In my case there were three separate sites on my account which were running versions of their software which were more than 12 months out-of-date. The reason was that I was no longer maintaining these sites and had, in essence, forgotten they were still there. I had hidden a couple of them by renaming the homepage which made it look (to the casual observer) like the sites weren’t there but of course all of the other pages were still in their normal locations and were full of holes.

Error #3 – Shared User Accounts

Sharing is good, right? Not in this case… I have a several different domains hosted under a single hosting account. DreamHost is really generous allowing customers to register any number of domains and attach them to the account. I host sites for myself, for family and for a couple of organizations I’m affiliated with. This in and of itself does not cause a problem. The security hole in my plan was that most of these domains were hosted on a single user account. This means that if that shared user account gets compromised, all of the domains which are run on that user account are potentially at risk.

Error #4 – Lack of Backups

The websites had no viable backups. Because no regular backups were being run of the account, it was virtually impossible to trace when the hack initially occurred. If there had been regular full or differential backups being made of the various websites it may have been possible to determine when the initial attack took place and roll all of the sites back to the way they were before they were compromised. In addition, if there had been any data loss (there does not appear to have been) the lack of backups could have meant the loss of many hours of work.

Error #5 – Reused Credentials

We hear it all the time – do not reuse usernames and passwords on your various accounts, particularly accounts you care about or are important. Account reuse increases the chances that a hack on one site can do more wide-spread damage than the initial compromised password should really allow. My main SSH credentials were a username and password that I had used on over 100 different sites and services. I know for sure that one of the web properties I use had these particular credentials released into the wild. Why didn’t I change the password? I don’t know. If that was the entry vector, it is quite possible that a number of other accounts of mine have also been compromised.

Overall Impact

The impact was (thankfully) minimal. Only two sites of value were compromised, and it appears that all of the data for those sites is undamaged. A number of other obsolete sites were compromised as well but as they are no longer actively used they are of no great loss.
It also appears that some sort of mass-mailing script was being run from the account as well. My server-side user account had received over 27K “Message Undeliverable” replies from various web servers. I hate to think how many it was able to send successfully.

The Cleanup

The cleanup had to be done in phases, addressing each of the five defects individually. Some of them were very easy to change, others required quite a bit more effort to implement and verify. However before any of the remediation could begin, the site needed to be cleansed.

The very first step was to ensure that my local machine had not been infected or compromised. I was pretty sure that it was clean as scans are run every night, but it would be like trying to wash a car with mud. No amount of scrubbing with the muddy sponge would get it clean. The machine checked out.

The second step was to change the passwords for all of the users on my hosting account, and change the main password for the account itself.

Next, data from the websites that needed to be saved was exported. None of the code for the software running those sites was saved, only the data. There was no way to tell if the software was clean or compromised so I decided to take no chances. The application software is not that difficult to install, and I was willing to take the hit on setting up modules, components and themes anew.

Once the data was backed up I wiped out all of the data on the user accounts which were being preserved. This meant a full wipe from the file-system from the operating-system shell on the server. All files and directories including “hidden” and “special” folders were wiped out. Some of these operations required the assistance of a DreamHost technician.

Step #1 – Remove all unused or obsolete websites

This was taken care of as part of the cleanup activities mentioned above. Simply removing the affected websites greatly decreased the attack surface of the account and reduced the number of attack vectors which could be used to attack the websites and/or the account.

Step #2 – Remove all un-needed user accounts

In the case of any obsolete sites, test accounts or test databases, these were removed directly from the hosting provider’s control panel as they would no longer be needed. Much like response #1, there is no sense in keeping any old files or data hanging around where they might later become a liability.

Step #3 – Change the passwords again

Once all of the files, scripts, data, databases, directories, logs and anything else I could think of were removed from the sites, the passwords were rotated again. This was done in the off-chance that there were cached credentials or some other form of persistent authentication lurking somewhere in the ether.

Step #4 – Create new per-domain user accounts

For each of the domains that would be remaining active, a new user account was created specifically for that user. These accounts would be used to connect to and install the necessary software on the websites, as well as to run backup and maintenance scripts. Passwords for these accounts were set to extremely long strings of random characters as they would not be required for day-to-day access and maintenance.

Step #5 – Set up public key authentication

For regular access to these sites, I decided to go with public key authentication. By requiring a private key (stored in an encrypted volume on my main desktop) and a lengthy but easy-to-remember passphrase I could fairly safely rely on the same public/private key pair to secure access to all of the websites. I found out during this step that both PuTTY’s puttygen application and my hosting provider’s implementation of OpenSSH have an upper-limit on the length of the passphrase. It is still a very long upper limit, but I was surprised to find it. If you share access to a website keys can be installed for each trusted user using the same method.

Step #6 – Change passwords again (optional)

Once the public-key authentication is in place the account passwords can be changed at will without affecting the state of the affected keys. This means that I have effectively made the public keys the only viable way of accessing the site over SSH short of having access to the main hosting provider account to do a password reset. Admittedly this step is for the very security conscious (read: paranoid) as I was quite certain at this point that the passwords on the system at this time had not been compromised. This however is to be the first step in a regularly scheduled series of password rotations that the system will handle on my behalf as a part of standard system maintenance.

Step #7 – Reinstall all server-side software

Once all of the base security measures was in place and tested, I set up the application software I wanted to run on the web server. The key here is to do the set up using copies of the software obtained only from trusted sources. What a trusted source is will vary from software package to software package, but typically the main project site for an open-source project (not a mirror) or the vendor website are good places to start. In this case downloading the latest stable WordPress release from the main website <link>.
I made sure not to rely on previously downloaded installation packages, getting the newest most up-to-date version I could lay my hands on.

Step #8 – Configure server-side software

Each software package is different, but going through all the configuration steps for your software package is important: don’t try to short-cut the process. In the case of WordPress we have to set up a MySQL database, set a number of hey/hash values which are used for authorization and cookies and finally set up the user accounts. I wanted to make sure that any passwords, keys or salt values were set using long randomly-generated strings. In my case I used the password generation function in LastPass. Other options would include tools like 1Password, RoboForm or Perfect Paper Passwords <Links>. The longer and more random the string is, the more difficult it will be to crack. I have been using values from 24 to 64 characters in length depending on the purpose.
If you have a system that assigns default passwords for new user accounts, be sure to change those default system-generated passwords and replace them with your own strong credentials at this stage.

Step #9 – Set up extensions and themes for server-side software

Once I got the base configuration is in place it was time to add in the additional features I required for these sites. In my case it was a collection of WordPress plugins and themes. It is easy to forget that each extension, plugin or theme that you add to your website’s software package is in fact additional software that will be executed when the website is used. Just as with the base software package it is important to trust the source of your plugins and themes. If you are suspicious as to the origins of the software, choose something else.
I also added the plugins and themes one at a time confirming after each step that there were no immediately visible defects.

Step 10 – Automated backup

The next step was to add a backup script for both the website and the associated database. By building this as a shell script it was possible to schedule full backups of the various sites and have them run on a set schedule. For now the script is very simple:

1. Extract the contents of the database
2. Zip the website and extracted database into a single archive
3. Send that file over SFTP to a location off-site from the server

There are other ideas for automation as well, but this post is long enough as it is. I will save those for later.

Lessons Learned

This could have been much worse. In many ways I count myself very lucky. I could have had all of my data wiped out, I could potentially have seen malware/scripts injected into my websites to capture login credentials or other sensitive information. This attack served as a warning and though I have had to spend a number of hours rethinking the way my websites are set up and managed, at the end of the day I will have better control over the sites I manage, better practices in place for dealing with security, and with any luck, better personal habits for dealing with information security.

Last, but certainly not least, a big thank you to the folks at DreamHost for confirming my initial diagnosis, helping to find the  possible entry vectors, providing guidance on cleanup and purging, and just generally doing that great customer service thing that they do.

• Facebook found a problem in the way that it was authenticating applications.
• Any time you used an application a token was created that would allow the application to do it’s thing — including posting on your wall, accessing photos or whatever other permissions it requested.
• The tokens did not expire and were being “leaked” through normal operation on Facebook.
• Anyone who found a token would be able to use it to do the same things that you allowed the application to do — including posting on your wall, accessing photos or whatever other permissions it requested.

It is important to note that Facebook has said there is no evidence that this has been exploited — yet.

The problem has now been fixed, but all the old tokens could still be usable until September 2011. You can re-secure your account by simply changing your Facebook password. This will invalidate any of the existing tokens.

Information Week has an article with more detail.

The key to the “vulnerability” with OAuth is that each application is given its own key. That key ties any request made to the service (Twitter for example) to the application which owns the key. The concern was that if the key falls into the wrong hands users’ personal information could be put at risk. With the key needing to reside somewhere that the application can read it, they’re typically stored within the application code which makes finding the key a trivial matter for a hacker.

The thought occurred to me that if you need to access a web-based service which requires OAuth, it might be helpful to have an intermediary service handle that authentication for you. By adding a service tier which authenticates a specific user of your application and performs all of the direct interaction with the service there’s no need to keep the OAuth keys on the client which makes them much more difficult to compromise.

No operating system is perfect, they’re all designed by people and are full of flaws as a result.  It’s important to keep in mind that one of the reasons that Mac OS X has had precious few problems with viruses and other nasties is market share.

Writing viruses is much like sending out mailers for advertising your new business. The more people you reach with your message (or malware) the more people you’ll connect with (infect).

If you want to infect lots of people, you write your malware for Windows.

Five years ago the market share of the Mac was in around the 5% mark, meaning that if you wrote a virus for the mac and distributed it to 20 million computer users you’d infect 100 people (at a rate of 1 in 10,000). If you write for Windows and infect people at the same rate, you’ll infect 1900 people.

With the market share of the Mac increasing, so does the surface area for attacks. Many Mac owners have become complacent over the years believing that they are safe because they use a Mac. As a result the infection rates of Mac systems could be much higher than Windows-based PCs if malware authors decide to target the Mac platform.

Food for thought.

In your LocalSettings.php file, add this to the bottom:
#Disable Anonymous Editing
$wgGroupPermissions['*']['edit'] = false;

It should be noted that this fix is for MediaWiki 1.5 and later. If you want some ideas on additional things that you can do with MediaWiki security, check out the MediaWiki Manual.

I carried this on for about two months, twitter became less active for me, not much in the way of new friend requests and ultimately a complete drop-off of activity.

Yesterday I decided to unlock my profile again, and resort to the manual removal/blocking of Twitter spam.  Within a few hours I had a bunch of new requests and Twitter activity seems to be increasing more ever since.

So the question boils down to this: To protect, or not?  Do you protect your Twitter?

With a vulnerability so wide-reaching, security researchers decided it would be wise to keep the exact nature of the vulnerability something of a secret until the patches were ready.  They did however announce that a vulnerability had been found.

This announcement was all it took for security-savvy netizens (the ones who know just enough to be dangerous) to start speculating and researching the nature of the DNS defect.  The good thing?  They figured it out.  The bad thing?  They publicized it.

As a keen observer of the whole mess, security expert and blogger Chris Hoff decided to dedicate a poem to the DNS Debacle.  I’ve included a short excerpt:

A bunch of big egos
called Dan on a bluff
said his vuln was a copy
of 10 year old stuff

So Dan swore them on handshakes
and details were provided
and those same cocky claims
soon all but subsided

Go and check the poem out.  It’s extremely creative, and as far as I can tell factually accurate to the events that took place.  My hat’s off to Chris Hoff for providing the prose, now we’ll all cross our fingers and see how it goes… 

Essentially what it boils down to is WP has separated cookies used for accessing the admin interface through HTTPS (SSL) and regular unsecured HTTP.  This allows for login information and the login cookie to be secured through the encrypted stream on every access.

The details are in Ryan Boren’s blog and get into a fair bit of detail.

Go download it!  I’ll wait….

There now… doesn’t that feel better?

Many of the extensions have already been upgraded to work with the new version, and others are sure to follow soon.  I’ll keep an eye on things and try to let you know when PortableApps releases Firefox3.

Also, if you download today (or by 10:00am PT tomorrow), you can be among those participating in Mozilla’s Guinness World-Record attempt.

At first, I gave “John’s Music” very little thought, I was listening to a podcast at the moment and wasn’t interested in investigating.  However soon after, when the show ended, my curiosity got the better of me and I went for a peek.  The music itself wasn’t all that amazing, but upon closer inspection I noticed something else.  I realized that I now knew far more about John than I thought I would and just from looking at iTunes.

Based on primarily his playlist names, and to a lesser degree the content, I was able to deduce:

• John’s last name
• John’s wife’s name
• John has two daughters
• John’s daughters’ names
• John owns an iPhone
• John’s wife owns an iPhone
• John is from the US
• John’s daughter (presumably the eldest) has an iPod Shuffle
• John is highly spiritual and a Christian

Those are some pretty crazy personal details… and they were all there for the taking right out of a publicly shared iTunes folder.

How do I Un-Share?

It’s actually ridiculously easy…

First, go to your iTunes Preference Panel…

Second, unselect the “Share my library on my local network” checkbox.

Now I realize that this may seem a drastic step for those who only ever use their iTunes at home.  But if you travel, or make use of open public wi-fi hotspots (or poached ones) your iTunes library could be giving away personal information without you even knowing it.  It also illistrates the point that not all Apple products ship in a “secure” mode as often touted.  It’s not out-of-the-box functionality, but it isn’t difficult to poach files out of someone’s iTunes folder if they’re DRM free…

Avast did a great job of finding most things and cleaning them up.  What it had trouble with was a few DLLs that were in use by the executing trojan.  I was pointed toward Unlocker to free the DLL’s of their executing process and remove the lock that windows places on these files.  Once the file was unlocked, it was able to be deleted by Avast and all was well.

(Photo Credit: bigux on Flickr)

To me, this is the kind of issue that shows immaturity in the OS.  Though it is possible to run the environment without full-blown admin permissions, some of the functionality of the environment is limited as a result.  There is an MSDN article on the subject which outlines the difficulties that are faced without admin rights.

Most of the problems are only resolvable by running VS2005 using administrative permissions.  Ross Dagan has a post on his blog on just how to set this up using the VS2005 shortcut.

Admittedly this is just another front in the battle between security and usability.  I understand why most of the security features which cause these issues exist in Vista, and admittedly the option to run only Visual Studio in administrative mode does keep the computer quite secure.  It’s just disappointing that there isn’t a more elegant solution.

Some research done by ZDNet Australia’s Munir Kotadia in a series of articles notes that the three top products (by market share) in 2005 were Symantec’s Norton Antivirus, Mcafee Virusscan and Trend Micro VirusDefense.  If the survey results are accurate, or even partially accurate, that could mean that running even two of these security defense products at once may only provide a 20%-40% protection.  Not exactly a comforting thought.

So where does this leave us?  Do we need to install three, four, five anti-virus tools?  Or should we just throw caution to the wind and not bother with anti-virus tools at all… after all what difference does it make.

The survey makes two interesting observations.  The first is that the quality of malware is improving.  The authors of the trojans, spyware and other threats are improving the methods that they use to attack and infiltrate our systems.  The second is that the threats are targetted very specifically.  Gone are the days of teenaged script kiddies who use primitive means of trying to attack or scam people.  Easy enough to detect and clean.

Today’s threats masquerade themselves as useful tools or applications.  This makes them more difficult to detect.  One such example is SpySherriff which though it must be manually installed purports to find various problems with the system and prompts the user to purchase a full copy of SpySherriff.

The vast majority of these threats are targetted at Windows systems.  Why?  Because nearly 90% of people who use the Internet, do so in a Windows environment (courtesy w3schools.com).  So if you were writing software for the home user (be they legitimate or malware) what platform would you target to get the largest number of people to use or see your application??  This puts the comments from Charlie White on Gizmodo in perspective.  When he discusses this subject he sums it up by saying: “Get a mac“.

I don’t want to get into the details of the Windows vs. Linux vs. Macintosh debate here, but let me say that yes its more likely that you’ll get infected with a Windows System.  Thats not a fault of Windows itself, just that the vast majority of threats are written for windows, and initiated by the end-user most often unwittingly.

I know we’ve all heard them before, but come on people some common sense!

• Don’t download programs if you don’t know where they’re coming from.
• Don’t open email attachments unless you’re 100% sure of the source, and you’re expecting the file to be sent.
• Do install some sort of firewall product (Windows firewall works too) to help block unauthorized activity

So what does it all mean?  Well, Virus scanners aren’t perfect (duh), but we already knew that.  Should you use one?  Yes.  Should you use more than one?  It won’t hurt (except for system performance).  Will it help you if you open anonymous email attachments, or don’t use some kind of firewall? No.

Remember: one of Google’s top rating mechanisms is pages that link to you or “inbound links” from its other indexed pages.

• Allowing HTML in Posts
• Allowing Anonymous comments/responses
• Putting some sort of image in to restrict automated account creation & logins

Right now, I’m coming down on the side of putting in place an HTML editing tool like FCKEditor for the Post/Comment editor. This would allow full formatting, and I could strip out

script tags and the like… If anyone has any thoughts on the Security v. Functionality debate, I’d love to hear them…

…back to the vortex…