0-Day - Always, “Just around the corner”

Sounds like something from a Bruce Willis blockbuster, or is Morgan Freeman about to shout down his colleagues? Unfortunately it’s real enough and it is part of everyone’s daily life. Devices like mobile phones, computers, servers and fridge magnets - ah, ok, not yet perhaps, but seriously - nearly everything connected to the WWW. No nuclear submarines or the TARDIS, it’s happening in your pocket through the air you breath.

So what is Zero-day? It is when a flaw in software is discovered by someone, somewhere, before the developers of the software. The zeroeth day of awareness of a vulnerability. There are many grey areas to consider. Let me provide a recent example:- Java is used by billions of devices. It is a cross-platform runtime environment. One development language that works on many different kinds of hardware and operating systems. Java is owned, maintained and supported by the giant, Oracle.

On the 26th of August, a US based security company reported that an unpatched Java vulnerability was being exploited, using the latest version of Java. This was confirmed by other security analysis organisations, including DeepResearch.org and reported globally by the Register. Metasploit, an IT security project, also confirmed. A bug was logged in the National Vulnerability Database as CVE-2012-4681. CVE-2012-4681 allowed an attacker to use a dedicated webpage for users to download and run a payload which could contain a keylogger or network scanner, for example. Oracle finally responded, four days later, on the 30th August. Two other vulnerabilities were discovered; these forced Oracle to make patches available outside of their usual release schedule.

How are users and SysAdmins supposed to respond? Shout, “Disable Java” is a reasonable response. But then that is a big call. Most people took the risk and left Java enabled. Most out of ignorance of the issue. Ignorance is bliss! What is the incentive behind reporting the issue on the public WWW? - leaving the found hole, wide-open. Usually publishing the technical details ready for criminals to exploit. Instead of quietly knocking on Oracle’s door with the problem - then walking away. 

Why is there no agreed standard protocol in place so that discovered vulnerabilities like this are reported in silence? I once dreamed up an acronym; VDAP, Voluntary (or Vulnerability) Discovery Announce Protocol - after a rather nasty experience with a flaw discovered in the Linux kernel during 2009. VDAP may be a secure system that could be deployed and used by all major software developers to communicate, with encryption, vulnerabilities and their details. This relies on the principle of security through obscurity, Microsoft have perfected this principle anyway. It also relies on deep discretion. The kernel flaw was discovered by a Google software scientist, then posted on his personal blog.

The incentive to report newly found vulnerabilities and cause 0-day is many things; including glory, kudos, and sales. Sales of unofficial patches, services or scanning software - amongst others. One the other hand, the pressure on large vendors to provide a patch is automatically increased. Open source vendors and communities are often faster to respond with a patch. An agreed protocol might not work because people will choose, not to use it. The best solution, may not become clear for many years and this chicken and egg scenario will continue. As a Linux SysAdmin and Engineer, I have tools at hand; kernel level security, host based, firewall rules, MAC (mandatory access control) and application level security. Of these, the Firewall with proxy filtering, is the most powerful; the best security is a well balanced combination.

If you're 'sharing' a document, you could be doing it wrong!

A beginner’s guide to basic document management within a business using Google Drive, formerly known as Google Docs.

Sharing by group

It’s obvious really, but consider this example; you have a sales team and there’s some collected information about the sales process you’ve written.  So you share it with salesperson A, B, C, and D - individually.  Seems simple and easy.  However, what happens when one of those people moves department or is replaced?  Are you really going to go through all your documents that you manually shared with salesperson C who has now been replaced with salesperson E, and update the sharing?  I thought not.

What you need to do is share the document with a group and ensure that your normal sysadmin processes include adding new users to the appropriate groups.  That way, whenever anyone joins or leaves the group they will automatically have access to all the documents they should have had - with no effort whatsoever.

However if this is all you’re doing then you’re still doing it wrong, better, but wrong.

Sharing by collection

Sharing by collection is what you want to be doing.  This makes everything much easier, reliable and less error prone.  Basically what you do is set something up akin to how you might manage files in a file server.  Create a single, or few, root collections - perhaps one per department.  Within the collection create sub-collections as appropriate for project or other needs.  Set the sharing permissions, using groups.  You only need to do this once at the start of using Google Drive.  Then any time anyone needs to collaborate on a document, all they need to do is browse to the collection where it needs to sit and click create.  Simple.

No-one needs to actively share again, and all the mess that that entails.  Now you know why, if you’re sharing a document, you’re doing it wrong!

Putting a table of contents on it all using Sites

