(Distributed) Denial of Service attacks, intentional or otherwise.

So, I have been away for a bit and thus the lack of posting. So to make that up, there will be two posts today and at least one more this week. Right, lets get into its shall we? Today's topic is (Distributed) Denial of Service attacks and how they can be inadvertently caused. So, first off, what exactly is is a Denial of Service (DoS) and indeed a Distributed Denial of Service (DDoS) attack.

A Denial of Service (DoS) attack involves sending an excessive amounts of data/requests/pings to a server with the aim of overloading the server so that legitimate users can not access the server. Imagine the following scenario: there is an office with an information counter. Normally, people would walk up tot he counter, get the information they need and then leave. After this the next person does the same and so on and so forth. A DoS would essentially be one person standing at the counter and asking so many questions that nobody else can get up to the counter.

A Distributed DoS (DDoS) is the same thing, except with one minor difference. In a standard DoS, there is only one attacker and one attacking system. In a DDoS, there may still be one attacker, but there are several systems that involved in the attack. For all intents and purposes, DoS attacks really only exist in textbooks, so we will only consider DDoS attacks.

So, now that we know what DDoS attacks are, let's look at how they happen. The normal scenario is that our attacker(s) pick a target and then bombard them with request. At a technical level, there are several ways to this in an intelligent ways, but the simplest is just overwhelming the server with requests. I would rather not get into the details, because to be quite honest, I find them inane and boring. SO, let's just say there are many ways of doing it.

Now, if you recall I did say we were going to discuss how one may inadvertently perform a DDoS. First off, we need to realise that different websites require different levels of hardware. Right at the top you have the likes of Google, who require server farms of sizes that are difficult to fathom. Then you go down to the bottom, where you have tiny websites that get a couple of hits a week, which probably run on a single machine. Obviously, the smaller the server, the easier it is to DDoS.Now, the unintentional DDoS attacks happen to theses smaller sites. How you ask? Well simple, they get very popular, very fast.

There a few ways you can achieve this. Firstly, start off a small website and then becomes popular. Then when you post new content, number of people accessing your site goes through the roof and your site becomes temporarily unavailable. Don't think this is possible? I refer you to a delightful webcomic (in a manner of speaking) The Oatmeal, run by Matthew Inman. He even says something about it on his Facebook page. He does somewhat DDoS himself, by being awesome!

Another way is best explained by using Stephen Fry as an example. Stephen had built up quite a fan base as an entertainer and television personality over the years, so when he ended up in Twitter, well naturally he had a smattering of followers (myself included). He is quite an avid user and apart from the usual tweets of his current activities (and of course his tweets for charity), he does tweet links to amusing content from time to time. The moment that tweet hits the net, there are thousands of people clicking that link and well it has caused more that one site to go down.

As we can see in both cases, neither party had any malicious intent towards the sites that they inadvertently DDoS'ed, but it did happen. The unfortunate part of this is that there is no way to defend against it. Well, there is the no practical way to defend against it. Of course, everybody could use industrial size server farms, but that is not really practical. There may be some sort of gains made if everything was hosted in the cloud, but I'm not sure how feasible that is.

Password Lockers Part 2

So, this is becoming a trend, well two trends: follow-up posts and data breaches. As you may or may not know, there was a MASSIVE breach involving Sony Entertainment, specifically the Playstation, but more on that later. More the the point you may recall my previous post on password lockers etc. Well, this post is about what can go wrong with a password locker.

LastPass is a company that provides a password locker service. What you do is register and download their software. Your master password, which unlocks the locker is then stored there. Now it recently came to light that some of these passwords were compromised (or not). Well, LastPast, if you are reading this, have a gander over here for a sec, k? We assume, hypothetically, that the master passwords were compromised (mainly because I have already written out most of this post and I'm kinda lazy). LastPass issues a warning to all its users to change their master passwords and they all do. Their servers could not handle the load and so they had to restrict the number of users allowed to change their passwords. This actually happened before they announced they were not hacked.

Well, I would like to say that I am somewhat impressed by the expediency with which the users tried to change their passwords. I am also impressed by LastPass's inability to deal with the situation. Agreed, that they had issues dealing with the load but according to their blog they have put affected accounts in "lock-down" mode. Kudos to you.

After all of this, LastPass then claimed they were not hacked. It seems that they just broken their system. After users changed the master passwords, they were met with garbage characters, random images and occasionally the deep dark void of nothing. Somewhere somebody thought that implied a hack. And that brings us to today's lesson.

When you think you have been breached, DO NOT PANIC! Check, re-check, double-check and confirm that there has been a breach. Immediately put in place counter-measures and check for other possible backdoors opened by this breach. Take a deep breath. Notify the affected users as required by law and/or company policy. If you follow these steps properly, then there should be no need to ever retract a security warning. Issuing a security warning scares people, retracting it causes doubt. We are trying to bring digital security out of the realm of FUD (Fear, Uncertainty, Doubt)!

Irony thou name is SQL injection

As I clicked on my slashdot bookmark, I for some reason said to my browser "Please give me something juicy" and it did not disappoint. It gave me this article. The sheer irony alone made me chuckle for 2-3 minutes. So, meine Damen und Herren, (I just had to throw a little German in there) let's talk about SQL injections. I promise this won't hurt (much)!


So, to understand a SQL injection, we need to understand SQL. To understand SQL, we need to know what a database is. And that's where we will start. This may be a bit round about, because to frank I find databases to be a dull and boring topic. We start at the bottom, with data elements. Now a data element is a single piece of data about an entity e.g. Name, Gender, Age, Favourite Star Wars Character and so on. A record is all the specific data elements about a specific entity e.g. {Saqib A Kakvi, Male, 23, Yoda} would be a record about me. If we have several such records stored as rows, we get a table. If we have more tables (generally related) we now have a database. In summary: A database is a collection of tables, which in turn is a collection of records, which in turn are a set of data elements.

Agreed, it's all fine and dandy having all this data nicely stored, but how do we access specific parts of it? The answer is Structured Query Language or SQL (sometimes pronounced 'sequel') for short. SQL is basically a language that allows us to get a section of a database based on some criteria e.g. all the records of people who are over the age of 30. Although SQL gives you quite a lot of lean room, it is strongly typed, which means that all SQL statements must have a very specific form, syntax and all the right symbols in all the right places.


And this brings us to SQL injection. A SQL injection exploits the srong-typing of SQL and issues malformed statements which cause the SQL interpreter to go a little bit bonkers and produce some crazy result. By taking very, for lack of a better phrase, well-formed malformed queries, an attacker can recover parts of (and even all of) the database. When implementing a database, one must ensure that any and all malformed queries are rejected, thus making SQL injections irrelevant. 


MySQL is a software that helps you implement, run and maintain a database (known as a Relation DataBase Management System {RDBMS}). The MySQL company seems to have forgotten about this vulnerability in a primary part of their system. As we have seen, MySQL (and apparently sun.com) have been so ironically compromised due to a SQL vulnerability. Well who would have thought it?


ME! ME! ME! Well, actually the thought had crossed my mind a few times and I thought it was funny, but sincerely hoped that it would never happen. Well done world, you continue to surprise me.