LibriumArcana.Games

I wrote up this giant post for a web hosting forum of which I am a member, but since it took all bloody day for me to type, I figure I will post it here too, for good measure.

Common attacks and their defenses

Here, I will explain a number of common attacks, how and why they work, the threat level and how you can defend against them, both as a programmer and as a user.

Denial of Service
A denial of service attack, like its name implies, is one where the attacker wishes to hurt you by not allowing you, or your users, to use your computer or website. It comes in many flavours. Here, I will focus only on ones against web services, though it is also possible to suffer a denial of service attack on your home computer too.

Here are some common types of denial of service attacks.

• DDoS: distributed denial of service attack. This is when multiple people across the internet all access or attack your service at once to eat up all your bandwidth or connection limits.
  
  How it works: someone decided it is time to attack you, and gets many other people involved. Each of them then start eating your resources. The simplest way of them to do this is all refresh your page at once, over and over again.
  
  Why it works: Every server on the Internet has limited resources. They can only upload so much data at once (bandwidth), they can only transfer so much data a month (often called bandwidth as well, but this is not entirely an accurate usage of the word), and can only handle so many connections at once. The connection limit is imposed by many factors: the amount of RAM and the speed of the server, amount a user is allowed to use on a shared server, and ultimatly, the number of entries in the server's operating system's process table. Also, entries in the server's configuration file can limit the number of connections at once (often used to help performance).
  
  When many users all hit it at once, it quickly fills up these limits, and when it is full, it rejects any new connections, or worse yet, handles all of them very slowly. If the monthly bandwidth is exceeded, your host will probably take your website down for a few days or more, or worse yet, charge you huge fees for going over!
  
  How can I stop it?: The nasty part about a DDoS attack is you really can't stop it. It comes from so many directions all at once and just overwhelms you. There are some steps in helping to limit it though:
  
  1. As a server administrator, you might be able to make some changes to handle a heavier load. Try changing your keep-alive time in your config to a smaller number, like usually 3-4 seconds will be plenty instead of the default 15 (for Apache). This has some drawbacks though, so read your server manual before proceeding.
  2. As a server administrator, you might be able to buy a more powerful server or more bandwidth, which can handle more users at once. This is costly though, and not a real defence.
  Threat level: LOW. If it is easy for individuals to do and hard to defend, why is it a low threat level? Because it takes many, many users at once to attack you to be effective. This takes coordination and planning, and isn't going to happen to most people. Though, keep in mind these attacks are sometimes accidental, for example the Slashdot effect, where a link on a popular site sends many users at once. Still, this doesn't happen often enough to worry about for most people.
• SYN Storm DoS attack: This is when a user floods your server with TCP SYN packets, without actually forming a connection.
  
  How it works: Someone decided to attack you, and either wrote his own tool or downloaded someone else's to flood your server so it cannot make more connections.
  
  Why it works: The way TCP connections work is first the one initating the connection sends a SYN packet to the server. The server adds this to it's pending connection table, and sends back a SYN/ACK packet. At this point, to finalise the connection, the connector is supposed send a final ACK packet, which confirms 2 way communication is possible. The server will wait for a time out time to pass for this ACK packet to come, and if it doesn't come for this time, it deletes the entry from the pending connection table, and carry on with its own business. If it receives too many SYN packets without the ACK response before this time out elapses, its connection pending table can get full, meaning legitimate connections will be refused.
  
  How can I stop it?: Again, you can't do much. There is only one possibility if you are the OS admin: turn down the amount of time a connection will wait on the table before being deleted. This has a drawback on slow networks of not waiting long enough for the response to get back to it if it is turned too low. Many operating systems now have a smaller number by default to help limit the potential of attack. Firewalling is not feasable to defend this because the IP source header in the packet can be forged for this attack.
  
  Threat level: LOW. Again it is pretty easy to do and hard to defend against, but even a successful one can only block you out for the duration of the storm plus a few seconds (the time it takes for the table to time out and clear itself). It can't do any serious damage.
