Tales from the Crypto

iCan’t sync with iTunes; iCan’t sync without iTunes…

OK, so that’s a horrible stretching of a song to cover a point, but it’s kind of the way I feel right now – torn between a rock and a hard place.

Some time ago now, I let you readers know that I’d won an iPad at the Black Hat security conference, and that I’d be trying it out to let you know what I thought.

First, let’s consider my usage case, and what I am comparing it against.

The iPad is, to my mind, a potential killer device for a few things I like to do:

1. Watching movies and TV shows on the bus on my way to work
2. Reading comics and books
3. Using Twitter and Facebook to keep up with people around me
4. Skype to my parents in England
5. Surfing the web in places where my laptop is too bulky

In checking out these behaviours, I’m implicitly comparing them to not only my own Windows Phone 7, but also my wife’s Kindle Fire.

Movies and TV shows

In common with many people, I have a lengthy commute – at least 40 minutes each way of which is on a bus, so I can happily watch videos. My comparison device in this use case is my Windows Phone – an HTC HD7 (I’d link to it, but apparently it’s not being sold any more).

The iPad is bulkier, for certain, and I can hold my phone in one hand comfortably for some time. However, making up for this is the fact that the iPad is a larger display and therefore easier to see at a comfortable distance. But watching on the phone isn’t bad either.

Syncing to the iPad is accomplished through Apple’s piss-poor iTunes software (of which, more later), which seems to require that my videos be already in a suitable format for the iPad. Syncing to the HD7 requires the Zune software, which is configured by default to convert video and audio in the background without any further assistance from me.

Note that – Zune converts the videos to the right format automatically when necessary, the iTunes software simply shrugs its shoulders like a Frenchman and refuses to cope.

Because of this, I can sync to the HD7 from more sources, and more easily and automatically than to the iPad.

However, the winning step that the iPad has for me comes from a combination of its viewing size, and the fact that it can play the audio from my videos to my Bluetooth headset, something that the HD7 currently does not. I have to use a Bluetooth dongle on the HD7 to hear my videos – and that’s not right, when I already paid for a phone with Bluetooth support.

It’s worth noting, however, that because the iPad seems to pretend to be a phone, I can’t have the appropriate level of Bluetooth support, allowing incoming phone calls to pause my video and let me answer the phone.

So, a narrow win for the iPad there. But keep reading. [Add Bluetooth support for video watching, and the Windows Phone will easily surpass the iPad]

Reading comics and books

Killer app, no doubt – the size and colours make the iPad superior for reading comics. For other books, you can’t really beat a Kindle, because it’s the size and shape of a book. The iPad does seem to suffer in daylight as well, not that we get much of that around Seattle – but we clearly get enough for this to be a noticeable problem for me.

The Kindle Fire is a more subtle device than the iPad in this use as well, since it doesn’t take up as much space. The battery life, as well as the use of standard charging cables (read: I already have dozens of the things, as opposed to having to look for the one wonky, too short cable that came with the iPad) makes the convenience factor that much greater.

However, I’ve even read my comics on the Windows Phone. It’s not that bad a format, because the display is so high a resolution.

Winner: Kindle Fire. Of course, I would say that. But since the Fire has no Bluetooth audio, I can’t use it on the bus as comfortably for my videos.

Using Twitter and Facebook

The iPad is certainly convenient for this, with free Twitter and Facebook apps, as well as a web browser to use the online versions. The iPad’s desire to keep pushing text further and further to the right of the screen, in ever-decreasing strips of window, make it incredibly difficult to read some items.

In comparison, while the Windows Phone does have a free Twitter and Facebook app, and access to the web, it doesn’t actually need any of these, because there are the “Me” and “People” tiles, through which you can read notices from all your social media sources (Twitter, Facebook, Linked-In, MSN Messenger in my case). This gives a more natural, integrated feel to the communication, and it feels more like I’m sharing with my friends than I’m using this or that app.

Winner: Windows Phone, hands down. [But it would be nice to have Bluetooth keyboard support]

Skype to the UK

OK, the iPad wins hands-down on this one. There’s a Skype app in beta for the Windows Phone, but my HD7 has only a rear-facing camera, and the Fire of course doesn’t have one.

Winner: iPad (but only because I have a 1st-gen Windows Phone)

Surfing the web

The iPad has no Flash support – but then nor does the Windows Phone.

The iPad uses a webkit-based browser, which comes with a fresh batch of security flaws once a month (as does iTunes). The Windows Phone comes with Internet Explorer – but without the same set of flaws that get patched in your regular Windows update. I strongly believe that the Windows Phone gives me the most secure browsing of any device that I have. But it is a little hard to read.

Winner: iPad

Sounds like we have a clear winner, then?

Yabbut no.

I got the iPad for free, so I have to bear in mind that for most people, they pay $500 to have it. It’s not that much better than the Windows Phone. I got the Windows Phone for practically free – one cent on Amazon Wireless, with a two year commitment. But then I was going to get a phone anyway, and the two year commitment is common for phones.

Irritations

As with every Apple product I have ever used, it seems like they skimped a little on the “fit and finish” of the software. This leads to small – but constant – irritations. There have been many times I’ve been tempted to throw it to the floor and stomp on it. So far, the iPad has survived largely because I know that if I want to get rid of it, there are numerous people who would happily take it from me. And then I settle down.

So, what are my irritations?

1. User interface
2. iTunes
3. iTunes
4. iTunes

User interface

There are some areas where it’s clear that the Apple design philosophy hasn’t been communicated well – even to writers of the native apps.

Delete an item

A clear example – how do you delete an item? In iBooks, you swipe to the right, which causes a delete button to appear. You press this button, and the item goes away. In Videos, you hold your finger on an item until a little “x” appears. You press the “x”, and are asked if you really want to delete the video. I guess videos are more important than books, that you have to be prompted.

I should say that this is how videos are supposed to be deleted. What actually happens is that you hold your finger on a video for a while. The “x” fails to appear, because you wiggled your finger a little (really common on a bus). So you let your finger up, and the video opens up. So you close it down again, and hold your finger on the video again. Now the “x” appears – albeit sometimes in a different place than you expect. So you press it. Damn, missed, because the bus must have hit a bump, so the “x” goes away. Bring it back! Bring it back! Okay, here it is again, so I can press it finally. And then I get asked if I’m sure. Am I sure? Am I sure? I’ve only spent the last ten minutes trying to get the damn “x” up on screen and hit it – of course I’m sure! And I remind myself not to throw the iPad to the floor and stomp on it.

Yes, I know about the “Edit” button, and that shortcuts one part of the process, but makes it more likely that you’ll accidentally delete the wrong video, because it puts an “x” above each one.

[A short note – the “x” appears in one of two places – either immediately on the top left corner, or a good half-inch above that. I can see no logic in why it does this.]

Detail view

In the Videos app, there are three kinds of video. “Movies”, “TV Shows”, and “iTunes U”. The “TV Shows” and “iTunes U” items all come from iTunes, so all the videos I put on my system end up in “Movies”, no matter what metadata I put on the file. Whereas I never metadata I didn’t like, iTunes clearly never metadata. For the iTunes U and TV Shows tabs, each item is listed with details – length, a title, and a description. This is great, although it would also be nice to see which ones I’m part-way through watching.

For the Movies tabs, however, there’s only two things showing – a thumbnail, which is the first frame of the movie (oh, and so often, that means it is plain black), and the curtailed title of the video. So, “Have I Got News for You: Series 42, Episode 5” is displayed as “Have I Got News for You:…” – as is every episode of every series of that show. Same thing for “The Sarah Jane Adventures…”, or “Who Do You Think You Are…” Yeah, the BBC could choose shorter titles, but the iPad could pay attention to the Subtitle field in the metadata for the episode information. Oh, yeah, that’s right, metadata is to be ignored.

And there’s no details on the video – no duration, no description, no indication of whether or not I’ve been watching this video file at all. I’d like to say “hey, this component of my bus ride is going to take another twenty-five minutes, so I’d like to watch something that length or shorter”.

Notifications – or scrubbing