As well as keeping the documents in some organised, or even one, collection, you are highly likely to want to make a reference to it on your intranet, aka Google Sites.  One reason is covered in a gotchya later but one of the best is that it can be like a table of contents to your collections and sub-collections.  It also can be a convenient place to put your departmental information and procedures and document storage standards.  It’s a good idea to keep all that together in one place for new and old staff.

Sites is completely separate to Google Drive.  Don’t get confused between the two.  Sites is just like a wiki.  Its permission sharing does not suck, unlike Google Drive.

Pitfalls and gotchas

Unfortunately, Google Drive permissions suck.  They offer far too much flexibility to the user that they simply don’t need such as the ability to re-share or, indeed, to share at all - that is not needed.  Ideally it would work like a file server where the sysadmin sets up all the root folders and permissions and no one can change it or need to.  Because of this, follows some things you should do to avoid problems.

The collection has been shared but can’t be found - you have to see it to see it

For some reason Google Drive will not show you collections or documents that have been shared with a group that you are a member of.  Yes it’s that dumb.  Unlike Google Sites which works as you would expect it.

There are some fairly simple steps you can repeat to ensure users can see the collections they need.  The best thing you can do is include links to the document collections on your Google Site home page.  However the user is going to want to put the collection in their My Drive so they can go straight to Google Drive rather than having to go via your Google Site.  To achieve that, set up some simple instructions like this:

To access all department B collaborative documentation, follow these instructions:

1. Click here: <A link to the contents of the collection, i.e. a link to the collection URL>
2. Now click here: <A link to a search with the full collection name in>
3. Right click on "<Full Collection Name>", click Organize.
4. Tick My Drive

Why Google makes users jump through these hoops I don’t know.

Ability to change permission

When creating a root collection or important sub-collection, then change the permission so that only owners can change permissions.  No one should need to change permissions anyway and if you don’t then chaos ensues - often just by people organising folders shared with them.  You end up with incredibly messy permissions.

Files moved in to collections may not inherit the correct permissions

If you’ve created a file and already started sharing it around rather than simply placing it in the collection it needs to be in, then when you move the file there it will not inherit the correct permissions.  The solution is to unshare it with everyone, then move it in there.  Just a little thing but it can cause confusion.

Creating templates in a collection will not place them there

Normally, when you’re in a collection and you create a new document it will ask if you want to create it in the collection.  Very useful.  However when you choose Templates it navigates away from the collection and thus when creating the document it will end up in your My Drive.  You then need to drag it into the collection you intended it for.

Dragging a collection or document from somewhere to My Drive can unshare it

Yes really.  This can be minimised by setting the ability to change permissions and most significantly by training users to use Organize instead.

Cloudy outlook for jobs?

I recently came across a report from the London School of Economics about the impact of Cloud based applications on employment (you can read it here ). It’s no surprise that the report forsees growing numbers of jobs because of the cloud, but there is a bit of sting in the tail.

Firstly job growth is reckoned to be twice as fast in the US as in Europe and in the short term comes from the staff needed to set up and run the data centres that the cloud applications reside on. In the longer term job growth comes from formation of new companies providing software as a service. Larger businesses, the report envisages, will retrain “surplus” IT staff.

So far so good and this is the pretty much the new cloud orthodoxy. There are some nagging doubts though. For a start with a prospect of long term financial constraint can you really see the “surplus” IT staff, many of whom are already contractors, being retrained or isn’t more likely they’ll be looking for new jobs?

As far as the growth of new small businesses, those of us who have been around long enough will remember the dotcom bubble as people with great ideas saw the nominal value of their companies shoot through the roof only to turn over and fail when it came time to deliver.

Whilst the growth of cloud services seems inevitable, companies will need to be sure that they plan the migration and look at the contingencies before betting everything on the latest application. Unlike the dotcom explosion, it’s not just the jobs in the start-up that are at risk.

Grab Bag

Couple of bits of news and links unworthy of a full blog post today, so you're getting the equivalent of grubbing around in my desk drawer for something when I forget your birthday... not a novelty paperclip and a stress ball, but instead...


First up, Greek triple-jumper Voula Papachristou is in hot water this week - not a hilariously mis-timed jump, but over a racist tweet. I'm not about to repeat what she posted here, but it was enough to get her booted from the Greek Olympic Squad. At the same time it probably wouldn't have triggered any "word filters" - no "obvious" racial insults there. Moral of the story, meanings come from context as well as the words, you won't easily guess sense with a machine, but you might really alienate a huge group of people really quickly. Think before you tweet. It may also be the case that an organisation is liable for a tweet sent from a corporate device... twitter can easily be made read-only.. just a thought. (See BBC News)
  

