Let’s talk a bit about session riding also referred to as Cross Site Request Forgery (XSRF). It seems to be as common of a vulnerability as it is underestimated in terms of a risk it poses to the data kept in and processed by the application.

The general idea behind the attack is to execute certain command in a legitimate user’s authentication context, thus saving the trouble of hacking into an application the hard way. It’s all about convincing a user, preferably with the highest access privileges possible, to enter a maliciously forged URI or webpage while their session in the vulnerable application is active (i.e. they are logged-in and have a valid session cookie).

As a supplement to my recent post on XSRF and to kind of give a complete picture — if there is a lot of money on stake, or if we are paranoid (which is not so good, but not too bad either) we can always decide to use an additional, independent channel when authorising extra-sensitive operations.

Even better, this kind of approach should prove useful defending against most of the attacks that aim to overcome authorisation controls in order to gain unauthorised access to sensitive data or to perform an unauthorised operation, like, say, wire-transfer all your money to a bank account somewhere over in Caymans.

You may ask, how is it that we are sure about the additional channel’s security. Well, it would be great if we could be sure about it, but usually we can’t. But it’s not the point. The point here is that an additional separate — and verified! — channel makes it much more difficult for an attacker to perform their malicious activities, as they need to take over both of them in order to succeed (say, intercept an SMS message and inject their own in its place — although doable, it takes a lot of effort and money). Think of it as a way of re-authenticating before a security-critical task, but performed out of bound.

And, of course, it’s not aiming on being so bulletproof that having all the money in the world would not be enough to overcome it. It’s just to much of an effort and, after all, there are easier targets out there, so why bother.

On the other side though, it’s an additional burden for a user, so, I think what is most important here, is to know when to apply this kind of a control and when it’s too much.

Always wanted to play an information security auditor? Here is your chance. For now all of it is in Polish, but guys promise that the competition will be held both in Polish and English. Hope they will come up with an English version of the site soon.

A short answer to WTFs: first there is an internet round, lasts five days and if you perform well enough in this stage (no idea what are the criteria, but hope we’ll find out soon), you go to Katowice and play the hard ball with the best.

Although it’s not entirely clear what the competition is actually about, it’s said that one needs to show agility in either web apps security or ISO/IEC 17799/27001 compliance (or both, of course).

Just letting you know — it may prove worthwhile to see what comes out of it…

How often do you happen to meet up via a phone? I did quite a lot of late — normal thing — you call a virtual conference room number, type in a preset password and start falling asleep while someone tries to bore you to death with their ramblings. This lasts like for ever… you switch your ears when receiver-induced pain starts getting unbearable… play whatever flash game is your favourite with one hand or type a short email to a friend putting a receiver between your had and your shoulder… yawn… try to not saw the wood and subconsciously scan the conversation trying to catch your name. Bored to death you occasionally mimic line-induced cracking sounds and ask other participants to repeat themselves and refuse to go any further before every word gets to you. Sounds familiar? Very likely, as this is what we do — we communicate.

But. When did the password to the phone conference room change last time? And how about a phone number? Is it by any chance a shared number that your whole team uses and to which everyone can dial in, provided they know the number and the never-changing password?

Riiiight. And how often does someone dial in mistakenly and it turns out they’re not at the conference they intended to, not at the right time, or not the same time zone? Imagine that, for a change, some serious matter is discussed, confidential maybe. Picture the situation when the discussion is so super-important that someone actually intends to eavesdrop on it. Would it be possible at your environment? How much of the effort would it take to get into such conference unnoticed? Wiretapping exec’s conference this way is not that easy and leaves trails, sure. But the key point here is that it’s usually not that difficult for an insider, as we would like it to be.

Of course, again, we trade the security for the convenience and usability here. Agreed that changing a password per conference might be a pain in the neck, but it’s good to at least know how this impacts security of the conference and be able to elevate security level whenever necessary.

It’s always your choice, but it’s best when it’s a good choice.

About two months ago FBI announced that they have charged or arrested three, as they like to call them, bot-herders. They are accused of being in control of botnets, infecting user PCs, sending spam, and issuing DDoS attacks. We’ll see what comes out of it and if they are found guilty or not, but what’s interesting about it, is how did the FBI get to them in the first place?

The traditional way of commandeering the botnet is to have all bots to connect to an IRC channel and to issue commands to this channel. The main idea behind it is that it allows all the bots to listen without a herder directly connecting to them. Also, the tricky part hear is that it’s nearly impossible to tell the master and the puppets apart, before the commands are issued (i.e. when bots are just reporting whatever they have to report).

On the other hand, when commands are being issued, it gets fairly clear who is the actual boss. It may take a lot of effort to reverse engineer the code of the bot, but it’s doable and one may finally work out which machine on the IRC channel is giving orders.

But. Knowing which user it is, does not necessarily give us much in terms of who the person really is. There is like a gazillion ideas about how to anonymise yourself in the net, especially when you control like a couple of thousands of hosts (or hundreds of thousands as it appears to be the case sometimes). You can bounce the communication back and forth, make it appear to originate from innocent hosts, when possible communicate using connectionless protocols spoofing IPs, making sure the communication goes through many different countries (hostile to each other preferably) and so on. Like you name it, the list goes on and on. And once you commandeer a botnet all of it is pretty easy to do.

And I didn’t even mention the easiest possible solution. Nearly free as in money and effort, wrapped in a nice shiny cellophane and home delivered — TOR (The Onion Routing).

The idea behind the TOR is to allow average users to maintain a reasonable level of anonymity when surfing the web and performing other privacy-sensitive operations on the net. Like, well, say ircing, as there are IRC networks trying to provide normal access for the torified clients.

OK, it may not give a military-grade privacy, but sure enough adds to anonymity and would make it harder to track a bot-herder down. So, something to think about — is it more likely that FBI have gone beyond anonymity improving solution like this, or maybe it’s that they’ve caught these guys, because they didn’t take care about enough anonymity when issuing commands to their botnets.

I guess we’ll find out soon enough.