When watching a video, you can ‘scrub’ through it by dragging a little slider at the top of the screen. Except when the slider is near the middle of the top of the screen, because then you’re going to actually be pulling down the notifications window. If anyone writing this software actually used an iPad, they’d be experiencing this frustration, and it would have been fixed by now.

Back, back, back – no, store!

To go backward in the user interface of an app, you click the button in the top left. Except that sometimes, the button in the top left takes you somewhere else, like the iTunes store.

Delete doesn’t actually free up space

You can delete videos all you like, bus joggling allowing, and when you’re done, your storage usage hasn’t gone down at all. There is no room for more videos. This one confused me for some time, until I remembered that you never actually close apps when you switch between them. The storage is released, not when you delete the movie, but when you close the app.

That would make sense, if you could actually undelete the movie while the videos app runs, but no. That doesn’t happen.

And on and on…

I could carry on, but I just get angrier and angrier. The difference between editing the list of apps you can run, versus editing the list of apps currently running, for instance. One is dismissed by a tap, the other requires that you hit the home button, and I can’t remember which one.

iTunes

So, the first complaint I have about iTunes is the one I have made from the beginning – it includes way too much, and it screws up my system way too badly. What do you get when you install iTunes?

Well, first you get a file called “iTunes64Setup.exe”. This installs iTunes into “C:\Program Files (x86)” – uh, yeah, that means the “64 bit” version of iTunes is actually all 32-bit. Then it tells you:

The wha?

What does iTunes have to do with Outlook? That’s crazy.

And then, what does it install? Only another four applications.

iTunes

When syncing videos to the iPad with the Windows version of iTunes, they are synced with at least one default setting not correctly set.

That’d be fine if it was an unimportant setting, but no. The setting is “resume from where I left off”. That means that every time I switch videos, or close the video application (see previous discussion of why I need to do this to recover storage), the video I want to watch starts again from scratch.

There is a simple fix to this – for every video I upload to the iPad, I have to go into iTunes, select the video, right-click it, select “Get Info”, open the “Options” tab, uncheck the box that says “Remember Playback Position” (or if I selected multiple videos, set to “No” the drop-down arrow labeled “Remember Position”), hit “OK” (there is no “Apply”), wait for this action to sync to the iPad, then right-click the video(s) again, select “Get Info”, open the “Options” tab, and then recheck the box (or set the drop-down box to “Yes”), hit “OK” and sync once again.

iTunes

For weeks I’ve been complaining that every USB device on my system has been unreliable – I have to plug and unplug simple USB flash drives a half dozen times before they finally get recognised in Explorer.

Then it finally dawned on me.

One device has been steadfastly reliable, always becoming active and ready to use within seconds of plugging it in. Yes, it’s the iPad.

Acting on this hunch, I removed iTunes, Apple Mobile Device Support, Apple Application Support, Apple Software Update, Bonjour, and even QuickTime (not sure how that got on there). Suddenly all my USB devices connect first time, every time. With the exception of the iPad, of course, which sulks if it doesn’t have iTunes (though the same charge can be leveled against my Windows Phone requiring Zune – although that hasn’t yet caused all my other USB devices to become unavailable).

Adding iTunes back in to the mix, strangely, has yet to reproduce the same unreliable behaviour. I strongly distrust software acting randomly.

If I could just drag my videos into a folder using Explorer without installing iTunes (since iTunes doesn’t actually properly do any of the other things that an intermediate program should do, such as converting video formats, extracting and using metadata, or setting the “resume from where you left off” option), I’d be happy without iTunes on my PC at all.

And other reasons…

There are other reasons not to like the iPad – it’s too trendy, for one; and it’s not really a $500 product. There are, as I point out above, too many areas where it’s clear that the developers have not finished the job.

I use the iPad simply because it’s free, and has a large display.

I’d far rather use a tablet that works in a more predictable and controlled manner, where the applications on the device and to sync the device have the flavour of being finished.

But I didn’t get one of those for free.

I got an iPad.

And I’m grateful.

Even if, once in a while, I want to dash it to the floor and stomp it into pieces.

Multiple CA0053 errors with Visual Studio 11 Beta

I hate it when the Internet doesn’t know the answer – and doesn’t even have the question – to a problem I’m experiencing.

Because it was released during the MVP Summit, I was able to download the Visual Studio 11 Beta and run it on a VS2010 project.

There’s no “conversion wizard”, which bodes well, because it suggests that I will be able to use this project in either environment (Visual Studio 2010 or the new VS11 beta) without any problems. And certainly, the project I selected to try worked just fine in Visual Studio 11 and when I switched back to Visual Studio 2010.

Unfortunately, one of the things that I noticed when building my project is that the code analysis phase crapped out with fourteen instances of the CA0053 error:

As you can see, this is all about being unable to load rule assemblies from the previous version of Visual Studio – and is more than likely related to me installing the x64 version of Visual Studio 11 Beta, which therefore can’t load the 32-bit (x86) DLLs from Visual Studio 2010.

Curiously this problem only exists on one of the projects in my multi-project solution, and of course I couldn’t find anywhere in the user interface to reset this path.

I thought for a moment I had hit on something when I checked the project’s options, and found the Code Analysis tab, but it didn’t seem to matter what I did to change the rule set, there was no place to select the path to that rule set.

Then I decided to go searching for the path in the source tree.

There it was, in the project’s “.csproj” file – two entries in the XML file, CodeAnalysisRuleSetDirectories and CodeAnalysisRuleDirectories. These consisted of the simple text:

<CodeAnalysisRuleSetDirectories>;C:\Program Files (x86)\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\\Rule Sets</CodeAnalysisRuleSetDirectories>

<CodeAnalysisRuleDirectories>;C:\Program Files (x86)\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\FxCop\\Rules</CodeAnalysisRuleDirectories>

As you can imagine, I wouldn’t normally suggest editing files by hand that the interface normally takes care of for you, but it’s clear that in this case, the interface wasn’t helping.

So, I just closed all currently open copies of Visual Studio (all versions), and edited the file in notepad. I kept the entries themselves, but deleted the paths:

<CodeAnalysisRuleSetDirectories></CodeAnalysisRuleSetDirectories>

<CodeAnalysisRuleDirectories></CodeAnalysisRuleDirectories>

Errors gone; problem solved.

You’re welcome, Internet.

MVP news

My MVP award expires on March 31

So, I've submitted my information for re-awarding as an MVP - we'll see whether I've done enough this year to warrant being admitted again into the MVP ranks.

MVP Summit

Next week is the MVP Summit, where I visit Microsoft in Bellevue and Redmond for a week of brainwashing and meet-n-greet. I joke about this being a bit of a junket, but in reality, I get more information out of this than from most of the other conferences I've attended - perhaps mostly because the content is so tightly targeted.

That's not always the case, of course - sometimes you're scheduled to hear a talk that you've already heard three different times this year, but for those occasions, my advice would be to find another one that's going on at the same time that you do want to hear. Talk to other MVPs not in your speciality, and find out what they're attending. If you feel like you really want to get approval, ask your MVP lead if it's OK to switch to the other session.

Very rarely a talk will be so strictly NDA-related that you will be blocked from entering, but not often.

Oh, and trade swag with other MVPs. Very frequently your fellow MVPs will be willing to trade swag that they got for their speciality for yours - or across regions. Make friends and talk to people - and don't assume that the 'industry luminaries' aren't willing to talk to you.

Featured TechNet Wiki article

Also this week, comes news that I've been recognised for authoring the TechNet Wiki article of the Week, for my post on Microsoft's excellent Elevation of Privilege Threat Modeling card game. Since that post was made two years ago, I've used the deck in a number of environments and with a few different game styles, but the goal each time has remained the same, and been successfully met - to make developers think about the threats that their application designs are subject to, without having to have those developers be security experts or have any significant experience of security issues.

In June: Happy Birthday to me–World IPv6 Launch Day

I’d like to thank ISOC (the Internet Society) for making my birthday later this year into World IPv6 Launch Day.

This year is a special one for anniversaries – my 45th birthday, 20 years since I arrived in the USA, 10 years since beating cancer – seems like the perfect time for ISOC to honour me by switching everyone to IPv6.

