Situational Awareness

One of the best defenses against phishing, scamming or pretty much any other type of social engineering attack is to be aware of your situation and what to expect to have happen as well as to know when it should happen. The various attacks that come along should all raise red flags at several steps in the process. In the real world, we get this through millions of years of survival training -- those who didn't sense trouble usually died out before they could reproduce.

However, in the internet world, most of the visual and/or aural queues that raise your sense of awareness and caution are missing and we need to learn a new set of such protection mechanisms.

To that end, I'm going to periodically talk through an attack and point out things that one might notice which should cause you to think twice about continuing (or at least do a much more detailed check of whats going on before you continue).

Today, I received an interesting email reportedly from "Classmates.com" (which, of course, we all know we can't trust as anyone can claim to be anyone else with current mailing technologies):

Your Classmates Events: Reunion January 16th 2009 " With pride and joy we invite you to share a special day in our lives and join us for the Class Reunion on Friday, January 16th 2009. Bring the gang from Our High School back together again! Great party - from start to finish! " Proceed to view details: http://video.classmates.completeserv.user-v5mn1ckah.newyearclassmates.com/messages.htm?/type/INVITATION=m5kibxmz390kynf Your favorite people are already here, so use ClassmatesTM to bring them together. With best regards, Carmine Hilton. Customer Service Department. Copyright 1995-2008 Classmates Online, Inc. All Rights Reserved.

At first glance this seemed somewhat legit because I am a member of Classmates.com and so could reasonably expect to get emails from them. I'm also in a graduating class that would have an interesting anniversary in 2009 so it does make sense that we would be scheduling a reunion.

However, the email address to which the email was addressed is not the one that I have associated with classmates.com account - so clearly it wasn't classmates.com sending me the email. The address that was used is one that I've had for ages and typically gets close to 99.9% spam, so my internal "what's going on here" guard sprung up.

In addition, the email didn't look like the typical Classmates.com email -- which is just stupid laziness on the part of the attacker as it's pretty easy to fake someone else's email style, so while the email looking right isn't a good sign, having it look wrong is a big red flag.

Finally, the link in the email wasn't at the classmates.com domain (to find the actual domain you have to look at the third slash (/) in the URL and then work backwords -- the first two slashes should be right after the http: at the begining of the URL, so it's the next /). In this case it was newyearclassmates.com which should be another big red flag since it clearly was made to look like the real classmates.com domain.

If you did, somehow, follow the link, it brought up the following page:

This, too, doesn't look like the Classmates.com site -- another red flag and has no real information about what's going on. One would expect to at least have some text at this point with the name of the high school and other such information.

Instead all you have is a thing that looks like a video player application but actually is just an image and if you click anywhere on the image (like the play button or, if you're thinking of a YouTube video, the center of the video image) or on the Adobe Get media player button, the site tries to download and run a native application (an EXE). That should send big "DANGER WILL ROBINSON" shivers up your spine. Any website that tries to download an exe directly to your platform has to be treated as the enemy until proven to be a friend (no innocent until proven guilty here -- good sites rarely download EXEs directly like that without at least having some interactions with the user).

In this case the executable was Adobe_Player10.exe -- which I'm sure is a Trojan Horse which would do very nasty things to your computer at some point and it wasn't coming from Adobe's own web site, but rather from the newclassmates.com site itself -- another red flag (which, I hope, you never got because you didn't get to this stage). If you did get here and you think everything's legit, you should stop, go to the adobe web site and check version numbers or at least download the application directly from Adobe -- never download/install software that you got to through an untrusted link or from an untrusted site.

UPDATE: I've gotten 7 more of these same invites. All to different email addresses that route to me. That's another really good sign that things aren't well in Kansas and you should stay away from the email.

Moral of the story: It's a jungle out there and you've gotta watch out for yourself as there's nobody else doing it for you.

Tags : hacking / phishing / Trojan Horse / Internet Self Defense

Facebook vs DNS

Sometime back, about a couple of weeks ago, my Facebook page loads all of a sudden started getting very slow (like 20 seconds or so before the data started loading, but once it did start loading it was fast). It was only happening at Facebook (Google, WheresGeorge, Blogger, pretty much any other site) was working fine, so I thought the problem had to be at Facebook rather than on my side.

