Website Security Paper

Instructor:
Class: CMGT/441

On June 19 2013 the popular social media website LinkedIn had a DNS hijack which affected all users of the website. According to “Tech Crunch” (2013), ‘’Shortly after the outage began, App.net co-founder Bryan Berg wrote on his blog that the site’s DNS may have been hijacked–in other words, its domain name was redirected to a different IP address”. Often this is the result of an attacker compromising the account used to manage DNS servers. One of the many flaws in LinkedIn’s security design is lacking SSL which means that if you visiting the website while the hack was occurring the cookies would have been sent over the network wire in plain text format and the hijackers would now have access to the payload data. SSL should be used anywhere where communicating information that should not be public. It is a very dangerous assumption to believe that no-one is listening to traffic between user’s computers and the remote server the hackers or black hats do not need direct access to the router it’s a simply listening of the network traffic and the information can be readily available. Without using SSL for sensitive communications, a single machine with a virus on a coworker’s computer is all that is needed for stealing the information of a network and then the compromises truly begin to happen. The availability of an authentication session cookie in an unencrypted form would allow an attacker to gain full access to a user's account, presenting the opportunity to modify information and setting, as well as exposing the user's network contacts to phishing and social engineering exploits.
The hijackers also had a redirection of the payload to a server hosted by confluence networks according to “Tech Crunch” (2013), ‘’ A spokesman reached at confluence-networks.com’s India number said that they are investigating why LinkedIn and Fidelity.com’s (see update below) name servers have been redirected to their Web site. This event has happened after the password security breach that linked in had their database stolen with a lot of password information the difference is that when the first hack happened the password were encrypted and usually when encrypted passwords get stolen then a brute force needs to specifically decrypt all the passwords. This is what happened when a password is stored in a database the password is then stored as a hashed version to make it harder to read in plain text. Additionally salting adds a string to the password before its hashed to make brute forcing the hash harder. So for example instead of saving the hashed version of the password ‘P@ssword’ in the database one could additionally add to the string ‘salty’ to the end in that case you would have a password in plaintext that would read ‘P@ssword2salty’ to the database This is only true however if the salt is unknown. Most of the time if an attacker has access to the database they will have the salt too. In order to get around this and good security practice would be using individual salt for each person. This way an attacker would need to brute force each user's password individually since each row would have different salt. This is only true when a database has been compromised of its data but keeping in mind that DNS dumping with no SSL provided the hijackers will provide the cookies from the users in plaintext format.
Lastly DNS cache poisoning is among the most disturbing forms of network attack, undermining the very foundation of trust upon which the Internet is built in According to "Network World" (2008), "With cache poisoning an attacker attempts to insert a fake address record for an Internet domain into the DNS. If the server accepts the fake record, the cache is poisoned and subsequent requests for the address of the domain are answered with the address of a server controlled by the attacker”. By injecting false addressing data into DNS resolvers, attackers can siphon user traffic away from legitimate websites and e-mail inboxes to their own servers. What's worse, a well-executed cache poisoning attack would leave few clues to its existence. If possible, users can seek providers that offer multi-factor authentication, offer one-time password tokens, and have lock-out systems in place to prevent script attacks. It should go without saying that passwords should never be stored in clear text, either in the enterprise or service provider. In conclusion Linkedin should have used SSL in its DNS to at least protect these type of attacks from happening in addition it should have encrypted and salted all user passwords with individual salting and not just general salting as stated by tech crunch they would have avoided this whole calamity and reputation on the internet is possibly the most significant since most websites lose credibility are the ones that are forgotten. The diagram below best illustrates the way an attack happens

References
Tech Crunch. (2013). Retrieved from http://techcrunch.com/2013/06/19/linkedin-outage-due-to-possible-dns-hijacking/ IPA. (2008). Diagram Retrieved from http://www.ipa.go.jp/security/english/vuln/200812_DNS_en.html

Network World. (2008). Retrieved from http://www.networkworld.com/news/tech/2008/102008-tech-update.html