Now, if only I could persuade Comcast to deliver IPv6 to my house, where we are still using Hurricane Electric’s Tunnel Broker.

Changing passwords on a service, part 3

It’s been quite some time since I wrote about changing passwords on a Windows service, and then provided a simple tool written in Visual Basic to propagate a password among several systems sharing the same account.

I hinted at the time that this was a relatively naïve approach, and that the requirement to bring all the services down at the same time is perhaps not what you want to do.

So now it’s finally time for me to provide a couple of notes about how this operation could be done better.

1. If you can’t afford an outage, don’t have a single point of failure

One complaint I have heard at numerous organisations is this one, or words to this effect:

“We can’t afford to cycle the service on a password rotation once every quarter, because the service has to be up twenty-four hours a day, every day.”

That’s the sort of thing that makes novice service owners feel really important, because their service is, of course, the most valuable thing in their world, and sure enough, they may lose a little in the way of business while the service is down.

So how do you update the service when the software or OS needs patching? How do you fix bugs in your service? What happens when you have to take it down because the password has escaped your grasp? [See my previous post on rotating passwords as a kind of “Business Continuity Drill”, so that you know you can rotate the password in an emergency]

All of these activities require stopping and cycling the service.

Modern computer engineering practices have taken this into consideration, and the simplest solution is to have a ‘failover’ service – when the primary instance of the service is taken offline, the secondary instance starts up and takes over providing service. Then when the primary comes back online, the secondary can go back into slumber.

This is often extended to the idea of having a ‘pool’ of services, all running all the time, and only taking out one instance at a time as you need to make changes, bringing the instance back into operation when the change is complete.

Woah – heady stuff, Mr Jones!

Sure, but in the world of enterprise computing, this is basic scaling, and if your systems of applications can’t be managed this way, you will have problems as you reach large scale.

So, a single instance of a service that you can’t afford to go offline – is a failure from the start, and an indication that you didn’t think the design through.

2. Old passwords and new passwords are both valid – for a while

OK, so that sounds like heresy – if you’ve changed the password on an account, it shouldn’t be possible for the old password to work any more, should it?

Well, yes and no.

Again, in an enterprise world, you have to consider scale.

Changing the password on an account isn’t an instantaneous operation. That password change has to be distributed among the authentication servers you use (in the Windows world, this means domain controllers replicating new password information).

To account for this, and the prospect that you may have a process running that didn’t yet have a chance to pick up the new password, most authentication schemes allow tokens and/or passwords to be valid for some period after a password change.

By default, NTLM tokens are valid for an hour, and Kerberos tickets are valid for ten hours.

This means that if you have a pool or fleet of services whose passwords need to change, you can generally take the simple process of iteratively stopping them, propagating the new password to them, and then re-starting them, without the prospect of killing the overall service that you’re providing (sure, you’ll kill any connections that are specifically tied to that one service instance, but there are other ways to handle that).

3. Even if you don’t trust that, there’s help – use two accounts

Interesting, but I can’t afford the risk that I change the password just before my token / ticket is going to expire.

Very precious of you, I’m sure.

OK, you might have a valid concern that the service startup might not be as robust as you hoped, and that you want to ensure you test the new startup of the service before allowing it to proceed and provide live service.

That’s very ‘enterprise scale’, too. There’s nothing worse than taking down a dozen servers only to find that they won’t start up again, because the startup code requires that they talk to a remote service which is currently down.

You wouldn’t believe how many systems I’ve seen where the running service is working fine, but no more can be started up because startup conditions for the service cannot  be replicated any longer.

So, to allow for the prospect that you may fail on restarting your services, here’s what I want you to do:

1. Start with a large(-ish) pool of services. [See “no single point of failure” above]
2. All of your services are running as one user account. Create another user account, with the same rights and privileges. Make sure that access rights are provided to the group that these accounts are a member of, rather than to individual accounts.
3. Wind down one of the services, and shut it down.
4. Change the downed service to use the second account you just created.
5. Start up the downed service.
6. Monitor this newly started service to make sure it starts up successfully and is providing correct service. (Yes, this means that you have the ability to roll-back if something goes wrong)
7. Repeat steps 3 – 6 with each of the other services in the pool in turn, until all are using the second account.
8. De-activate / disable logon to the old user account. Do not delete it.

As you can probably imagine, when you next do this process, you don’t need to create the second user account for the server, because the first account is already there, but disabled. You can use this as the account to switch to.

This way, with the two accounts, every time a password change is required, you can just follow the steps above, and not worry.

You should be able to merge this process into your standard patching process, because the two follow similar routines – bring a service down, make a change, bring it up, check it for continued function, go to the next service, continue until all services are done.

No excuses

So, with those techniques under your belt – and the necessary design and deployment practices to put them into place – you should be able to handle all requests to rotate passwords, as well as to handle patching of your service while it is live.

Sorry that this doesn’t come with a script to execute this behaviour, but there are some things I’m hoping you’ll be able to do for yourselves here, and the bulk of the process is specific to your environment – since it’s mostly about testing to ensure that the service is correctly functioning.

What else I did at Black Hat / DefCon–the Core DataMatrix Contest

Black Hat, and its associated sideshow, DefCon, consists of a number of different components. Training, Briefings, Exhibition and Contests, all make up part of Black Hat, and DefCon is a looser collection of Workshops, Events, Parties, Talks, Villages, Contests and numerous other things besides(*).

Perhaps the thing that gave me the most fun this year was the contest that I entered at Black Hat and at DefCon. The contest was run by Core Labs, a part of Core Security Technologies, and featured the theme of reverse engineering.

Reverse Engineering is the skill of looking at someone else’s code – in source code or binary form – and figuring out what the code does, and more importantly, how best to make it do what you want. This often involves exceeding the original design specifications – which is perhaps the simplest and most inclusive definition of “hacking”.

In the DataMatrix contest, the code (or at least, a portion of it) is given to you in source form, in C#. You are told that this code is running as part of a server, and you are given access to the server in the form of two webcams and an output screen. The output screen displays a score sheet, the views from each webcam, and a ‘debug’ output window. I’ve lost the link to the Black Hat version of the code, but here’s the DefCon code.

The webcams are the only form of input to the server that are available to the contestants. Each contestant is given a DataMatrix containing their activation code. This is a bitmap (kind of like a two-dimensional barcode) with some “registration” values around the edge, and squares either black or white in the middle.

And that’s it – that’s all the help you get.

But then, that’s probably all the help you’ll need.

The first challenges

The first challenges are relatively easy. First, you activate your userid by showing the webcam your initial card, and then you see there’s a function called “process_activate” – that sounds like it’s the function that was used to activate your card.

It’s fairly simple to see that this must use the single byte command (in the “cmd” variable) “1”, along with your two byte userid and four byte password, to register you in the system as an active user. It also increases a user-specific value, “score”. To make this easy to understand, we’ll call this “scoring a point”.

Then you see a function “process_free” – from the code, this is clearly a free point. All you need is a command “10”, and your userid, to score a point.

Another function, “process_pieceofcake”, is almost as easy. Command 11, and your userid, plus another four bytes which are simply the two’s-complement of your userid. Easy. In fact, in the Black Hat version, this was even easier, if I remember correctly, but I don’t have the code handy.

“process_name” is clearly one to call early on, because it gets you the bragging rights of putting your own name in the high score table. Plus, it gives you five points more. Pretty good, huh? By now you should have eight points.

Some more interesting challenges

“process_regalo” took my interest next, since it talks about a “gift_list”. Regalo is, apparently, Spanish for “gift”. This one’s strange, because the process has some activity even when the command code isn’t the code expected.

So, I took a look at what that path does. Checks four bytes for the user’s password, and if the “data_regalos” value for this user is less than 10, increments it, and then assigns an extra point to a randomly selected member of the gift list.

Having figured that out, I realised that the quicker I get on the gift list, the quicker I start racking up the points. So, I solved the little coding conundrum (did you figure that one out yourself?) in the other path of process_regalo, and added myself to the gift list.

Five times.

Yeah, five times – did you spot that in the code?

“process_fabe” and “process_fabe13” – those were a little harder. You have to not only crack an MD5 hash (not difficult, but hard), but in the “fabe13” case, figure out what the appropriate “encode” is for the “decode” function. [ROT13, if you didn’t get it]