• Bandwidth overflow attack: this is when an attacker with more bandwidth than you tries to use his muscle to waste all yours. It is like a small scale DDoS.
  
  How it works: A malicious user repeatidly hits your website, transferring many large bandwidth files over and over again.
  
  Why it works: As I said on the DDoS section, websites have limited bandwidth. If someone keeps hitting you, especially if he has more transfer potential than you, he can waste away your whole allotment, meaning no one else can get to your site.
  
  How to defend against it: Since, unlike a DDoS attack, this is only coming from one user, you can just firewall / block him and be done with it.
  
  Threat level: LOW It is easy to block, and often individuals don't want to waste their own bandwidth wasting yours, so this attack is rare.

That wraps up my discussion of Denial of Service attacks. There are many more than what I listed, but they all share most things in common with the above.


Direct Password attacks
A direct password attack is my term that I use to describe a category of attacks where the attacker directly tries to defeat password security on a system. The password is generally the second weakest part of a security system (the first being the user himself), and is often attacked directly. Some systems, such as SSH, allow you to not use passwords, instead using cryptographic and host based defences, which are almost always a better system, but those are beyond the scope of this post. There are a couple variations of these attacks that I will talk about in detail.

• Brute force attacks on the server: these are where the attacker will try massive amounts of password variations hoping he will get the right one.
  
  How it works: An attacker has a program that feeds all possible passwords to your log-in form, hoping he will get lucky.
  
  Why it works: There are a finite number of possibilities; if you try them all, you will eventually find it, it might just take a long long time.
  
  How can I stop it?: As a user: use long passwords. The longer it is, the more time it will take to break by brute force. As a programmer: insert forced delays and timed lock outs in your log-in scripts. If you, for example, require 3 seconds between every log-in attempt, that makes brute forcing almost impossible. Also, temporarily locking an account after a number of failed attempts is a good idea. For example, after 5 log-in failures, the account is locked for 15 minutes (or an administrator unlocks it).
  
  Threat level: LOW. It is easy to defend against, and takes massive amounts of time to try all the variations. It is almost never tried because the odds of success are very low; the dictionary attack, which I will explain shortly, is used far more often.
• Brute force attacks on the data: this is when an attacker has already compromised your password database, and is now attempting to determine passwords from this encrypted data.
  
  How it works: After the attacker has access to your password database (which he should not in the first place! If he has access, your security has all ready failed!), he may want to figure out what your passwords were in the first place. This information would be useful to him because all too often, people use the same password in multiple locations. He begins to brute force it on his own computer, or if the passwords are unencrypted, he simply reads them.
  
  Why it works: Once he has access to the data, encrypted or not, he can use all the computing resources available to him to attack it. There are no longer log-in delays or any other server side security, nor is there network latency to worry about. He can crunch the numbers non-stop for days if needed; he has all the time he wants.
  
  How can I stop it?: Use strong passwords, always. Also use different passwords on different sites, so even if he succeeds, he will have learned nothing useful. As a site admin, you will want to keep your password database in a safe place: only you should be able to access it. Be sure the permissions are very restrictive on the file or table in the database. Also, encrypt your passwords in the database with a one way algorithm, possibly adding a salt for added security. I personally use the MD5 Message Digest Algorithm, by RSA Data Security, Inc. to hash my saved passwords. This is simple because it is easily available. In PHP, do something like this:
  
  [php]
  $password = md5($what_used_entered);
  
  /* save the password to the database */
  mysql_query("INSERT INTO users_table (password) VALUES ('$password')");
  
  /* or to compare to the password in the database */
  mysql_query("SELECT user FROM users_table WHERE password = '$password'");
  [/php]
  
  Always discard the plain text password in favour of the hash. This makes it so an attacker would indeed have to spend hours or even days crunching numbers to get each password from the database, even after he has acquired full access to it.
  
  Threat Level: LOW since the attacker needs full access to your database and many hours to extract anything if you take the simple step of hashing, this is of a very low threat. However, once an attacker has this level of access, you are probably all ready compromised.
