For your ease of following us: Facebook & Twitter

by Ruchna Nigam
June 20, 2011 at 3:31 am

A couple of days back, a game of Nerd Truth or Dare in the lab led to the shocking revelation that most of us were using our Facebook/Twitter accounts mainly to keep up with security blogs. Personally, being a twitter non-conformist until recently, I even created a twitter account for this sole purpose. And that led to the realization that FortiGuard Labs need to ‘get with it’ too.

So here’s introducing our Facebook and Twitter pages for your ease of following us.

If you, like us, have tried every RSS aggregator there is under the sun, have been left unsatisfied with each, and then have finally resorted to using social networks as aggregators, you might be happy to know that you can follow FortiGuard Labs through your Twitter or Facebook accounts.

Follow/Like us to keep up with our research, blog posts, threat advisories and other work that we feel you might find interesting.

Author bio: Ruchna Nigam is a security researcher at FortiGuard Labs and works with PC and mobile malware. She is also interested in aspects of security like biometrics and encryption schemes and is getting used to referring to herself in third person.

Encrypting Facebook

by Axelle Apvrille
December 21, 2010 at 9:36 am

A while ago, probably after a long and difficult day, I got into this funny idea of encrypting my Facebook account messages so that only the people I really wanted to could read them (i.e not an unknown stranger using Firesheep, nor a third-party applications or not even Facebook itself). For a moment, I wondered how to do this, until I remembered a Firefox plugin named FireGPG. Basically, FireGPG is Firefox extension to GPG, i.e it enables easy encryption/ decryption/ signature/ and verification in the browser.

So, I installed the plugin and tried it out. It’s quite easy to use, actually. I prepared a new message in Facebook (don’t hit the “share” button yet). The example below shows the encryption of a new status, but of course, it works just the same with direct user to user messages.

Writing an encrypted message on Facebook

Then, I encrypted the message (copy message to clipboard and do Tools > FireGPG > Encrypt – for example) I wanted to secure. FireGPG is basically a GPG front-end, so it is possible to use public key cryptography and encrypt the message for one or several recipients (provided their public keys are in your keyring) or use “conventional encryption” which consists in sharing a passphrase among recipient.

This is what my wall looks like to unsollicited readers or applications :) Geeky, huh ?

Encrypted message on Facebook

But friends whom the message is for (and who have FireGPG installed) can decrypt this quite easily, because the FireGPG plugin spots there is an encrypted message and displays the following:

FireGPG spots an encrypted message

They click on decrypt, enter their keyring passphrase or the shared passphrase, and read my wall correctly.

Decrypted message

Note that if you are already using a Firefox plugin such as HTTPS everywhere or Force-TLS, the communication pipe with Facebook (from your browser to Facebook hosts) is already secure, thus FireSheep users (and sniffers in general) won’t be able to snoop on your private data. In that case, FireGPG is ‘only’ useful to secure the messages on Facebook hosts – in other words, if you want that Facebook itself cannot read them (nor anyone else hacking her way into it).

Okay, so now I need to convert my friends to FireGPG. ;)

– the Crypto Girl

Author bio: Axelle Apvrille's initial field of expertise is cryptology, security protocols and OS. She is a senior antivirus analyst and researcher for Fortinet, where she more specifically looks into mobile malware.

Spam 2.0 leads Facebook users to Canadian Pharmacy ring

by Guillaume Lovet
May 4, 2009 at 12:01 pm

Our sensors (i.e. our digital media person, a rabid fan of Facebook) caught today some interesting Facebook private messages. One of such, sent by a “Friend” to about 100 contacts of hers, merely consisted in a domain name, as can be seen below:

Mass Private Message

Fortunately for Daniel, he did not know what to do with it (or he knew, but did not want to); yet other recipients may have recognized a domain name, and entered it in their browser’s address bar, out of curiosity. After all, that’s from Martha, and she usually sends rather funny links.

female_cialisOf course, the link was not actually from Martha, but rather from a cyber criminal having compromised her account. Fortunately, unlike Martha feared (but one is never too careful, and Martha is wise), the link did not lead to a virus-loaded page, but to a “pharmacy shop” belonging to the infamous “Canadian Pharmacy Ring“, and registered at “Directi Internet Solutions” (the new name of the infamous EST Domains registrar). In a nutshell, a typical case of spam 2.0. But while spamvertizement has happened before on Facebook Walls, and worms such as Koobface did leverage Facebook Private Messages to propagate, to our knowledge it’s the first instance of spam being distributed via Facebook Messages.