“process_enqueue” – nasty, this one sends a message to an email address at mailinator.com that you have to figure out for yourself. I still haven’t figured it out. So, I also haven’t got the points from “process_claimMessage”.

“process_sync” was one function where I knew I had an advantage. It requires the use of a .NET Random function, and because I spend a fair amount of my development time in .NET, I knew that I could use my own system to figure out what times the sync function was expecting me at. Occasionally, the webcams weren’t reading my cards quickly enough, but that’s OK. I didn’t necessarily need a whole lot of those points.

Ladies and Gentlemen, we have a winner!

So, as you’ve probably guessed by now, using these functions I managed to rack up quite a number of points, and as it happened, I conquered the Black Hat competition. 60 points to me, 27 to my nearest opponent.

As a result of this, I am now the proud owner of an iPad. Yes, I know, all those things I’ve always said about Apple, and here I am, walking away from a competition with an iPad 2. The irony is almost unbearable. I’ll tell you later what I think of the iPad.

Then comes DefCon

DefCon started out much the same – I was streaking ahead of the competition, largely because the contest was better attended, and I’d already got my foot into the gift_list early on.

Then I saw the part of the server code that was new – it allowed you to write a limited form of program to execute on the server, that would randomly add points to your score. I entered that, and sure enough, I got a pile of points very quickly – about twice as many as I had at Black Hat.

I thought that meant I was going to win the prize.

Sadly, I hadn’t taken into consideration that this was DefCon. The people there are sometimes more devious (though there are also an awful lot of wannabes).

Sure enough, two of my competitors executed the portion of code that allowed them to dump out the list of executing code, as well as to remove the code sample I had submitted. That way, they could copy my code in order to give themselves points, and remove my ability to add points.

In a way, I almost felt like this was kind of cheating – what, they couldn’t write their own code? But, realistically, this was simply a part of the challenge – if I had been as good at reverse engineering as I felt I was, and a little less cocky, I would have spotted this functionality and taken advantage of the means with which to prevent it.

As it was, I came in third, and won a t-shirt. But the joy of winning the Black Hat contest is still something I’m proud of, and grateful to Core for letting me play their games.

NCSAM 2011–Post 21–Failure is always an option

For my last post in the National Cyber Security Awareness Month, I’d like to expound on an important maxim for security.

Failure is always an option – and sometimes the best

If you can’t handle a customer’s credit card in a secure fashion, you shouldn’t be handling the customer’s credit card.

If a process is too slow when you add the necessary security, the process was always too slow, and can not yet be done effectively by modern computers (or the computers you’re using).

If you enable a new convenience feature, and the rate of security failures increases as a result, the convenience is more to the hackers than to the users, and the feature should be removed or revisited.

Accept your own failures and deal with them

Sometimes there’s nothing to do but to say “Oops, that didn’t work”. Find something else that does.

If you’re writing software code, expect to encounter failing conditions – disk full, network unresponsive, keyboard stuck, database corrupt, power outage – all these are far more common than software developers anticipate.

Failure is not the exception, it is a part of life in an uncertain universe.

Handle other people’s failures gracefully

Other people will fail you.

This is not always their intent, nor is it necessarily something that they will recognise. Do not punish unintentional failure as if it was an intentional insult. Educate, where possible, redirect otherwise.

Where failure is intentional, be firm and decisive. Do not allow deliberate failure to continue unhindered.

Failure is always a necessary part of innovation

Innovation is doing that which has never been done before.

As a result, no one knows how to do it correctly. You will fail, a lot. If you are always right, it is because you are doing something that you already know.

Because failure is ubiquitous, look for it everywhere

Part of being a security expert is the ability to see where people, process and technology are likely to fail, and how someone might take advantage of that, or cause you disadvantage.

Turn “I can’t imagine how that might fail” into “I can see seven different ways this could screw up, and I’ve got plans for eight of them”.

And yes, I failed to finish writing this in National Cyber Security Awareness Month.

NCSAM/2011–Post 20–Is SSL broken?

It seems like a strange question for me to ask, given that in a number of my National Cyber Security Awareness Month posts to date, I have been advising you to use SSL or TLS to protect your communications. [Remember: TLS is the new name for SSL, but most people refer to it still as SSL, so I will do the same below]

But it’s a question I get asked on a fairly regular basis, largely as a result of news articles noting that there has been some new attack or other on SSL that breaks it in some way.

To be fair, I’m not sure that I would expect a journalist – even a technology journalist – to understand SSL in such a way that they could give a good idea as to how broken it may or may not be after each successful attack. That means that the only information they’re able to rely on is the statement given to them by the flaw’s discoverers. And who’s going to go to the press and say “we’ve found a slight theoretical flaw in SSL, probably not much, but thought you ought to know”?

The good news

First, the good news.

SSL is a protocol framework around cryptographic operations. That means that, rather than describing a particular set of cryptography that can’t be extended, it describes how to describe cryptography to be used, so that it can be extended when new algorithms come along.

So, when a new algorithm arrives, or a new way of using an existing algorithm (how can you tell the difference?), SSL can be updated to describe that.

So, in a sense, SSL will never be broken for long, and can always be extended to fix issues as they are detected.

Now for the bad news

Of course, SSL is really only a specification, and it has to be implemented before it can actually be used. That means that when SSL is updated to fix flaws, theoretical or practical, every implementation has to be changed to catch up to the new version.

And implementers don’t like to change their code once they have it working.

So when a new theoretical flaw comes along, the SSL designers update the way SSL works, increasing the version number when they have to.

The implementers, on the other hand, tend to wait until there is a practical flaw before updating to support the new version.

This means that whenever a practical break is found, you can bet it will be at least several weeks before you can see it fixed in the versions you actually use.

In moderation

The presence of SSL assumes that your communications may be monitored, intercepted and altered. As such, don’t ever rely on a statement to the effect that “this breach of SSL is difficult to exploit, because you would have to get between the victim and his chosen site”. If that wasn’t possible, we wouldn’t need SSL in the first place.

Having said that, on a wired network, you are less likely to see interception of the type that SSL is designed to prevent. As such, even a broken SSL on wired networks is probably secure for the time it takes everyone to catch up to fixing their flaws.

On a wireless network, any flaws in SSL are significant – but as I’ve noted before, if you connect immediately to a trusted VPN, your wireless surfing is significantly safer, pretty much to the same level as you have on your home wired network.

The bottom line

In summary then:

SSL is frequently, and in some senses never, broken. There are frequently attacks, both theoretical and physical, on the SSL framework. Theoretical attacks are fixed in the specifications, often before they become practical. Practical attacks are fixed in implementations, generally by adopting the tack that had been suggested in the specifications while the attack was still theoretical. At each stage, the protocol that prevents the attack is still SSL (or these days, strictly, TLS), but it requires you keep your computers up to date with patches as they come out, and enable new versions of SSL as they are made available.

If you’re on a wired network, the chances of your being attacked are pretty slim. If you’re on a wireless network, your chances of being attacked are high, so make sure you are using SSL or an equivalent protocol, and for extra protection, use a VPN to connect a trusted wired network.

NCSAM/2011–Post 19–Is it safe to give out my keys?

There are some people who seem to get this right away, and others to whom I seem to have been explaining this concept for years. [And you know who you are, if you’re reading this!]

Whenever you talk about keys used for encryption, you have to figure out how you’re going to keep those keys, and whether or not you need to protect them.

And the answer depends (doesn’t everything?) – and depends on what kind of encryption algorithm you are using.

Let’s start with the easy kind, the one we’re all familiar with.

Symmetric (aka shared-key) cryptography

This is the sort of code that I’m sure we all played with as children. The oh-so-secret code (well, we didn’t know about frequency counting or cryptanalysis back then), where you and your best friend knew the secret code and the secret key. [Probably a Caesar cipher, although I used a Vigenere cipher, myself]

Well, those codes, like us, have grown up. The category of shared-key cryptography, also known as symmetric cryptography, so that the same keys (and sometimes the same operations) are used to encrypt and decrypt the data, has been enhanced hugely since those old and simple ciphers.