• Dictionary attacks: This is very similar to a brute force attack, but instead of trying all possibilities, the attacker tries a list of common passwords instead (like words in a dictionary; hence the name).
  
  How it works: An attacker has a program that feeds common passwords to your log-in form, hoping he will get lucky.
  
  Why it works: Often users pick passwords that are easy to remember, and since words are easier to remember than random strings of symbols, they use words. The attacker, using statistics on what words are most common, uses these words to attack. This is the most common type of password attack.
  
  How can I stop it?: As a user: use passwords that are more than just simple words. Add numbers, symbols, spaces and capital letters to it. A password of even "Password 2006" is much better than simply "password", and is much less likely to be broken. However, clever attackers will realise tricks like this too; you should try to add numbers, symbols, and capitals to the middle of the password rather than just on the end. "20 PaSsWoRd 06" is a far better password than "Password 2006" and that will probably never be broken by a dictionary attack. See the thread on "Dynamic Passwords" in this forum for some more tips on making a strong password.
  As a programmer, the same steps taken to prevent brute force attacks will also be very effective on preventing dictionary attacks.
  
  Threat level: MEDIUM. It is pretty easy to defend against, but with a larger number of users, it becomes more and more likely that one of them will use a weak password. And with how common these types of attacks are, you will probably be hit with it at least once. It is a threat to be taken seriously.
• Intelligent guess attacks: This is where an attacker takes something he knows about you to try and guess your password. Sometimes the thing he knows about you is something simple, like you are the administrator, so he tries the password "admin" first. When combined with a dictionary attack, this can be brutal.
  
  How it works: The attacker, usually someone who knows you personally, but not always, tries to learn about you and guess what you would use as your password. Once he has some ideas, he simply tries them.
  
  Why it works: Many people use things close to them as a password because it is easier for them to remember. Something like their kid's birthday or wife's name are very common. Figuring out this information is often not very hard for an attacker.
  
  How can I stop it?: Use a strong password that is not necessarily easy to guess, and don't tell anyone what it is or what system you used to make it. See the thread on "Dynamic Passwords" in this forum for some more tips on making a strong password.
  
  Threat level: MEDIUM: the attacker has to know something about you and needs to target you specifically to make an intelligent guess, but that is getting easier and easier with the Internet, so I give this a medium rating.

Social Engineering
Social engineering attacks, unlike direct password attacks, don't target the computer directly; they instead target the people. In security systems, the people are usually the weakest link. A study was done in 2004 in Great Britain that showed that over 70% of office workers questioned were willing to give away their passwords to someone who asked.[1] The number gets even worse when tricks are used. I will be explaining some common tricks attackers use to try to gain access to your system.

• Fake official looking emails: by far the most common variation are forged emails claiming to require your password or other information.
  
  How it works: The attacker forges an email from an institution claiming to require important information from you, and either expects you to email it back, or sets up a fake website to receive your information (see Man in the Middle attacks below). These emails claim to need your password to verify your account, or something along those lines. Some attackers will go for other information, like your social security number. Clever attackers might try to trick you into giving away information that seems harmless, but is actually useful for him to guess your password (see intelligent password guessing section above)(or some other scheme).
  
  Why it works: Forging the from header in an email is very easy to do. The protocol that governs email, SMTP, was written in an earlier time and never had security in mind. Also, since most emails are not encrypted, there is no way to be sure it came from who it says.
  
  How can I stop it?: NEVER give out important information over email. It can be read by others, because it is not encrypted (see Sniffing below), and you can not trust the source. Remember that companies or sites will not be contacting you asking for your information: the most they will do is send you a message saying you should get back in contact with them. If this happens, don't click on links in email: manually type the URL of the site you want yourself. If an email asks for your information, it is probably fake.
  
  If you are wondering how to stop people from faking mails from you, what you should do is digitally sign every mail you send. There are Free Software solutions, like GNU Privacy Guard, that can do this for you. They can forge the from header, but they cannot forge your digital signature.
  
  Threat level: MEDIUM. It is easy for the attacker to do, and human nature is generally pretty trusting, so if you aren't paying attention, you might fall for it and lose your password, or worse yet, fall victim to identity theft. Luckily, if you do pay attention and follow my tips here, you should have nothing to worry about.