However, after it kept up for a week, I started to get irritated enough to dig into it. First I turned off my web proxy and went directly to the sites from my browser. Things worked fine then, so clearly it was an issue in my proxy. I run a Fedora Linux server at home that serves as my web proxy using the Apache HTTP daemon.

This past weekend, I started digging into the problem and spent several hours debugging, testing, searching the web and while I still don't have a clear reason as to the why, I do understand the what and have put together a somewhat nasty hack around the problem. Hopefully I will dig around and find or figure out what the problem is so that I can put in a good fix.

My first look at the server didn't show anything amiss. The httpd logs showed the accesses to Facebook with no errors. That led me to consider DNS as this felt like what you get when your DNS is timing out.

My /etc/resolv.conf file was clean and correct. Using the nslookup or dig tools, I was able to look up the names without problems and quite quickly on both my own name server as well as the name servers provided by my ISP. The system logs didn't show any problems in named or anything that looked like the firewall could be getting in the way.

However, using any other tool (telnet, wget, httpd) the name look ups would go through several failures before succeeding -- causing a substantial delay in accessing the site. This only happened with Facebook related sites (www.facebook.com and apps.facebook.com to mention two of them). The same tools, accessing any other site that I tried, had no problems and no delays.

Using strace, I could see that the first pass at the name service look ups were failing and each timing out after so many seconds before trying the next. Eventually, the tools go back and try again and the second time, the response comes back almost immediately and the tool continues. For example, "wget http://www.facebook.com" returned the following:

01     0.000106 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
02     0.000068 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, 28) = 0
03     0.000076 fcntl64(3, F_GETFL)       = 0x2 (flags O_RDWR)
04     0.000054 fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
05     0.000042 gettimeofday({1227974358, 62163}, NULL) = 0
06     0.000048 poll([{fd=3, events=POLLOUT, revents=POLLOUT}], 1, 0) = 1
07     0.000059 send(3, "\0079\1\0\0\1\0\0\0\0\0\0\3www\10facebook\3com\0\0\34"..., 34, MSG_NOSIGNAL) = 34
08     0.000861 poll([{fd=3, events=POLLIN}], 1, 5000) = 0
09     4.998266 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
10     0.000065 connect(4, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("66.36.226.50")}, 28) = 0
11     0.000071 fcntl64(4, F_GETFL)       = 0x2 (flags O_RDWR)
12     0.000046 fcntl64(4, F_SETFL, O_RDWR|O_NONBLOCK) = 0
13     0.000041 gettimeofday({1227974363, 61621}, NULL) = 0
14     0.000046 poll([{fd=4, events=POLLOUT, revents=POLLOUT}], 1, 0) = 1
15     0.000053 send(4, "\0079\1\0\0\1\0\0\0\0\0\0\3www\10facebook\3com\0\0\34"..., 34, MSG_NOSIGNAL) = 34
16     0.000098 poll([{fd=4, events=POLLIN}], 1, 3000) = 0
17     2.998500 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 5
18     0.000070 connect(5, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("207.228.225.50")}, 28) = 0
19     0.000073 fcntl64(5, F_GETFL)       = 0x2 (flags O_RDWR)
20     0.000045 fcntl64(5, F_SETFL, O_RDWR|O_NONBLOCK) = 0
21     0.000043 gettimeofday({1227974366, 60548}, NULL) = 0
22     0.000045 poll([{fd=5, events=POLLOUT, revents=POLLOUT}], 1, 0) = 1
23     0.000052 send(5, "\0079\1\0\0\1\0\0\0\0\0\0\3www\10facebook\3com\0\0\34"..., 34, MSG_NOSIGNAL) = 34
24     0.000118 poll([{fd=5, events=POLLIN}], 1, 6000) = 0
25     5.997342 gettimeofday({1227974372, 58108}, NULL) = 0
26     0.000050 poll([{fd=3, events=POLLOUT, revents=POLLOUT}], 1, 0) = 1
27     0.000054 send(3, "\0079\1\0\0\1\0\0\0\0\0\0\3www\10facebook\3com\0\0\34"..., 34, MSG_NOSIGNAL) = 34
28     0.000416 poll([{fd=3, events=POLLIN}], 1, 5000) = 0
29     4.997778 gettimeofday({1227974377, 56418}, NULL) = 0
30     0.000063 poll([{fd=4, events=POLLOUT, revents=POLLOUT}], 1, 0) = 1
31     0.000055 send(4, "\0079\1\0\0\1\0\0\0\0\0\0\3www\10facebook\3com\0\0\34"..., 34, MSG_NOSIGNAL) = 34
32     0.000106 poll([{fd=4, events=POLLIN, revents=POLLIN}], 1, 3000) = 1
33     0.001235 ioctl(4, FIONREAD, [34])  = 0
34     0.000065 recvfrom(4, "\0079\201\202\0\1\0\0\0\0\0\0\3www\10facebook\3com\0\0\34"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("66.36.226.50")}, [16]) = 34