Now we have AES to contend with, and for all practical purposes, with reasonable keys, it’s unbreakable in usable time. [But if you have a spare universe to exhaust, perhaps you can crack my files]

For symmetric key cryptography, you do have to give out your key – to the party with whom you plan to exchange data. Of course, you have to protect this key as if it was as important as the data it protects, because it is all that protects your data. [Your attacker can tell what algorithm you use, and if you develop your own algorithm, well, they can tell what that is, too, because crypto algorithm inventors are generally doomed to fail to recognise the flaws in their own algorithm.]

That’s kind of a catch-22 situation – there’s really no way using cryptography to protect a key-sized piece of data outside of encrypting it with another key.

Asymmetric (aka public key) cryptography

That’s why the British had to invent public key cryptography.

Of course, unlike the Americans, the British managed to keep this a secret – so much so that to this day, many Americans believe their country invented public key cryptography (along with apple pie, mothers and speaking English loudly to foreigners).

With public key cryptography, there are two keys for every cryptographic operation – the public key, and the private key.

Here’s the tricky part

OK, I don’t think this part is very tricky, but there are several people I’ve had to explain this to over and over again, so I’ll try to take it really slowly.

Of the two keys, there is one key that you are supposed to share with anyone and everyone. To some of you it may come as a surprise that this is the PUBLIC key.

Again, the PUBLIC key is something you can share with anyone and everyone with no known danger to date. You can print it on billboards, put it on your business cards, include it in your email, really you can do anything with it that distributes it to anyone who might want it.

In a pinch, you might want to make sure that you distribute the public key in a way that allows the recipients to associate it with their opinion of your identity.

But the PRIVATE key – no, no, no, no, no, you do not ever distribute that. You don’t even let someone else create it for you. You generate your private key for yourself, and you don’t ever tell it to anyone.

The simple reason is that anyone who has your private key can pretend to be you – in fact, for cryptographic purposes, they are you.

So, really simply now:

• You generate your own keys. Nobody else ever does this for you (otherwise they aren’t your keys)
• The public key can be given to anyone, but has to be associated with your identity in the recipient’s mind.
• The private key cannot be given to anyone. It must be held by you, and you alone.

If you think this is confusing, apparently you are right – even Microsoft’s official curriculum for the Windows Server 2003 training courses says that “Alice encrypts the message using Bob’s private key” – if Alice has Bob’s private key, she can exchange any secret message with Bob while they are in bed together that night.

Actually, scratch that – even my wife doesn’t have access to my private key, and I don’t have access to hers.

What do you do with these two keys?

There are two operations that you can do with your private key. You can decrypt data, and you can sign data.

Reversing this, there are two operations that you can do with a public key – that would be someone else’s public key, not yours. You can encrypt data, and you can verify a signature.

Hybrid cryptography

In many cryptographic exchanges, such as SSL / TLS, and other modern equivalents, asymmetric cryptography is used briefly at the start of each session, so that two parties can identify each other and exchange (or, more commonly, derive) a shared key. This shared key is then used to encrypt the subsequent communications for some time using symmetric key cryptography.

A quick summary

For shared-key (aka symmetric) cryptography, you do have to share your keys – but you share them secretly with only the person to whom you are communicating. If you are trying to protect a communication between you and a partner, you cannot send the keys down the same line that you are going to send the communication down, because an attacker who can steal your communication can also steal your keys.

For asymmetric cryptography, you also have to share your keys – but only your public keys. Again, that’s only your public keys that you share. And you have to share those public keys. Your private keys are used by the various applications that encrypt data on your behalf, or to sign data to prove it came from you. Anything outside of that realm that asks you for your private keys is not to be trusted.

Any questions?

Ask an expert if you still have concerns. Because if you give out your private keys, then you have to generate new ones, and distribute new public keys.

NCSAM/2011–Post 18–Know what security you want from your network

In yesterday’s post, we talked about how SSL and HTTPS don’t provide perfect security for your web surfing needs. You need to make sure that a site is also protecting its applications and credentials.

This can be generalised

One of my favourite interview questions for security engineer candidates is to ask what an application developer could use to protect a networked application if SSL wasn’t available.

It’s an open ended question – what parts of SSL is the interviewee looking to match, and what parts are they willing to throw away with an alternative (and do they even know what they are throwing away?); and it asks the interviewee to think about how else they can achieve those goals.

I like to hear answers that cover a number of options. I won’t provide a perfect answer here, because I’m sure I’ll miss something, but here are some of the considerations I would give:

Can we use network layer security?

There are a number of different ways to secure network communications, providing for encryption, integrity and authentication – IPsec and VPN are just two methods that should spring immediately to mind. These are not universally suitable, as they tend to be all-or-nothing solutions, rather than per-application, but if you expect to see only one application running on the communicating pair of systems (this is relatively common in business communications), this can be acceptable. These are also a considerable effort to set up, and don’t always scale to inter-networked situations.

What about application layer security?

Hey, what’s wrong with encrypting and signing a file with PGP or S/MIME, or even WinZip, and sending it through email?

Not a whole lot, surely. We can get into discussions of key distribution and so on, but essentially, this is a solid technique. Maybe not easy to automate, and probably not accepted by everyone the world over, but from a “protected by encryption” standpoint, this is actually fairly defensible.

So what’s my point?

What I’m really trying to say here is that your application’s security rests on an understanding of what protections you can ask from your network – and from your network staff, and which you will have to implement in the application itself. For every protection that is available in the network, that’s maybe some less work you have to do in your application; and for every protection the network does not provide, that’s one more thing you have to write into the app itself.

Without knowing what security your network provides between you and all your communicating partners, you can’t truly know or guess what security you need to provide in your application. Without knowing what security your application provides, you can’t describe what network environment is appropriate to host that application.

We split the world into infrastructure and application so frequently, that it’s important to remember that we each have to understand a little of the other’s world in order to safely operate.

NCSAM/2011–Post 17–SSL does not make your web site secure

I know, it sounds like complete heresy, but there it is – SSL and HTTPS will not make your web site secure.

Even more appropriate (although I queued the title of this topic up almost a month ago) is this recent piece of news: Top FBI Cyber Cop Recommends New Secure Internet, which appears to make much the opposite point, that all our problems could be fixed if we were only to switch to an Internet in which everyone is identified (something tells me the FBI is not necessarily looking for us to use strong encryption).

HTTPS is just one facet of your web site security

There are a number of ways in which an HTTPS-only website, or HTTPS-only portion of a site, can be insecure. Here’s a list of just some of them:

Application vulnerabilities

It’s been a long time since web servers provided only static content in their pages. Now it’s the case that pretty much every web site has to serve “applications”, in which inputs provided by the visitor to the site get processed and involved in outputs.

There are any number of ways in which those inputs can produce bad outputs – Cross Site Scripting (XSS), on which I’ve posted before; Cross Site Request Forgery, allowing an attacker to force you to take actions you didn’t intend; SQL injection, where data behind a web site can be extracted and/or modified – these are just the most commonly known.

Applications can also fail to check credentials, fail to apply access controls, and even fail in some old-fashioned ways like buffer overflows leading to remote code execution.

Path vulnerabilities

Providing sensitive information in an application’s path, or through parameters passed in a URL, is another common means by which application authors, who think they are protected by using HTTPS, come a significant cropper. URLs – even HTTPS protected URLs – are often read, logged, and processed at both ends of the connection, and sometimes even in the middle!

Egress filtering in enterprises is often carried out by interrupting the HTTPS communication between client and server, using a locally-deployed trusted root certificate. This quite legitimately allows the egress filtering system to process URLs to determine what’s a safe request, and what’s a dangerous one. This can also cause information sent in a URL to be exposed. This is one reason why an application developer should avoid using GET requests to perform and data exchange for user data, or for data that the site feels is sensitive.

Other path vulnerabilities – mostly fixed these days, but still something that attackers and scanning suites alike feel is worth trying – are those where the path can be changed by embedding extra slash or double-dot characters or sequences. Enough “..” entries in a path, and if the server isn’t properly written or managed, an attacker can escape out of the web server’s restrictions, and visit the operating system disk. The official term for this is a “path traversal attack”.

