When is security "Over the Line"?

I've been trying out various security apps for Android, including location and theft tracking, secure e-mail and other device control techniques. I came across Google Apps Device Policy in the Play Store (among others). There's a handy little device management panel. I found the features a bit sparse - I could only see options to remotely wipe the device, locate it and make it ring nice and loud (I have a fairly discreet ringtone), though even this came in handy this very morning (housewarming, cocktails, phone-based DJ system, details are fuzzy towards the end of the night, great party).
A bit more digging and I found the full-blown control panel in my Apps admin page, and there all the meat is laid out - requiring the device management policies be enabled before e-mail can be subscribed to, forcing password policies and the like.
I did notice one comment that stood out in the review page on Play Store entitled "Over the Line". It's a bit of a rant, with the poster complaining about the power the device policy gives his IT department. Some education is certainly required here.
We're living in a very close approximation of Arthur C. Clarke's World of Tomorrow, but even he would probably have been surprised by the sheer power and connectedness of the devices we carry in our pockets and purses. The old adage of our phones outpowering the lunar module is somewhat behind us; they're performing megabytes of 256-bit encryption per second and rendering 3D worlds at a rate that would make older Silicon Graphics workstations blink. Yet we treat them with no more concern than a wristwatch, merely a tool for consuming information and perhaps flinging a bird from a catapult.
E-mail is sensitive. I still don't think we've fully understood the ramifications of transferring our brick-and-mortar existence fronted by a postbox to simply occupying a few square millimeters of hard drive space. Pinging an e-mail address to verify my identity when recovering a password (on services as sensitive as PayPal no less) have deep flaws, most based on the assumption that users understand account security and host the address at a secure provider. Corporate e-mail is generally even more precious, and teams of people in IT departments around the world spend their entire day protecting digital assets from the wide world of internets.
So how do casual devices interact with secure systems? A lot of banks have pared-down versions of their mobile banking websites available as apps with little risk of being vectors for attack - sensitive information is not stored on the device (and my previous post describes how easily and frequently that device's security can be engineered for flimsiness), and practices such as limiting the potential harm through daily limits.
E-mail clients tend to be more of a problem, with contents stored for long periods of time, users expecting to be able to retrieve arbitrary content outside of the retention window, creating and sending new messages without explicit authentication, and others. This is something of a nightmare scenario for organisations, large and small.
There are two outcomes from this. First, the powers provided by these policies are only invoked as necessary. I can imagine a very real case of damage claim should the department decide to wipe your device without notifying you up-front, regardless of reason. Yes, there is a lot of power there, but it only really makes sense if the company is facing imminent loss, either through the user misplacing the device or having it stolen, or worse yet if the user has malicious intent. The warning screen is there to explicitly inform you what you're signing up for and gaining your acquiescence. I remember no such introduction when handed my first Blackberry, but it doesn't grant the IT administrators any less power to remotely wipe it (including my own data that happened to be stored) when necessary.
The second though is that the device becomes a very real part of that network. Companies have policies for all kinds of things, the sense of which are not immediately apparent - sign-in at the front desk is ostensibly to ensure you are accounted for in the event of fire evacuation where security is not primary, something I didn't realise for some years when I first started working. A friend of mine with a very corporate job had a clause in her contract that she was permitted to dye her hair, but only to the range of natural hair colours. I can certainly imagine reputational harm if she arrived at a customer properly suited and booted as required, but sporting electric-blue locks. While there is no accounting for taste in corporate contracts, I would imagine this seems entirely reasonable to the vast majority of people. I suspect those who find such a policy repulsive probably wouldn't want to work there for other reasons.
A compromised device closely coupled with a corporate e-mail system can cause very real harm. Address book caching, calendar searches and assuming the identity of the original owner are powerful tools for an intruder. There is an option here.
While a company can require you wear their uniform for a job, they're far less likely to require you sew a logo onto your own clothes. You can choose to, but I doubt they would be happy if you did this in an inappropriate position as it would cause them reputational harm, and e-mail is similarly interesting.
If you truly require mobile e-mail access, perhaps your company should be paying for that service instead of free-riding your mobile contract and making you nervous about your device integrity? I know my Android device allow my to remove the enforcement agent myself, which very quickly removes the corporate e-mail from the phone as a consequence. You're in control, which fits since you're paying for it.
And if you're the only one who thinks you need it, why do you get to decide how much risk the company should accept? I know my organisation has absolutely no policy for remote wipe even though I accepted exactly that power when hooking my device to the corporate e-mail system, but it still jumped out at me.
With great power comes great responsibility.
It's not a wristwatch.

Locking myself out

I've become quite adept with Android ROMs of late. In the last month I've re-flashed my HTC Legend at least eight times, one of them a desperate measure to get back in after idiotic inattentiveness.
The after-market firmware scene is amazingly vibrant, and I'm typing this post on Cyanogenmod's CM7.2, which brings Gingerbread (Android 2.3) to my two-year old device, something the manufacturer has no intentions of doing. Just as in my previous post about digital legacy, the open-source community is doing what vendors simply won't, and surprisingly well. I'm so pleased I've even offered to upgrade a (decidedly untechnical) friend's Legend.
Doing this requires bypassing the vendor's OS locks - "rooting" - and optionally the firmware locks. By default, open ROMs leave these locks off to preserve your Newfoundland freedom. There's a problem there.
Yes, I want to continue hacking away, but I'm not comfortable leaving root accessible for my friend's device. A diagnostic mechanism called USB Debugging doesn't reset itself on reboots rendering the screen lock rather useless. The Cyanogenmod authors have stated root access will be off by default from version 9 (Android 4.0) onwards, but the Tom I tried on my device (so very close to useable) had no such measure.
Should a rooted and reflashed device be misplaced or stolen, the new owner could quite easily get in. Remote wipe and location apps can be disabled (Link2SD makes this trivial) and data compromised. As a network administrator I wouldn't let one of these devices anywhere near my messaging system, since the policy enforcement engines rely in unprivileged users to function.
I could of course re-applt the vendor recovery software to prevent the OS image being altered, and re-enable firmware controls to stop this being undermines, but this is all moot once the OS can do as it pleases.
Open-source software thrives on freedom, and I love that attitude, but ensuring a well-controlled network often works against that when viewed from certain angles. So, what path?
Security systems relying on obscurity of design have repeatedly been subverted, but how do you convince open-sourcers to build effective blockouts into their project?

Perhaps by helping them realise the real loss their moms and kids might experience when their unrelentingly open device is abused?

Blizzard, a Few Words on API Implementation

Over on battle.net, Blizzard is defending their action of banning users for using Wine to run copies of their hugely popular Sword & Sorcery game Diablo III. In Blizzard’s words:

Account Action: Account Closure
Offense: Unapproved Third Party Software
A third party program is any file or program that is used in addition to the game to gain an unfair advantage. These programs may increase movement speed or teleport heroes from one place to another beyond what is allowed by game design. It also includes any programs that obtain information from the game that is not normally available to the regular player or that transmit or modify any of the game files.

Now I happen to know a fair bit about the internals of Linux and Windows, and can say one thing for certain: Wine is not the problem.
As mentioned on Ubuntu Vibes, the Wine developers are keen to distance themselves from the issue, and fair to them it is not their fight. But Blizzard definitely has some explaining to do.
I have been very much on the side of those calling foul of Blizzard's method of providing the game state, essentially running a single-player game on their servers. While Diablo II saved locally and ran game logic entirely independent of servers, a single-player game in Diablo III is essentially a single user multiplayer instance – all state is held on their servers. This has advantages, like quickly and more reliably allowing me to invite internet users to join my game, but that’s about the only benefit I can see.
It would appear that Blizzard are trying to clarify that they don’t ban based on OS (or API implementation), and its a subtle point. Whether cheating is actually happening in this particular community as they allege is not quite evident, but since Blizzard don’t reveal the exploit a user is supposed to be using there is no recourse for refund or rectification. I’ll leave that point alone, save to say that I would prefer other users don't cheat, but that it’s irrelevant if I’m in a single-player game. Unfortunately, the way the game is designed there is no such thing.
There’s been ranting about other problems, but one I’m most interested in is legacy. The reason almost any software has a minimum specification for operating system is a guarantee that they APIs they need will be present. Wine is an undertaking to replicate the APIs in Windows for use on other platforms, prominently Linux. Backwards compatibility is the bane of Microsoft’s existence, but there’s no option there really.
The big issue here is the digital legacy. I used to play with my father’s toys as a kid, and he with mine – that is until I started gaming. I have a partner who went barking mad as the release for Diablo III approached simply because she was excited to relive the enormous amount of time she wasted in college playing Diablo II. The problem is even graver than if Steam went dark for good where i simply couldn’t install my games. If Blizzard pulls the plug I cant launch games I’ve already installed, ever! And frankly, twenty years from now I just might like a shot of nostalgia.
But the hardware/operating system of the future might not support it you say? I’d say you’re dead wrong! Steam released the classic X-COM games packaged running in DOSBox, showing that there are solutions to anciently legacy games on modern platforms, and open-source no less.
So just what is Blizzard’s problem? The fact that Wine presents a functional implementation of the Win32 API is of little relevance. there’s no clear statement that non-Microsoft/Apple platforms are enough to get you kicked, far from it they leave it up to users to employ best-efforts. Blizzard may very well claim that they only support native implementations, but WOW64 is really an implementation of the Win32 APIs, when the underlying system is in fact 64-bit.
So, we have both closed-source and open-source solutions to the problem of running legacy code, both apparently providing a reasonably good experience (in fairness I think the Windows implementation is excellent, no idea on quality using Wine). Twenty years from now I have a fairly good feeling there will be legacy emulators (Windows 7-in-DOSBox, Wine for Linux 7 or something as-yet undreamed of), but I am almost certain Blizzard won’t be keeping up a service for Diablo III, even if I just want to show my kids how their dad used to kill demons fell more in love with their mom.

Zero-effort Theft Tracking

This little nugget (nhinkle on SuperUser blog) popped up on Slashdot recently, describing just how Windows 7 (and I presume Windows Vista) knows whether your network connection is an unrestricted Internet conenction, has no connectivity beyond the local LAN or are behind a hotspot authorisation page. Of course, the state of your network connection may be more complex than that (proxy server requiring authorisation, badly configured routing, or wrongly reporting a working connection that drops your VPN traffic), but it's mostly quite good.

Essentially, the first thing the Network Location Awareness service does is check if it can retrieve a url specified in the registry, and if the contents of that file match a set string. If successful, NLA assumes you have full connectivity. If it fails, a DNS lookup similarly needs to match a specified IP, in which case it assumes you need to authenticate (e.g. you're on a hotspot).

The privacy concern is that your system is checking-in with a server controlled by Microsoft every time it attaches to a network, and periodically after that. Obviously, nobody knows how or if Microsoft is using any logs of these check-ins, but it opens an intriguing possibility now that instructions in the article reveal how to customise this behaviour. Essentially, you can instruct NLA to check-in with any URL you like.

As long as the file is retrieved with a 200 OK result and the string matches (apparently it's even sensitive to an extra CR/LF, so make sure it's generated correctly), everything is hunky-dory. But here's another possibility...

The URL retrieved doesn't have to be a simple text file. The URL could actually query a script (PHP, ASP(X) etc), as long as it returns a specified result. Using Group Policy, an administrator can update the URL to include a client-specific parameter (say an asset code, MAC address, serial number, username etc) in the form of http://some.server.com/NLACheckin.php?Serial=1234. The server script can then note the source IP/subnet of the request in a database, and presto! Real-time location tracking. Group Policies and/or client-side scripts make this rather trivial.

The great part of this is that it doesn't require any specific check-in, theft tracking or other location software to be installed, and the service cannot be disabled by an ordinary user. It doesn't look like there's any action that can be launched on a specific response in the client end (say shuitting down the device), but it offers an extremely simple way to find stolen computers. It's no defense against a wipe-and-reinstall, but for the gain it's well worth the effort.

 

What is a Read Receipt?

I saw a posting on GMail's messaging forums today about their apparent lack of the facility to have a Read Receipt generated. I felt compelled to reply, and I thought I'd post it here too as it's something not quite as obvious as it might first seem. Google is moving more and more into the enterprise, and this is a standard feature that is just plain missing, so obviously it's noticed. To me, it's more of a social than technical challenge...

A Read Receipt is quite the misnomer: the best you can say is that the message was shown on a screen. Which screen though? GMail is accessible through  the webmail, POP3, IMAP, mobile devices (GMail native client, Exchange Sync), mobile web... what exactly are you trying to prove happened?

I've found Read Receipts to be near useless, while Delivery Receipts are generally poorly implemented and probably achieve the same thing: some systems will say that they've taken receipt of the message into the system, but what you actually want to know is that it has successfully arrived in the user's mailbox. Signing for a courier delivery is exactly that, but you'll never know if the recipient ever opened the package.

If you're so keen to know whether the person opened the mail, ask them to confirm receipt manually. Having a computer tell you that you read something is at best trivial and at worst misleading. For a one-line e-mail,this facility may be useful and mostly true, you're likely to have absorbed it. A 1000-word essay, what you really want to know is not just that it was displayed on some screen (and reading that much on a mobile is pointless), but rather that the end-user absorbed everything. Only the user can attest to that.

On principle, keep read receipts out of GMail (or other providers, even Exchange!), and these problems go away. Just ask for a reply that your message is received, understood and/or acted upon. Much more useful.

I'm very disappointed to report that it works

A friend of mine was recently reviewing a friend's CV, and noted he had an ethical hacking qualification. I found this rather amusing, since I know there are a gazillion unqualified, uncertified hackers (and simply curious people) who I'd much, much rather be on some kind of radar. It reminds me of the DRM/DMCA debate: it's the ones not following the rules that tend to get the benefit, or at least know enough about the rules to not care about enforcement.

I have been having a series of discussions with a few security specialists in the last two weeks, and they've put a few seeds in my brain. I've reviewed a few articles about application vulnerabilities, and with more and more of the world moving into "the cloud" (btw, I hate that phrase) we're handing over more control to this nebulous entity. Google are definitely at the front, at least as far as end-user experience goes. Heck, I'm hosting this very blog on Google's servers, and neither know nor care where they are.

I also recently acquired an Android phone, and allowed Google's hooks into my life to sink just that bit deeper with integrated messaging, contacts, calendaring, apps I really don't need, Facebook on-the-go, Twitter... it's all cloud! I left my laptop at a friend's house recently, and realised (to my own shock) that frankly, I can live without it for a day or two, such is the functionality in this great new device.

So while all the focus is off in the cumulo-nimbus, I'm still dealing with daily life that's hosted and automated on some providers that are definitely well-defined. My bank is one of them, and as an extra I do some share dealing with their attached brokerage. Side note: three years ago I had spare cash and thought "what's safer than banks?".

Today, I placed an order to sell a few shares and received an order number. I recalled a conversation with one of these specialists about session identifiers where we discussed collision avoidance and non-sequentialness as two good markers for session tracking. On a whim, I took the URL generated by the transaction ID to view details and incremented the trade identifier by one digit.

Lo and behold, I got the details of someone else's trade. One thousand shares of an oil company, concluded around the same time as mine. Alarmed, I did it again, this time decrementing (I'd hit an upper bound), and found an incomplete trade. This is an order, as yet unfulfilled, awaiting the conditions set by the initiator. Now granted, i couldn't see the identity of the trader (in either case), so perhaps on the surface not such a big deal. But, if you know dealing, complete trades are not so significant as they are done and dusted, while incomplete trades show intention. Script this query for current and future IDs, and you could get a feel for investor sentiment that gives you an advantage.

I've been using this particular trading system for years, and regardless of the losses I've made (seriously, I have no aptitude for this) thought of the security measures as fairly robust: SSL encryption, separate login and dealing password both never revealed in full, limits on trading volume by account type and history, approved browser versions only. How easily we are placated.

Handing over so much of our personal info into the (at least free) cloud scares me, though I'm conscious of the fact that free products are, in the sage words of my father, worth what you paid for them. Paid services may not fare much better; by abstracting services into this fog, we run the risk of losing touch with how services are delivered, how we control them, and what we stand to lose if it all goes wrong.

But most of all, they're still built and run to the same rules as traditional systems, no matter how abstractly they're presented. The same DBMSs, the same web servers and runtimes, the same developers and critically the same developer mentalities.

A sobering lesson indeed.

Oh, and yes I raised this with the brokerage concerned. Does that get me the ethical badge?

Security by Default in the Defined Domain

Some simple security concepts are tougher for engineers to grasp than they should be. A pervasive view I've found is that firewalls, security policies, LAN partitioning and excess of routing tend to just get in the way of making systems work.

Now certainly, large enterprises and especially security sensitive ones requiring secure access to and transmission of data such as financial services, R&D, law enforcement and others do require a higher level of attention to detail when designing and operating their systems. Most engineers cut their teeth building systems in the privacy of their homes or labs, neither of which can match the scale and complexity of real-world systems spanning continents, regulatory domains and most importantly untrusted links. When learning and experimenting, the engineer tends to be in control of everything.

Secure authentication is enabled by default in Windows, with Kerberos providing one of the most resilient systems available, and AD integration makes expansion and administration a breeze. But most of the remaining protocols don't pay too much attention, starting with the most pervasive - CIFS (Windows File Sharing). Even RDP starts off with secure authentication then moves on to a plaintext stream for keyboard inputs and screen updates.

I'm a big fan of IPSec, since it allows for transparent encryption and authentication without having to do pretty much anything to your applications or network layout. The problem comes in getting all your nodes to play nice, since it does require some configuration. Windows domain policies and domain membership vastly simplifies this - if your system is a domain member, enabling opportunistic IPSec encryption is a breeze.

This is the "Defined Domain", a set of systems over which you have complete control. A visitor to your network would not have these policies defined, so their device would not be able to participate, but placing them in a guest LAN and tunneling the connection at the router over a secure connection in Tunnel mode can help solve that problem, but it can quickly spiral out from there - how do you get simpler devices and protocols like SNMP and even PING to cooperate?

The Defined Domain needs to incorporate not just the systems you're protecting, but also how and why. Secure protocols aren't that hard to come by these days (e.g. SNMPv3 incorporates some measure of encryption, SSL is available in all major web platforms), but still requires some configuration and attention. Applications need to be designed with at least some measure of awareness of the security domain if they are to be trusted, and administrators and designers most of all need to keep this in their head when going about their work.

The biggest threat to any security domain is and will always be the human factor. By incorporating security devices in an easy-to-use package, and often transparent, it can make the average engineer immune to the considerations required to make systems truly secure. Yet again, ease induces laziness, and the worst kind of security is the kind you can't (or won't) verify. It took about two hours of use before a colleague of mine noticed his newly-secured RDP session (certificate-based authentication) placed a new padlock symbol on the control bar of his Terminal Services Client. Until then, the idea that the connection was relatively more secure was fairly unverifiable, and eventually irrelevant.

Attention is required, and a lot of education. No one security solution is a panacea (everyone kept screaming certificates at me, as a one-size fits all solution, no no no), and this will always be the problem.

At least in a defined domain, it's more manageable, more approachable. And then along come the users...