As you can see, the delays come waiting for a response from the nameserver and it's not until the second try on the second name server (lines 31-34 before we get a response. You might think that this has something to do with my name server on 127.0.0.1, but that wasn't originally in my /etc/resolv.conf file until I started the debugging and the problem still occurs when I remove it.

A similar trace of the dig command shows that the first name server (whether it be 127.0.0.1 or my ISPs) resolves the name almost immediately (though dig uses a different communications method (sendmsg vs send) and different networking libraries.

Traces for wget with other host names return successfully on the first lookup.

I haven't (yet) figured out what exactly is causing this. But I have figured out two workarounds (neither of which are all that nice):

• Set one of Facebook's name servers as the first name server in my resolv.conf file (so my applications use that name server to resolve all host names.

  This does work (name resolutions worked first try and in very reasonable times). However, name servers are core trusted parties in your network access and I really don't like setting things up so that I totally trust Facebook's server for all of my outgoing name service look ups. Call me paranoid, but this one just isn't right for me.

• Add www.facebook.com and apps.facebook.com host entries to my /etc/hosts file (which is checked before name service look ups.

  This definitely works, though it does remove the usefulness of DNS from my access to Facebook (like if they change their IP address I won't know). However, it is the lesser evil of the two solutions I have found so far and so this is what I've done for now.

I'll post an update if I figure out exactly what's wrong (which I'm very unhappy about not being able to figure out so far -- I like being able to understand things and spent several hours after I had workarounds trying to figure it out to no avail).

Tags : facebook / dns / name server

Paul can't be wrong all the time

I have to say that, for once, I totally agree with Paul. In responding to a post by Ben Laurie, Paul disagrees with Ben's opinions of passwords and phishing.

Ben had said (and I'm showing a bit more here than Paul did in his response):

Well, no. If your password is unphishable, then it is obviously the case that it can be the same everywhere. Or it wouldn’t be unphishable. The only reason you need a password for each site is because we’re too lame to fix the real problem. Passwords scale just fine. If it wasn’t for those pesky users (that we trained to do the wrong thing), that is.

First off the phishability and reusability of passwords are distinct and separate issues. They have pretty much nothing to do with each other.

The primary reason one should not use the same password everywhere is that once that password is discovered at one location, then it can be reused at other locations. So, if, for example, you use the same password at Amazon, eBay, PayPal and Facebook, all one needs to do is find out your password on Facebook and then they will be able to sell things in your name on eBay, buy things in your name using PayPal and ship lots of things in your name at Amazon).

As Paul mentioned, there are many attacks to finding your password -- an administrator at Facebook could look it up in the password database, you could have a weak password that the hacker could attack via brute force (and if you're using the same password everywhere, they could use multiple sites to break the password making all/most of the anti-brute force rate limiting capabilities at a given site pretty moot). Just to name a few.

All of that said, Ben did have several good points in his post. Yes, we, as an industry, have done a terrible job in the usability of passwords. The typical user has been prompted for passwords so often and in so many places that they have no feel for when it should or shouldn't happen (one of the best personal defenses against phishing).

Personally, I think the utopia for online identity comes in with strong authentication to a small number of identity providers which assert my identity through SSO and Federation out to a large number of relying parties. Ben's point about the attacks around issuance/re-issuance of such strong credentials is very valid -- they can't be based on much weaker socially engineerable factors. The credentials will end up having to be issued with strong levels of assurance.

I also look forward to being able to login once at the start of my day and maintain that state in a reasonably secure fashion for the entire day without having to re-authenticate every few minutes or deal with "your session has been terminated for your security" when I've been sitting at the computer the entire time.

Tags : identity / authentication / assurance / federation / SSO / password / phishing