Credential vulnerabilities

The presence of a padlock – or whatever your web browser shows to indicate an HTTPS, rather than HTTP, connection, indicates a few things:

• Your communication is encrypted (This can be overcome, but it takes so much work at both client and server for most implementations that I think it’s fair to say you will not be in the situation where you see a padlock without the use of encryption.)
• That doesn’t mean to say you will always have the best encryption around, but if you didn’t go and enable weaker encryption than that supplied in a recent and patched browser, you’re fairly well guaranteed to be safe.
• The web site you are connecting to is at least trying to give some indication of security.
• The web site to which you connected has convinced your browser – or you – that it is who it claims to be in the address bar.
• Note that this may not mean that it passes a test of its identity that you really want. You could be in an enterprise with an SSL-interrupting egress filter, as explained above, you could have been convinced fraudulently to accept the site’s certificate, or you could have installed an inappropriate certificate authority’s root certificate.

If you’re the sort of person who clicks through browser warnings, all you’ve managed to confirm is that your communication is encrypted, and the site you’ve connected to is trying to convince you it is secure. Note that this is exactly what a fraudulent site will try to do. The padlock isn’t everything.

Then think about where your secret information goes. If you’re like a lot of users, you’ll be using the same password on every site you connect to, or some variation thereof. Just because the site uses SSL does not mean that you

But at least it’s a start.

If your bank doesn’t use HTTPS when accepting your logon information, it’s a sign that they really aren’t terribly interested in protecting that transaction. Maybe you should ask them why.

Many web sites will use HTTPS on parts of the site, and HTTP on others. Observe what they choose to protect, and what they choose to leave public. Is the publicly-transmitted information truly public? Is it something you want other people in the coffee shop or library to know you’re browsing?

NCSAM/2011–Post 16–FTP is secure

Week 4 of National Cyber Security Awareness Month, and I’m getting into the more advanced topics of secure communications and protocols.

I figured I couldn’t start this topic without something that’s very near and dear to me – the security of FTP.

The good/bad old days

FTP is one of the oldest application protocols for the Internet. You can tell because it has a very low assigned port number (21).

You can also tell, because it actually has two assigned port numbers – 20 for ftp-data and 21 for ftp.

In many ways the old days of the Internet were really good, and in much the same ways, those days were bad. From a security perspective, for instance, those days were bad because none of the protocols considered security very much, if at all. Of course, you could look at this as ‘good’ and note that there weren’t really a whole lot of reasons to include security protections. Most of the original users were government, military or academic, and in each of these situations there were pretty good sanctions to use against evil-doers.

The Middle Ages

In the middle ages of the Internet, the security was still missing from many protocols, and people took advantage of them a lot. Additions like SSL were invented, and we are all familiar with using HTTPS on a web site to protect traffic to and from it.

Other protocols were simply shunned, as was the case with FTP, on the basis that no one was interested in updating them – after all, what with the web and all, who needs FTP?

Modern Day

Fast forward to modern day, and we find that FTP has a poor reputation for security. But is it deserved?

In some respects, yes – FTP has had its fair share of security badness in the past. But it’s also had its share of updates.

First, there was RFC 1579, Firewall Friendly FTP. Not much of a security advance, using PASV (passive) mode to open connections, so that it’s the server’s responsibility to be compatible with its firewall.

Then came RFC 2228, FTP Security Extensions, dealing with additions to FTP to manage encrypted and integrity-protected connections for data and control channel. Good, but the only protocol supported is Kerberos, and nobody really uses that on the open Internet.

Next, RFC 2577, which addresses some of the common areas where FTP implementations suffer from security failings – a definite huge step forward, because finally even new FTP implementations could get things right in terms of many of the security issues seen in older versions.

And recently (OK, so it’s six years old this month in RFC form, and has been developed for a few years before then), RFC 4217, on Securing FTP with TLS – applies the usual SSL and TLS network protection layers to FTP, basing it on the work defined in RFC 2228.

Are we done yet?

I don’t know, but I’m fairly certain that you will find FTP as it exists today is a far more secure protocol than the one described in, say, the PCI DSS requirements. In fact, if you’ve implemented an RFC 4217 compliant FTP server, enabled its protections, and made sure it implements the suggestions in RFC 2577, you can make a good case to your PCI Auditors (QSA, to use the technical term) that this is an acceptable and secure method of transferring data.

So, what’s holding you back from using FTP in your secure environment now? Anything?

NCSAM/2011–Week 3 summary–names and addresses

So, what did we learn this week?

Your user name is not a secret

Because the operating system doesn’t bother to help you hide user names, and because those user names are used in countless protocols as if they were public information, you’re backing a loser if you want to try and act as if the user name is some kind of secret. There is nothing wrong with having predictable user names. If you need more security, make the passwords longer.

Don't bother renaming the Administrator account

Arguments from other security luminaries notwithstanding, I’m still of the opinion that there really is no benefit to renaming the Administrator account, and it’s going to cause plenty of irritation.

What is a fingerprint?

Despite being used as both a claim and proof of identity, it really needs to be seen as one or the other, along with other biometrics. Also worth noting are the ADA and other considerations that some people just don’t have readable fingerprints, if any at all.

An IP address as an authenticator

Don’t do it. Just don’t do it. Use IP addresses as a filter, to cut out the noise, but don’t rely on that as your only authentication measure, because an IP address doesn’t have sufficient rigour to use as an authenticator.

What's the better firewall - black-hole or RFC compliant?

While it’s tempting to think that a black-hole firewall is the best, because it sits silently not responding to unwanted traffic, there are some times when it’s important to respond to unwanted traffic with a “go away, I’m not talking to you”.

Up next week – Communication Protocols

And do, please, leave comments or email to let me know if you’re enjoying this series, which is published because October is “National Cyber Security Awareness Month”.

NCSAM/2011–Post 15–What’s the better firewall–black-hole, or RFC compliant?

So, given the information we have so far, you should be able to answer the question.

Background info

There are two schools of thought when it comes to how a firewall should behave in some situations.

The one school says that a firewall should ignore all traffic that reaches it, unless it is traffic that should be passed on. This is known as a “black hole”, or “fully stealthed” firewall, because it refuses to send any packets in response to communications it didn’t request.

The other school says that a firewall should respond to unexpected traffic exactly like a router that knows it is unable to reach the host being requested. This is the RFC-compliant firewall, because it looks to the RFC documents to decide what should be done in response to each packet it receives.

First, consider the ‘black hole’

Black hole firewalls are named after the cosmological entity of the same name, because they suck packets in and never send them back out again.

Much like a black hole, however, their existence can be deduced by the simple absence of light passing through them – a range of IPs that should be responding with reset packets (aka “go away, not listening”) to incoming TCP requests, are instead simply ignoring them. If the intent of the firewall was to make the attacker lose interest, you’ve already failed.

And now the RFC compliant firewall

The RFC compliant firewall replies to every unwanted TCP connection request with a RST packet, to indicate that the targeted address is not interested in talking.

To a well-behaved TCP connection partner, this is a request to stop all communications and close the connection, without processing any further data.

Which is fine, except all unexpected traffic at a firewall is an attack, right?

Not every packet is an attack

OK, I really telegraphed that one.

Some unwanted TCP packets are actually very informative, and the RST message sent in response is a useful part of keeping your systems safe.

Let’s suppose someone was able to predict, or otherwise get a hold of, the Initial Sequence Numbers we talked about in yesterday’s post. That someone, an attacker, would be able to spoof, or forge, a connection coming from your system, and connect to a targeted server. Even if they couldn’t see what information was coming back, they might be able to make an attack look like it came from you.

The classic example of “what can I do with a spoofed TCP connection” is that of sending email – spam, usually – from the user of an ISP.

But those packets from the server, that the attacker can’t see (but can guess), do go somewhere – and if the Internet is working properly, they go to your computer, or the firewall sitting in front of your computer.

If your firewall is an RFC-compliant firewall, those packets will be seen by the firewall as unexpected and unwanted – and the firewall will send back a RST packet, demanding that your mail server stop trying to communicate with you. This may be the only indication to the server that anything is amiss. Your RST packet, if it arrives quickly enough, will prevent the spam run being done in your name.