• Fake, official looking websites: see below for the Man in the Middle section, where I address this.
• Instant Message tricks: Email isn't the only way someone can try to pose as someone getting you to go to a malicious website or give up important information. While faking the screen name of someone you know is harder to do, it is not impossible to break it. Also, if you get a message from someone you don't know, always be weary.
  
  How it works: Most IM attacks are done by automatic bots, and sometimes these bots will infect a real person's screen name and go down his buddy list trying to also infect his friends. This is how most IM viruses work.
  
  Why it works: The user gets a link from someone he knows, and assumes it is safe, and therefore follows it. In reality, it was a IM hijacked by a virus and the link is how it propagates.
  
  How can I stop it?: First, never follow a link from someone you don't know. Second, before following a link from someone you do know, check where the link leads. If it goes to a .com or a .exe, it is probably not safe, and you should not follow it. Third, if you think it looks suspicious, ask for confirmation from the other person. If it can carry out a meaningful conversation, it is probably not a bot. Lastly, a preventitive measure would be believe it or not, always using proper grammar and spelling when IMing. Most bots mimic AOL speak, with poor spelling, grammar, and capitalisation. If you always use proper English, it will often rub off on your friends, and then when you get a message that does not use proper language, it will set off warning bells instantly.
  
  Threat level: LOW. IM viruses, while common, are easy to spot and don't do that much damage, even if you do fall for it.
• Forum posts: remember anyone can post to a forum, so don't take it seriously. Also be careful about following links other people post; it might be to a malware site. Same caution you should take for IM problems, listed above.

Sniffing and Man in the Middle Attacks
A man in the middle attack is when the attacker actively puts his computer between your's and the destination. (not physically, but in the line of the data) From this position, he can see all traffic between you and the destination, including passwords, web sites, or even credit card numbers. Sniffing is when he sits close to your path on the network, passively listening to all your traffic. I will explain both active and passive listening here as two separate concepts.

• Passive sniffing: this is where he simply listens to your traffic, not altering or communicating with your computer or your data in any way.
  
  How it works: The attacker is on the same network segment as you or the data path, and he sets his computer to view all data, instead of just the data addressed to him. As the data flies by, he can decode the protocols and see all your communication.
  
  Why it works: On an Ethernet network, when data is sent down the wire, it goes to all computers connected on that segment. Normally, the computers have their own address, and when the data arrives, it checks the destination address of the packet. If it is not for you, it discards it. But, it is easy to switch a network interface to "promiscuous mode", where it keeps all data, even that not addressed to you.
  
  By network segment, I mean up until the next switch on the network. Switches take the data, look at the destination MAC address on the Ethernet header, and send it down the correct wire to get there, instead of down all wires, like an Ethernet hub does. However, it is still easy to trick a switch into sending the data down the wrong wire, with a technique called ARP poisoning. I will not explain the details of how that works here, but take my word for it that it is easy and works.
  
  Your data on the Internet potentially goes through hundreds or thousands of computers before it gets to its destination and any one of those could listen in.
  
  How can I stop it?: You cannot stop him from listening, but you can stop him from getting anything useful out of it. If you are going to be transmitting important or sensitive information, make sure it is always encrypted. Encrypted websites have a https: prefix, instead of normal http:. Your browser also usually gives a visual cue: Internet Explorer displays a little lock in the corner, and Firefox displays the address bar in the colour yellow. If it is not https, don't send anything important, like a credit card number, over it. Keep in mind that email is by default never encrypted, so don't send important information over email unless you encrypt it yourself.
  
  Also remember that if being HTTPS means that the people listening can't get anything useful out of it, but you still need to trust the destination website. More on this in the next section.
  
  As a web master, if you want your users to be able to safely send sensitive data to you, should set up SSL and get a certificate digitally signed by one of the authoritative companies. Some of these include Verisign, Inc., RSA Data Security, Inc., and others. They are somewhat costly, but your user's privacy is worth it.
  
  Threat level: HIGH. This is easy to do and you cannot stop it. The attacker need not even target you, he just sees it all looking for something interesting. That is why https and other forms of encryption for sensitive data is so very important.
