22 May 2011

A Rather Damning Indictment...

[Out of time constraints, I decided to publish this on Facebook on 16 May 2011. As I have a little more time, I'm copying the Note in its entirety over here...]

This morning, while I had a few spare minutes, I went ahead and set up a test based on one of the earlier labs I did in my Security+ class. This lab had to do with ARP spoofing (also known as ARP flooding), and the potential for damage it can cause.

What is ARP spoofing? Well, first, one needs to know a little about networks and ARP. ARP is the address resolution protocol. Simply put, it's the mechanism by where a particular computer knows exactly where it is on a network, as well as its neighbouring nodes. ARP maps a host to a particular computer's unique MAC address and each computer stores it in a table.

ARP spoofing, then, is where a malicious user (let's call this user/group Moriarty for simplicity) running a machine manages to insert himself on a given local area network (LAN) at a point where they are able to intercept packets coming from targeted/victimised hosts while said packets are en route to the router, and ultimately its destination on the Internet. Very often, there isn't a lot of noticeable detection for a casual user.

This can lead to several major attacks such as:

a.) data theft, such as website credentials or other equally-sensitive data being transmitted
b.) "man-in-the-middle", wherein Moriarty is able to inject or otherwise modify the data that is being transmitted
c.) internal denial-of-service (DoS), which represents loss of connectivity for its victims

The equipment I used in this simulation were both virtual machines:

1.) BackTrack 5 (KDE 32-bit), which is a Linux-based pentesting distribution currently based on Ubuntu 10.04 LTS and the current release.This was the "attacking" PC that was directly connected to the LAN at 10.14.252.26/22
2.) Windows Vista Enterprise with Service Pack 2, which represented the "victim" and on the same LAN segment, having an IPv4 address of 10.14.252.27/22

I used three sites in my test, where I have or have had accounts: Google's Gmail service, Windows Live, and OkCupid. Of the three, only Gmail explicitly used HTTPS encryption for its logins.

After configuring SSLdump and the appropriate IP commands (IPv4 forwarding and iptables), I went to the victim box and logged in successfully to each of the sites. On the attacking machine, the credentials were logged to a text file I called "secret."

Below is the entire output of the file called "secret", noting that I have removed my username and passwords by obscuring them with XXXXXXXX. They represent the username and password values captured, but do not necessarily indicate the length or other attributes of the collected data.


2011-05-12 10:03:52,714 SECURE POST Data (www.google.com):
ltmpl=default&ltmplcache=2&continue=http%3A%2F%2Fmail.google.com%2Fmail%2F%3Fhl%3Den%26tab%3Dwm&service=mail&rm=false&dsh=4968638006474660586&ltmpl=default&hl=en&ltmpl=default&scc=1&timeStmp=&secTok=&GALX=cQG6UqvY8rw&Email=XXXXXXXX&Passwd=XXXXXXXX&rmShown=1&signIn=Sign+in&asts=
2011-05-12 10:03:56,259 POST Data (mail.google.com):

2011-05-12 10:03:56,693 POST Data (mail.google.com):

2011-05-12 10:03:57,120 POST Data (mail.google.com):

2011-05-12 10:03:57,403 POST Data (mail.google.com):

2011-05-12 10:03:57,404 POST Data (mail.google.com):

2011-05-12 10:03:58,180 POST Data (mail.google.com):

2011-05-12 10:03:58,884 POST Data (mail.google.com):

2011-05-12 10:03:59,278 POST Data (mail.google.com):

2011-05-12 10:03:59,528 POST Data (mail.google.com):

2011-05-12 10:04:00,098 POST Data (mail.google.com):