Another point worth mentioning is that while to Daniel’s eyes (if we assume his reply was ironic), junglemix.in was obviously a domain name, it was not at all the case to Facebook filters. We have shown in a previous post how Facebook wraps all urls featured in messages, so as to retain control on the “clicks” performed by recipients, even if those recipients read the message from their regular email account. This one obviously went under the radar, most likely because it did not feature ‘http://’, ‘www’, and used a domain extension (.in) that is also a (very) common word.

The consequence is that although Facebook did react fast, deleting the messages in the Facebook boxes, those which have already reached the regular mailboxes of recipients (most people do have the “forward messages to my email” option enabled), are still there, unwrapped, so Facebook cannot deny access to the link. The downside for criminals, of course, is that it is not clickable.

Author bio: Guillaume Lovet is the head of Fortinet's FortiGuard security research team in EMEA and a regular speaker at international antivirus conferences.

Facebook’s automatic URL-wrapping: A double-edged sword?

by Guillaume Lovet
March 5, 2009 at 2:13 pm

The Koobface worm scouring Facebook since last July, and which made the headlines again this week, is certainly beginning to redesign the concept of “friend. ” The “acquaintance from high school you’ve never talked to since you added her/him” might now be the “acquaintance from high school you’ve never talked to since you added her/him and who occasionally sends links to sites loaded with viruses.”

While Koobface has redefined this friendship concept, it’s not the only thing: It’s redefined the URL redirection policy of Facebook.

Indeed, URLs used to be left “as is” in friends’ private messages — assuming that they did not lead to a malicious site, of course. This is the very reason why Koobface “first-click URLs” are a mere hop through a reputable site (Google Reader, Google Picasa…), which in turns redirect unfortunate users to the final, malicious site (Facebook is not going to blacklist Google, right?).

Now and then, URLs included in messages are being automatically wrapped up by Facebook, in the following fashion:

URL: http://www.example.com
Wrapped URL: http://www.facebook.com/l.php?u=http://www.example.com

The latter is called a “web redirector.” Upon clicking on the wrapped URL, users are “going through” Facebook before reaching the final destination (here, www.example.com). What is really the point in force-wrapping URLs in redirectors? Simple: Friends’ messages are not only sent to the recipient Facebook account within the site, but are also e-mailed to the recipient external mailbox (Gmail, Hotmail, Yahoo Mail, etc.). Wrapping URLs in redirectors therefore allows Facebook to track clicks even when they are performed from the recipient external mailbox.

In our precise case, this serves a security purpose: even once malicious messages have been successfully emitted, users happily journeying toward the malicious final site from their mailbox can still be stopped at the redirector level.

It does make some sense. One may very well wonder if the cure is not worse than the disease, however. Indeed, web redirectors raise multiple security issues, which have been known since at least 2003 and have many times generated indignation in the ranks of the security industry.

Simply put, open web redirectors allow spammers, phishers, fraudsters, scammers and other cyber criminals to “wash” their malicious links with the name of a reputable site, fooling URI filters and human users alike.

Indeed, wouldn’t http://www.facebook.com/l.php?u=http://my%2Emalicious%2Esite%2Ecom be more likely to be trusted than http://my.malicious.site.com? This is where it all becomes ironic: since precisely this redirector is meant to wrap malicious links, Facebook might be seen as unwillingly giving an edge to cyber criminals without the later ones even being aware of it.

Granted, when going through Facebook redirector, users are presented a message stating:

“You are about to leave Facebook to visit this address: [...] For the safety and privacy of your Facebook account, remember to never enter your password unless you’re on the real Facebook web site.”

Let’s therefore grant Facebook’s the title of “semi-open redirector.” Yet, users are nowadays so much watered by warnings anywhere they click, that the efficiency of this one may be questioned. Besides, a base of social engineering (directly inherited from experimental social psychology) is that once the decision to perform the first click has occured, little events could reverse the process of commitment to reaching the destination.

So, automatic URL-wrapping, a good idea or a double-edged sword forced by Koobface’s pressure?

Author bio: Guillaume Lovet is the head of Fortinet's FortiGuard security research team in EMEA and a regular speaker at international antivirus conferences.