If your firewall is a black-hole router, on the other hand, no RST packets will be sent, and the communication between spoofer and server will continue uninterrupted, unabated, and with you potentially on the hook for emails sent “from your IP address”.

[Note that the same argument can be made for a network where the attacker is a man in the middle who can read and inject packets, but is unable to remove packets from the stream between you and the server.]

Not really settled

As with many of the other issues I’ve been talking about this month, there are differing views on this. I’m generally a fan of following the RFCs, because they’ve usually been arrived at by smart people persuading other smart people to a consensus. I’m sure that you’ll run into people with other opinions on this issue, so please feel free to ask more questions and share different opinions. The really fun topics in computing are those where there are multiple answers that could all be right.

NCSAM/2011–Post 14–An IP address as an authenticator?

So we’ve talked a little about names as claims of identities and passwords as proofs of those identities, continuing on to describe a fingerprint as a reasonable proof of identity, but perhaps not so useful when it has to be a claim and proof of identity at the same time.

So, how about an IP address?

A number of applications offer you the ability to accept or deny connections / requests from outsiders, based on their IP address. Good connections / requests from IP addresses that you know are allowed; bad connections / requests from IP addresses that you don’t know (or from IP addresses that you know are bad) are blocked.

Since this looks rather like an authentication scheme, let’s ask the question:

What is the claim of identity, and what is the proof?

UDP – User Datagram Protocol (or “Unreliable”)

Well, for UDP, the claim appears to be the IP address in the “source address” component.

Is this IP address also a proof of identity?

Since I can forge a UDP datagram for any source IP address, I think that means that it can’t possibly be a proof of identity.

So, for UDP traffic, using the source IP address as any kind of authenticator is clearly a bad idea.

TCP – Transmission Control Protocol

TCP is a little stronger of a case, because there’s a connection to be made, and some protections to be had. One of the protections to be had is that the handshake at the beginning of the connection exchanges a couple of random numbers – known as initial sequence numbers (ISNs) – one from the client, and one from the server. The client then has to send packets with a sequence number starting at the ISN the server sent, and the server has to send packets with a sequence number starting at the ISN the client sent. This means that it’s harder to forge TCP connections than UDP requests, because the client has to see the ISN from the server, and vice versa.

Are these ISNs and subsequent sequence numbers a proof of identity?

Not really, because of a number of factors.

• In early days of TCP implementations, the ISN was easily guessed by a spoofing client, who didn’t actually have to see their connection handshake. It’s always possible that a flawed TCP implementation in the future will also generate predictable ISNs.
• The ISN is essentially echoed back, rather than being a secret held by the owner of the identity (IP address) being claimed as the source identity.

All that the ISNs really do is provide a reasonable protection against massive floods of forged connection attempts, by requiring that the client be able to receive and respond to the server’s messages. Some schemes even make use of this further, and don’t create the actual connection object until receiving the first packet with the correct sequence number.

If they aren’t a proof of identity, how can someone spoof me?

There is always the possibility of a third party who can listen to your conversations, and spoof portions of your communications. They can know your ISN, and use it to initiate or continue connections you make to other servers.

This usually requires the attacker to be a “man in the middle” (MITM), and remember, an attacker can do that through a wireless connection.

The only protection you have is if you also are a part of this conversation and can send a quick message along the lines of “stop, don’t trust him, he’s not really me”.

This would be the RST, or reset, message, that aborts a TCP connection, usually because inappropriate (out-of-standard) traffic has been detected. We’ll touch on that more in the next post.

Bottom line: IP address is not an authenticator

So, while it might be a good filter for convenience and traffic reduction, filtering by source IP address is not something you can consider as a security measure, because there is no authentication involved.

Rather like the “TCP evil flag”, it does require that someone be truthful when attacking you, so that you can repel them.

NCSAM/2011–Post 13–What’s a fingerprint–name or password?

I’ve given a couple of arguments about names and why they shouldn’t be treated like passwords now, and because I always like to turn problems into classes of problems to be solved (the “meta-approach”), I figured a long time ago that I should decide what it is that makes a name different from a password, and whether I could apply that to the security world as a whole.

A Name is a Claim

A name is a claim of your identity. “Hello, I’m Bob,” says the badge – but anyone could wear that badge, much to the consternation of any real Bobs who happen to be bobbing around in the background. [Another name for a claim is an “assertion”, but the term “claim” seems to have won out in recent security discussions.]

An identity claim is best when it’s unique – so that claiming to be “Bob” is only useful if no one other than the one, true “Bob” gets to use that name.

A Password is a Proof

Your password, by comparison, is a proof of your identity.

Your password is not unique – which is good, because if you set your password to “frebbot”, and the system told you “that password is not unique”, you’d have a relatively easy time of going through each user on the system to find out who had that password.

Occasionally, systems are proposed where the entry of a password is all that is required to establish an identity – the proof is needed, but the claim is not. This is an example of a truly pathological case of unique passwords, in which you don’t even need to guess whose account has the password that you’ve just been denied.

So, what’s a fingerprint?

I’ll readily admit to enjoying using a fingerprint reader as a convenience device on my home computer. It’s a great way of quickly logging on to a system that no more than about four legitimate users are registered on, so I’m not going to say that fingerprints are unusable in all cases.

However, by the descriptions above, your fingerprint serves as both a claim of an identity, and a proof of that identity.

This alone rings alarm bells, and is a reason not to use it in an environment such as an enterprise, where hundreds, maybe thousands, of people are registered, and where a relatively simple few mistakes in reading a fingerprint could result in being identified as an entirely different user.

Other reasons to distrust fingerprints

There are, of course, further reasons why I would discourage security practitioners in business to avoid fingerprints as a security measure.

• Hygiene. Fingers are dirty appendages, thrust into ears, mouths and noses on regular occasions, and having a shared device whose designed purpose is to wipe fingers across seems to be a problem, even if you are far from being a germophobe. The only device I have with that purpose in mind is a hanky, and I wash those after each day in which I use them.
• Bad matches. False negatives are inconvenient, but not greatly so. False positives are disastrous, as you cannot predict who is going to be hit by them. There are a number of high profile cases of individuals who have been misidentified in criminal cases by partial fingerprints, or rotated fingerprints (imagine, a supposedly unique identifier that becomes non-unique when you add a consideration of rotation by right-angles)
• Revocation. If you ever do find two people whose fingers match, you can’t replace them with non-matching fingers. OK, so you can, but fewer than a dozen times.
• Failure. Some individuals don’t register as having fingerprints. As with any biometric, there will be people who can’t use it – whether because they have no fingers, or simply no recognisable fingerprints.
• Theft. Steal a Mercedes S-class and realise you need a fingerprint to unlock it. OK, so kidnap the owner so that you can steal the car. Then realisation dawns that you don’t need all of the owner. Just the finger.
• Mathematical rigour – or lack of it. We really don’t know how fingerprints form, and there aren’t sufficiently large studies to back up the use of a fingerprint as an entirely unique identifier. There are cases of mistaken conviction from fingerprint evidence that demonstrate fingerprints can be matched to people who didn’t plant the prints.
• Scientific rigour – lack of. Addressing the issue of the theft of a finger, some fingerprint readers claim to not be fooled by excised fingers. To make such a claim with any scientific rigour, they would have to have tested a finger several times for low false reject rate while attached, and then tested it for false accept rate once detached. I can’t see anyone volunteering for that study.

NCSAM/2011–Post 12–Don’t bother renaming Administrator

My argument here is much in the same vein as my previous post on choosing random usernames.

I’ve met a number of people who argue that renaming the built-in Windows Administrator account is a great security measure, because an attacker now has to guess the name of the Administrator account as well as its password.

Or they put it a little more scientifically, and say that renaming the Administrator account increases the entropy already present in the password.

If you want more entropy in the password, put more entropy in the password

Seems pretty obvious to me, really.

If your passwords don’t have enough entropy (more or less equivalent to “random” in the everyday sense of the word), add more entropy – use a wider range of characters, or simply make the minimum password length that much longer.

The system works against you