2011-05-12 10:04:00,200 POST Data (mail.google.com):
count=0
2011-05-12 10:04:00,348 POST Data (mail.google.com):
count=7&ofs=0&req0_type=ns&req0_hasac=true&req0_chat=true&req0__sc=c&req1_type=r&req1__sc=c&req2_type=sg&req2__sc=c&req3_type=cr&req3__sc=c&req4_type=i&req4_time=2531&req4_evtype=&req4__sc=c&req5_type=ns&req5_hasac=true&req5_chat=true&req5__sc=c&req6_type=j&req6_jid=&req6_json=%5B%22mf%22%2C%22nf0%22%2C%220.0.0%22%2C1%2C%7B%22os%22%3A%22windows%22%2C%22clientver%22%3A1%7D%5D&req6__sc=c
2011-05-12 10:04:01,328 POST Data (mail.google.com):

2011-05-12 10:04:21,575 POST Data (login.live.com):
handler=1&login=XXXXXXXXX%40live.co.uk
2011-05-12 10:04:25,611 SECURE POST Data (login.live.com):
login=XXXXXXXX@live.co.uk&passwd=XXXXXXXX&type=11&LoginOptions=3&NewUser=1&MEST=&PPSX=PassportRN&PPFT=CZe5JkMkGaBy8wJ9Ik4q7gdiKzN*mOb0MJaorwNAo1D8wQ%21AoR3*t7rJ9JeYEGcpfBVM6xR0X49Ry5sjd8vHn9ObvnhTc3rH55ZLL4MoFNwsh6uAWuCHAFTEFe2sTiYbORuZce4c*BIqO4b1r9peXl1rgKRTMeM1Ih9c2VqPwmSO*cJ1kUV28tzZXNA3GAR8J22UpNidYHL3lNZtcrcMSJEE*MYS&idsbho=1&PwdPad=&sso=&i1=&i2=1&i3=14094&i4=&i12=1
2011-05-12 10:04:30,546 POST Data (ocsp.verisign.com):
0Q0O0M0K0I0     +
2011-05-12 10:04:44,810 POST Data (www.okcupid.com):
ms=93&rand=0.3788016390015945&file=http%3A%2F%2Fincludes.okccdn.com%2Fautocore.js%3Ftier_hash%3D53072bbd%26files%3D0%2C1%2C3%2C4%2C5%2C6%2C7%2C9%2C26%2C28%2C29%2C31%2C32%2C36%2C37%2C89
2011-05-12 10:04:50,087 SECURE POST Data (www.okcupid.com):
username=XXXXXXXX&password=XXXXXXXX&dest=%2F%3F
2011-05-12 10:04:52,271 POST Data (www.okcupid.com):
base=1&page=Home&pageurl=%2Fhome&cachebust=602867&authid=1%2C0%2C1305645164%2C0x785ba94b7163e3a1%3B7b00305782a74e53ec5121c682aad8532f0b9bfa&format=background
2011-05-12 10:04:53,638 POST Data (www.okcupid.com):
ms=390&rand=0.44930431183089436&file=http%3A%2F%2Fincludes.okccdn.com%2Fautocore.js%3Ftier_hash%3D53072bbd%26files%3D2%2C8%2C10%2C12%2C17%2C23%2C24%2C30%2C34%2C38%2C42%2C66
2011-05-12 10:05:04,644 POST Data (www.okcupid.com):
base=1&format=logout_req&authid=1%2C0%2C1305645177%2C0x785ba94b7163e3a1%3B7c261cd7b12e8681fdef3a35617133133881f548
2011-05-12 10:05:06,472 POST Data (www.okcupid.com):
ms=109&rand=0.863012380335322&file=http%3A%2F%2Fincludes.okccdn.com%2Fautocore.js%3Ftier_hash%3D53072bbd%26files%3D69

I have some recommendations, such as wider support for true multi-factor authentication (such as incorporating secured tokens using a strong cypher, biometrics, or using one-time PIN codes) for signon to these sites. Already there are some banks and even the popular World of Warcraft game series implement these as security measures. The questions remains: what is stopping sites like Facebook, Windows Live, Gmail, the plethora of "dating" sites, and others that contain much of our personal (and perhaps outrightly intimate) data from going these routes? Is not increasing security for users a good thing?

No comments:

Post a Comment