• Active man-in-the-middle: In an active man in the middle attack, an attacker sets his machine to be right in the middle of your datastream. You actually send the data to him, and he can then do whatever he wants with it, including forwarding it to the real destination and also seeing the response. He could also just send back a fake response and trick you even further.
  
  How does it work: The attacker sets up a website that is a copy of the real site, and redirects you to his site instead of the real thing. Sometimes you can tell it is a fake site by looking in the address bar, but more sophisticated attacks can also hide that. Usually the part of the website that is copied is a log-in form. That way, when you fill in your user name and password, the attacker receives it, keeps a copy, then forwards you to the real site hoping you never notice he was there. With HTTPS websites, he can also forge the encryption, so he can see even encrypted data. Luckily, the HTTPS system has a way to spot this.
  
  Why does it work: Often users use simple pattern recognition to know they are on the correct website. If it looks close enough to the real thing, they will trust it without necessarily checking the address. Links to the fake site are usually covered up, so they appear to go to the real thing ( <a href="fake site address">real site address</a> ). For HTTPS websites, remember that the end points of an encrypted conversation can still see the whole thing. The attacker in this scenario would set himself to be an end point on both ends ("cut the line" and attached both ends to himself in the middle). He can use tools to forge a real looking secure certificate to trick the user into trusting him. This doesn't happen as often as simple tricks, for two reasons: one is it is harder to do, the second is it is easier to spot, if you know what you are looking for.
  
  For more sophisticated attacks, he might also poison your DNS data so the URL of the real site points to his server instead of the real thing. This is less common though, because it is harder to do.
  
  How can I stop it?: Before following a link, hover the mouse over it and look down on the status bar to see if it leads where you think it should. This is not enough though, because that can be spoofed with Javascript, so before you actually type anything into the forms, look up at the address bar, and make sure you are indeed at the right site.
  
  Now, about encryption: all https websites have a certificate that is digitally signed by a known third party to prove that you are indeed talking to the right server. Forging a digital signature is not possible (well, maybe it is, but it is so extremely hard to do, even for experts, that you don't have to worry about it). If a certificate is not signed by a known authority, your browser will pop up a warning. It will tell you that the signature does not match a known authority. If this warning comes up, do NOT send sensitive information to this website: you can't be sure that you are talking to the real thing and not an attacker. It is true that some websites will pop up this warning all the time: that is because the webmaster didn't pay for a proper certificate. However, if it does it all the time, there is no way to know for sure you are talking to the real thing.
  
  Bottom line: if the certificate warning comes up, don't trust the site with anything important. And, as a web master, you should keep this in mind too: get a certificate from a known authority if you are going to be accepting sensitive information.
  
  
  Threat level: MEDIUM. This attack takes an amount of skill and preparation to carry out, but if it is successful, he has gained a significant advantage over you and your information. Luckily, they are usually not too hard to spot, and if you follow the defences I suggested though, you should be pretty safe.

Injection Attacks
An injection attack is where a skilled attacker takes advantage of a programming mistake in the system to inject his own code to take control. These usually take more technical skill than most attacks, and are therefore rarer, but should never be discounted, as they are among the most dangerous attacks possible, and it only takes one skilled attacker willing to share his tools with the script-kiddies before it may become commonplace.

Here, I will explain two common types of injection attacks: SQL injections, common on web forms and something EVERY web programmer should take very seriously, and overflow exploits, often used against programmes written in languages like C which allow arrays to be overwritten out of bounds.

• SQL injection attack: this is where an attacker feeds specially crafted data through a form to access parts of your database he shouldn't have access to.
  
  How it works: The attacker usually writes a script to attack a known vunerability in a web application. This script feeds a specially crafted string to the form, which changes the result of the SQL query.
  
  Why it works: When the programmer sends a string to the database, the data in encased in quotes. If he does not properly check and escape the input, the attacker can add extra quotes which allows sneak code in with the data to do whatever he wants.
  
  How can I stop it: As a user, make sure all your software is always kept up to date. When the software author releases a security patch, install it as soon as possible.
  
  As a programmer, ALWAYS ALWAYS escape all data that is going to be passed to a SQL query. If fact, you should perform checks on ALL data you use that might come from the user before using it. This includes GET, POST, and cookie variables. Even if you don't have a form on your page, if you access these variables without checking them, you are asking for trouble.
  
  As a server admin, make sure the register_globals option in PHP is turned OFF. When it is on, malicious attackers can forge data to overwrite important variables in the script, and it offers no real advantages to the programmer.
  
  PHP has some built in functions to do this for you.
  
  [php]
  $data = mysql_real_escape_string($_GET['data']);
  [/php]
  
  You should call the mysql_real_escape_string, and / or others like it on ALL data that will be passed to a SQL query. See the PHP website for more information.
  
  Threat level: HIGH This is the most common way a script is attacked on a website, and if successful, your database is compromised. Luckily, it can be prevented with some defensive coding. Always have the threat SQL injection in mind when working with a database.
• Overflow injection: This is when a malicious attacker exploits minor errors in a program to inject his own code, and get it to execute instead of what the program was supposed to execute. This is the most common type of exploit used in binary files.
  
  How it works: The attacker takes binary code and encodes it into data, then passes it along to the victim program, which is tricked into running it.
  
  Why it works: Buffers are placed in memory of the program. So are program variables, pointers, and, in the case of the stack, function return addresses. If the data being copied into the buffer is too big, it can overflow the buffer, and overwrite the other data, allowing the attacker to take over.
  
  How can I stop it?: As a user, always use the most up to date stable versions of software available. Patch as soon as possible when the author releases updates.
  
  As a programmer: ALWAYS check user input before using it. Check the size of the data, and ensure your buffer is long enough to fit it all. Use functions like strncmp instead of strcmp, etc. Never blindly copy data anywhere, and ensure strings are NULL terminated when they are supposed to be. Again, check the size before copying it!
  
  As a system administrator: you might want to look into getting patches for your kernel that disallow execution of code in any writable segment of memory; i.e. mark the stack and heap as non-executable.
  
  Threat level: HIGH. It takes considerable skill to discover and exploit these problems, but when it is found, it can lead to unlimited power for the attacker, and remember it takes only one skilled attacker to share his work before the script-kiddies start to use it. You MUST sanitize all user input in all programs, or you are being a negligent programmer, putting all your users at risk.

Common Conclusions
Here, I will simply list off tips that will always help keep you secure.

1. Always use strong passwords.
2. Never send sensitive data unencrypted over the Internet.
3. Never make a transaction or give personal information to someone who contacted you: always be the one contacting them so you know who it really is. Also applies to running programs: don't run it unless you got it yourself.
4. Always sanitize user input when writing a program.

Follow those four points, and you can prevent most security problems.



Lastly, I want to take a moment to put forth a few points, more political in nature. The people who break security are rarely hackers, and you shouldn't call them hackers. A hacker is an affectionate term for an expert in a system. Most the people who break security like this aren't experts at all: they are just immature children who take other people's work and cause mischief (script-kiddies). Real hackers have no respect for these script-kiddies, and do not appreciate being associated with them by having the word "hacker" misused. While it is true that many hackers are also security experts, they are very rarely malicious attackers. To paraphrase Richard Stallman[2], I have enough computers of my own to play with. I don't need yours. Please, when referring to security crackers, do not use the term 'hacker'.

The second point I want to make is if you ever think you want to break security or spam people, think again. There are strict Federal laws in the US, UK, and many other countries that come down hard on crackers and spammers. "My only crime was curiosity" doesn't fly in Federal court. Messing around with other people's data and websites isn't worth jail time. Don't do it. If you really want to play around with security, pick up a used computer at a garage sale and set up a network in your own home. Don't use other people's property for your own little games.


...wow, this ended up taking all day to write, being much longer than I thought it would be. At least I got to type it on vim. :-P Hope it is useful to someone. If anyone sees an error, disagrees with my threat levels, or has anything to comment or a method or detail to add, please do. And of course, if you would like more information on defending yourself, don't hesitate to use google or ask me here. But don't ask for help breaking someone else's security, that will only make me angry.

Footnotes:
[1] The Register reports on the password study
[2] ESR quotes Stallman in the Jargon File

One thing about the SQL Injection method - I used to think this was obselete, a cute trick everyone knows about that works nowhere(and it is indeed rare to find a place where these still work)....

Until I talked to a guy who'd managed to connect to the DB of a major newspaper out here using a "yell-at-secretary-for-a-server-name" trick and the lowest form of SQL Injection(the old add-an-always-true-condition-at-the-end crap). At. A. Major. Company.

So yeah, that one's a good example of something that'll be around for as long as incompetent coders are. Even barring security concerns, validating user input is basic.

EDIT: Oh, yeah. Anyone wants to try legal internet hacking, here ya go - http://www.hackthissite.org/