If you make the name of the Administrator account a secret, that’s really no good, because the system works against you. It does absolutely nothing to protect you. A simple call to “NET USER” will list the local users, including the local administrator, and a relatively simple ICACLS command will apply rights to the local administrator – no matter its name – on a file. And then you can list the file’s permissions – again using ICACLS – to see what the name is for that administrator.

The one argument in its favour

There is one argument I accept as moderately valid for renaming the Administrator – now you can go ahead and treat every attempt to use the “Administrator” account as an attack, because none of the valid uses of the renamed-Administrator account will use that user name.

But so many arguments against

So now for some arguments against – unlike the “doesn’t really add entropy” point above, these are areas in which renaming the Administrator account does actual harm:

• You can’t reuse scripts and applications without having to reconfigure them so as not to use the Administrator name, but your “NotReallyTheAdministrator” account.
  • If that’s even possible for the app you want to use – I know, that would be a bad app, but when’s the last time you went a week without having to use an app with some bad behaviour?
• You have to supply the new Administrator name to each person who has to use the account. [Re-training]
• Your single Administrator account should already be treated as if every use is an attack, because individual administrators should have their own account, to allow for auditing and revocation. The Administrator account should be rarely used.
• You have to change the Administrator account as soon as anyone who knows it leaves (and because anyone can find it out, that’s fairly frequently!)

And my favouritest argument of all:

• There are very many things, more important than renaming the Administrator account in securing your systems, that you have not yet done, and which will take less time to do than implementing all the infrastructure and operational procedures required to rename your Administrator account and keep it correctly monitored and managed.

NCSAM/2011–Post 11–Your user name is not a secret

It always amuses me when I receive an email where the “From” line reads something like this:

From: mo95213@example.com (Davis McTeague)

Because what this means to me is that some well-meaning security practitioner has decided that giving users random names “adds to the entropy in the password” – meaning that it’s harder to guess the user’s name and their password at the same time, than just guessing the password, because the user name is clear and obvious.

Of course, the email kind of gives it all away.

Lockout policies and the random username

I had one of these usernames at one point in my past career. “us43792”, I think it was. Or “us43972”, or “us42793”. Maybe.

Every Monday morning, I did the same dance, of trying to remember my username. And, because the well-meaning security practitioners had also decided that the “three bad logon requires lockout” policy was a great idea, every Monday, I managed to lock some other user out of his or her account, because instead of getting my password wrong, I’d get my username wrong.

I really felt bad for whoever it was that I was locking out of their account. They probably had a hell of a time every Monday, calling up tech support, and asking to have their account unlocked, and tech support treating them like they were idiots for messing up their password every week.

I suppose I could have simply written down my username, but that was as much against the spirit of the policy on random usernames as it would have been to write down my password. So each Monday, I caused a lockout event to some other person in the company, wasting their time, and that of whoever they called in tech support.

The random username and entropy

While it’s true in some ways that a random username adds entropy (you might think of this as “randomness”) to the whole logon sequence, it’s not lasting entropy, because even when the user changes their password, they aren’t changing their username as well, so that part isn’t getting updated. And as time goes by, a lot of people know the user’s name. Everyone they email, everyone they hand their business card to (which includes every lunch establishment around the neighbourhood), now has that information.

It doesn’t matter any more that the username isn’t predictable, because it’s known by fundamentally everyone.

It’s public information.

The system is working against you

My final point against random usernames is that the whole system – and not just the operating system – is working against you in keeping this entropy secret.

Email messages aren’t the only way in which usernames are exposed. Every time you authenticate to a networked application, although challenge-response techniques allow you to keep your password secure from that application, your username is still passed to that application unaltered. File sharing requests are made using the same sort of technology, meaning that your username is sent there. Many other networking protocols carry the username around, and users themselves have all sorts of outlets for sharing their username, from home directories named after them, to instructions on contacting them through email or messaging.

My username is “alun”

I think that says enough.

NCSAM/2011–Week 2 summary–wireless networking (Wi-Fi)

So, what did we learn this week?

Don't disable SSID broadcast

While it may sound like it helps you secure your network, it doesn’t really do anything of the sort. About the only argument in favour of this feature is that it causes casual users to select a different SSID to connect to when they’re looking to leech free WiFi. Not a security feature, because your SSID is broadcast by every device as it searches to connect to your router.

Don't use WEP or WPA

These encryption protocols are flawed and take seconds to break. WPA2 is the only current strong encryption mode for wireless traffic, and for enterprises, you can look to 802.1x as an alternative.

Beware Rogue Access Points

Whether it’s “HPSetup”, “Free Public Wi-Fi”, “attwifi”, “Starbucks” or a number of other SSIDs, there are people out there who set up their computer to look like a wireless router, and to offer free Internet, in the hope that they can steal your credentials, your traffic, your transactions, your money. Make sure you connect to the right access point for the environment you’re in, and take other measures to protect yourself.

Use a VPN

Connect back home to your own VPN. Ask if your ISP has a VPN you can connect through when you don’t trust the local network.

WiFi is MITM Central

Although we used to say that the Internet was somewhat safe – even if not secured – that isn’t true when the medium you connect over is a public, broadcast and interceptable signal such is Wi-Fi. On a wireless network, everyone can read your packets, everyone can write packets pretending to be from you, and anyone can pretend to be the local Wireless Access Point (WAP).

Up next week: Names and Addresses

And do, please, leave comments or email to let me know if you’re enjoying this series, which is published because October is “National Cyber Security Awareness Month”.

NCSAM/2011–Post 10–WiFi is MITM central

So, why all the fuss about securing Wi-Fi?

And what’s this “MITM” you talk about in the title of this post?

MITM is a common abbreviation for “Man In The Middle”, a type of computer security attack, in which the attacker sits between the two ends of a conversation. As you can imagine, if you call your bank, and there’s someone in between you and your bank, they can pretend at the same time to be both you and the bank.

So, as you can see, it’s a bad idea to let an attacker get in between you and your bank – or your job, or your home, or anything to which you are communicating where it is important to be sure that you get uninterrupted and unintercepted communication.

In the old days, this was hard

For the longest time, security had an easy out – you could actually tell people “sure, someone could listen into that conversation and/or alter it, but they’d have to be in a position of responsibility, such as the network provider, the telephone company, the bank, etc”. Which was pretty much true, because it was really unlikely that someone could actually steal your communications without already being in the sort of position that allowed them full and trusted access to the sort of information you might want to keep from an attacker.

You already trust the phone company, the ISP, the bank, etc, that you use, so you’re not in a worse position by continuing to trust them.

The wrinkle in all of that is when you are in a situation where you cannot trust the communications medium that you use.

Public – really public – networking

You may think you’re on a public network whenever you use the Internet, and to a limited extent this is true – you can reach other people on the Internet (if they let you), and they can reach you (if you let them).

When you’re using Wi-Fi, however, by definition the medium over which you communicate is a public medium in the truest sense – it is broadcast, as if everyone were bellowing over megaphones. And when your computer receives a message from the coffee shop’s wireless router, inviting it to connect, it has no means of distinguishing that from a similar message sent by the attacker sat at the next table over.

Is an attacker really likely to be sitting in your coffee shop?

It depends – if you were an attacker, would you hang out there? Certainly coffee shops where employees go to talk about secret projects are going to be targets. Is it worth taking that risk, when there are some relatively simple measures you can take to protect yourself?

What about the other places you connect to for wireless Internet and then conduct your business (whether personal or work) – I’ll bet there’s an attacker sitting in range of the airport Wi-Fi, in the library, at the University book store, at the school.

And the attackers have tools that make it dreadfully easy to hijack your traffic if you aren’t taking good measures – such as always connecting to your ‘home’ VPN. Sadly, the attackers don’t even need to be all that bright to intercept your traffic any more, if you aren’t using a VPN.

Are there any other public networks?

There can be – we have certainly seen that some cable TV providers, when they added Internet connectivity as a service, forgot to prevent your traffic from being seen by your neighbours. They should be mostly over that by now, certainly if you have a big name cable provider like Comcast. But if you can’t trust your cable company to provide you with quality TV, you can’t really trust them to have your security in mind when provisioning Internet service.