Maybe you noticed, maybe not, the site got defaced yesterday for couple of hours. Terrible, isn’t it? Actually, not very much.

The old boring index files had been replaced by a fancy-Turkish-something for a little while, that's all what happened. A rumour has it that especially the tune played by the replacement site was nice. By now you probably wonder what the hell happened. Guess what, turns out the Movable Type 3.33 has some minor (yet, as you can see sufficient) vulnerabilities, which served the very purpose of defacing the blog. And guess what, the version 3.34, where all these identified flaws are fixed, released Jan 17, didn't make it to the blog yet.

But. In case any harm was done to the data, I would have it back again from an off-site backup in no time. And now, the administrative interface is accessible only from trusted IPs — learn something every day, they say.

Lessons learned: 1) patching the software immediately after patches are released (following the change management procedure though) usually pays off; 2) having an off-site up-to-date backup of all sensitive information buys you peace of mind (for a fairly low price); 3) it's always good to separate administrative interface from the publicly available content — the lower level the separation is done on, the more bulletproof the solution is.

And as a bonus, some problems with user input sanitation in a contact form code (not part of MT) found.

It's not anything near a good idea to migrate any sensitive environment to Vista just now, that's for certain. Too much of the code has been rewritten to not introduce some very exciting vulnerabilities.

But it's pretty interesting to have a look at what's going on in there. And it seems there is at least couple of entirely new and revolutionary concepts in there. Well, maybe it's neither revolutionary nor new, but at least it's screwed up in a really refreshing and admirable way.

But to the point. There is two major flaws in Microsoft's design of the so called User Account Control (UAC) mechanism: 1) it, hell knows why, assumes that all setup executables need administrator privileges when being run and 2) there is no assumption that using an administrative account user does it deliberately and consciously.

While the first flaw is pretty straight forward and just defeats the whole purpose of using a restricted account, the second one is a little bit more sophisticated. Microsoft decided the well known model of securing high privileged accounts using a per task login mechanism (like sudo) is not good enough for Vista users and designed their own solution. Behold!

There are two possibilities: 1) if you don't have administrative privileges and for whatever reason you need to elevate them, you will be prompted for a password along with the information that the action is potentially dangerous (nothing special by now) or 2) if you do have the administrative privileges, you will just be prompted to confirm that you are aware of trouble that you may possibly run into when proceeding with whatever you were to do (cool, ehh?). Not that bad, as you expected?

Well, it's seriously worse than it may seem, because from a user perspective there is no difference, besides when they work as Administrator, they don't need to type in that wacky password every now and then. But they're equally prompted that the action may be potentially dangerous, etc. each time privileges are to be effectively elevated. So, from the average user's perspective what is the exact difference between administrative account and the normal one? Besides it's easier to work as Administrator not being prompted for the password all the time? Close to none?

It's even worse, because the information displayed when elevating privileges may become so annoying as to cause a serious temptation to turn the whole contraption off. And even if not, it will get into a habit to just automatically discard the message a moment it jumps out.

Conclusion? Putting in a lot of popups saying "Hey, what you gonna do may blow your system apart... or not. The only way to find out is to proceed. So. What do you say?" is not the best idea one can imagine. Because those who already know this, don't need this. And those, who don't know this, should not be using an administrative account. The way better idea is to, along with implementing the mechanism of per task privileges elevation (as it's been done), promote a policy of not using an administrative account for day-to-day activities.

It's all about user awareness of the concept of using privileges based on the "need to have" principle. One does not need effective administrative privileges to run minesweeper, so don't give it to them. Why not to entirely block the ability to login onto the administrative accounts interactively (as opposite to a per task login)? If it's any trouble to login interactively, people won't do it unless they realy need it.

Seems like it's all about the defaults and laziness...

Enforcing desired level of confidentiality of specific data takes preventing unauthorised people from tampering with the data. It boils down to separating sensitive assets from people who have not been granted access to them. The proper separation needs actions on both, assets and people.

The assets should be divided depending on their sensitivity (particularly confidentiality). And by divided I mean physically separated, so no-one with no proper clearance is allowed to access the location.

Equally important is to properly manage staff's access rights. Clearances should be given only to people properly screened before, so trustworthy enough (it's hard to put it less precise, I know) and only on the "need to know" or "need to have" basis.

And to complete the picture special emergency (fire, etc.) procedures for restricted zones should be developed, so that neither unauthorised people are able to access sensitive locations nor people evacuating from restricted areas are able to mix with them. It considerably improves both, access control and user accountability.

Pretty obvious, but... you know how it is.