Secondly, for the developers amongst our loyal readership  I happened across a great post on "Coding Horror" listing new programming jargon from stack overflow. I particularly enjoyed "Yoda conditions" and the concept of "Stringly typed"... take a look: http://www.codinghorror.com/blog/2012/07/new-programming-jargon.html
 

Finally, one for the travellers amongst us. Apparently, some hotel swipe-locks are right up there in the security stakes with bits of string and XOR based encryption, as a hacker rather irresponsibly demonstrated without first disclosing the problem to the company concerned. Still, you might want to stick your valuables in the hotel safe as well, until someone backdoors that too. http://www.bbc.co.uk/news/technology-18968225

Trends on Twitter can Make You Look a T#t

In a recent flurry of fairly pointless "news", Microsoft was under the spotlight for including some slightly odd constants in their open-source code. The hex values, at least one of which, #B16B00B5 could be considered on the wrong side of sexist, were at the very best a little puerile.

Developers have been spelling things in hex for as long as we've been building software.  As hexadecimal numbers can contain the numeric digits 0-9 as well as letters A-F, the propensity for silliness is so much more than with decimal. One example you won't have to travel far to stumble across is #DEADBEEF, perhaps offensive to vegetarians?  FACE:B00C formed part of the address a popular social networking site used on world IPv6 day, and Microsoft have previous form, using 000FF1CE at the end of their product codes in MS Office.

In any case, it is probably sensible not to include anything likely to cause offence in your source code, though some of the comments in the Linux kernel sources range from the hilarious to the downright vulgar with some crossover in between - indeed the "F-word" was (is? I haven't checked) used as a placeholder to search for in one bit of source. I guess the largest software companies aren't used to having their work looked at in so much detail.

This story did have a useful point to it, however. The widespread reporting caused #bigboobs to trend on twitter, and whilst a good section of the tweets were having a sly dig at Microsoft, some were, well, what you'd normally expect from a reference on the Internet to boobs.

Twitter does have a control to prevent you opening adult content - however, as it seems to rely on users self-tagging tweets, it ranges in efficacy from chocolate teapot through fishes on bicycles. I've  had a look, and reckon the only reasonable way to keep twitter clean is to filter at search-term level, indeed going after the #bigboobs hashtag from behind guardian gets you no tweets. It's not perfect, but it will remind users to be careful what they click, and provide another backstop against liability and e-safety issues.

What does your password say about you?

Last week, Yahoo became the latest in a long list of sites to have a chunk of password data stolen. Read all about the breach at Computerworld, the cause at SC magazine, and Yahoo's response at Techworld.

This is a particularly nasty example of the breed - a month or so ago, we were busy shaking our heads and tutting at LinkedIn for failing to salt their passwords - a process which makes it harder for an attacker to recover plaintext passwords from encrypted ones. Sadly, Yahoo's problems go a step further, their list was leaked in plain text. There is a special circle of hell for developers who store passwords in plaintext.

Happily for readers of this blog, having nearly half a million plaintext passwords gives us an opportunity to peer into the minds of the people who set them.

Firstly, lets look at the year. It is suggested that this database table wasn't live, and that it only referred to accounts created prior to 2010, and wasn't used for validation of any user passwords. Poor housekeeping! If we assume many people set a password containing the current year, and look at the passwords with a year in them (I looked at all 4 digit strings starting 19 or 20) we see a peak at 2008, though there's still many more 2012s than there are 2013s...  i'll let you make your own mind up, but it doesn't look great does it?

The data gives another little hump in the 1980s, which I assume is users' birth years. Seriously, don't do this. If your birth year makes up half of your password, you've given an attacker a lot to go on. There's barely a break in the 200 year span I chose, so it's clear some of those numbers are part of a longer string, perhaps (all digit passwords? yuck!), and some may be chosen more arbitrarily. If your password contains 2087, you should be ok for a while as a sensible attacker will concentrate on past years... and by 2087 I am quite sure password encryption of today will be seen as quaint.

What else can we learn about the users of this service?

6 people thought "secure" was a secure password - too literal, I'm afraid! While 4 more chose "insecure" or a variant - maybe this is a throwaway account, but it's all leverage to a hacker who will try and escalate privilege further and get to something of value - amazon, ebay, your credit card, even World of Warcraft.

Then we peer a little more deeply into what makes these folks tick - 16 felt strongly enough to include "hitler" in their passwords, and a handful of others made the sort of statements about race and sexual orientation which aren't suitable for a family blog like this one. Over 150 are just general "haters" with varying targets from "you", through names ("John" is unpopular) to life (sad isn't it!), school (predictable) and food(!).

Over 1000 chose passwords containing "god", though any religious overtones are tempered by both godzilla and the godfather. Just under 1000 picked "jesus", and these are much less polluted by the secular. Good advice: keep your faith out of passwords, it will make them easy to crack! FWIW, almost 200 passwords were based on the deities of other religions. Satan comes in bottom with 26 - obviously the bad PR of being the devil does nothing for your popularity as a password.

For a bit of local colour, we find 4 passwords almost certain to refer to Leeds United, but more like 30 which are manchester - that's what a few years in the lower leagues will do for you! Chelsea (108) are streets ahead of London rivals Arsenal (57), though not all will be related to the football club.

Sport is eclipsed by sex it seems, having over 1000 sex related passwords ranging in levels from polite admiration, through to some quite graphic suggestions.

Only about 3% of users chose a password which contained anything other than alphabetic or numeric characters. This would seem typical of a consumer service where passwords are chosen on convenience rather than security. Of course if the service you choose to use happens to store your password in the clear, much of your hard work choosing a decent password is undone.

Updated for 2013: Breaking news, password habits still diabolical. Thanks to those inadvertently generous folks at Adobe, there's a whole new bunch of purloined passwords to play with. The BBC have reported that right at the top of the top 20 sits old favourite "123456", with "photoshop" and "adobe" making guest appearances (yes, this is up there with using your sort code as your banking password!). Interestingly "azerty" pops up alongside "qwerty", showing we've got similarly bad habits regardless of keyboard layout. Reload this page next year to see that nothing ever changes!

Why Facebook is like a Fork...

At this year's Edugeek EDIT conference in Preston, I gave a presentation on why Facebook is like a dinner fork - so here's the idea, blogified.

Way back when, in the mists of time, somewhere between "dinosaurs roam the earth" and "electric light", people of various cultures invented the fork as an eating implement. Prior to this, food had been eaten with the hands, and often with a knife - which was the must-have multi-purpose tool. Perfectly acceptable,  we believe, to go out and slay a dragon in the morning, and then eat your lunch with the same bit of pointy metal.

Anyway - some chap invented the fork. Maybe the last civilised thing to come out of Sheffield? Suddenly, a whole host of new rules sprang up around the dining table. Which hand was it suitable to hold a fork in? Americans still use the right hand - some folk thought it unsuitable to hold an eating implement in your left. The fork was used to signify you'd finished eating (again, different cultures arrange their knife and fork in different patterns for this one). Soon, the fork bred - there were different forks, and associated knives, and more etiquette blossomed around which to use first. Today, if we went to a restaurant (for those who consider McDonalds a restaurant, you can quit reading here, you won't get this!) and found any of our culture's "rules" broken, we'd find it quite odd.

So, Facebook.. and other social networks like Twitter. They're like an early fork. Most people can easily grasp the idea, and see what the tool is for, and how to use it, at least in a rudimentary way. However, Social Media has yet to socialise - there's no etiquette, no canon of rules, no cultural influences to tell us how to behave.

Things happen on-line  which we wouldn't tolerate in person, there are incredibly loud and boring people, who won't STFU about their farm. There are bullies. There are gossips, and scuttlebutt is traded as fact. Why is this accepted more easily online? It isn't because of lack of oversight - this happens in front of the most important people to all of us - our peers. The reason is because there's no culture. No rules have grown. And there are no rules because rules take time, and they need to evolve fairly naturally.

What should we do about this? Well, one thing the social media sites can do for us is give a bit of power to the network. Right now, there is very little you can do to express your displeasure at someone's actions. Things you'd do in the "meat world" if someone transgressed our culture, our manners, just aren't there - the subtleties don't exist. In some ways, a "dislike" button  on Facebook might actually help the situation. Right now, the only "sanction" we can take against an offender is to unfriend or unfollow them. They may not even notice, and it's a big step - and you can't do it twice. This could do with a fix - Facebook, Twitter - over to you - empower our peers.

What we should do as a society is bring online etiquette and behaviour into our everyday lives, and into the schooling of children. Sure, things move fast enough that Facebook is likely to be irrelevant by the time today's 6 year old is a moody 16, but some of the lessons learned will hold. This means "decriminalising"social networks in Schools, and encouraging parents to engage with the technology their children have to grow up with.