KingAnt.net

In light of my previous post where I talk about how it’s relatively easy to commit a man-in-the-middle attack, I feel like I should explain how people can protect themselves.

If you’re typing information that you consider private (typing your SSN or typing a password, especially for webmail or your bank), use this checklist:

1. Go to the login page (the page that asks you to type your password), but don’t type anything yet!
2. Look at the address bar at the top of your web browser.
3. Inspect the web page address and make sure it’s correct. For example, if you’re logging into Bank of America’s website then the address should be https://www.bankofamerica.com/ and not https://www.bankofamerica.youcantrustus.com/ and not https://www.bankofamerica.com@3468664375/ (the difference between these is subtle, but extremely important)
4. There should either be blue or green text, and/or a blue or green background in the address bar. Sometimes your browser will even show you the name of the company who operates the website; this gives you an extra level of trust.
5. There should not be a red X, a broken lock, a black slash, a yellow caution triangle, etc.

That’s it. Beyond that you’re trusting that the owner of the website you’re using knows what they’re doing and is competent.

Fair warning: This is somewhat technical.

Introduction

I recently wondered how hard it is to perform a man-in-the-middle attack. The login forms for Facebook, Twitter, Pandora and countless others submit login credentials using HTTPS, however, the forms themselves are served using HTTP (by default, anyway—many web sites allow users to choose an HTTPS login form).

The theoretical danger with a man-in-the-middle attack is that a malicious user could alter the content of web pages as they’re sent down to your computer. Login forms could be changed to submit credentials insecurely, thereby exposing your username and password. But just how feasible is it?

Step 1 – Trick the Victim’s Computer Into Routing Traffic Through Your Computer

This turned out to be much easier than I was expecting. I used a program called Ettercap¹, but there are other options. It has a GUI. I scanned my local network, picked out the IP of some poor sod (actually just another one of my computers), and chose the ARP poisoning option. Boom, all of poor sod’s internet traffic was being routed through my computer.

Step 2 – Serve the Victim An Altered Login Page

One way to accomplish this is to use DNS spoofing to make the victim think the attacker’s computer is “www.example.com”². Then run a web server on the attacker’s computer that serves content that looks like www.example.com, but behaves maliciously. Ettercap has a plugin that makes DNS spoofing easy. I played around with it and it works quite well. However, I didn’t want to bother with installing a web server on my computer or recreating www.example.com.

I wanted to do something a bit more elegant. I wanted to alter the web page on the fly, as it transferred through my computer on the way to the victim’s computer. Again, Ettercap makes this easy. It supports simple, text-based filters that allow you to search and replace any data on any port. I wrote a filter that 1) changes the login page of www.example.com so that the form is POSTed over HTTP and 2) saves the form submission to a text file³.

I cleared the web browser cache on the victim’s computer (to ensure I was using the altered login page), browsed to http://www.example.com/, logged in, checked the attacker’s computer, and indeed, my username and password were captured to a text file. Harrowing!

Firesheep

There’s been a fair amount of hubbub recently about Firesheep. It’s a point and click interface for session hijacking popular websites. It uses passive listening to capture network traffic from other computers on the network. It looks for session information for various websites, displays a list of discovered identities, and allows the user to impersonate a discovered identity by double-clicking on the victim’s name.

So that’s scary, but mostly just an annoyance. The potential for a criminal to benefit from Firesheep is limited—web sites that matter, like banks, tend to be more responsible and use HTTPS for all traffic. Want to know what really scares me?

Point and click Man-in-the-Middle

It’s easy for me to imagine a program that sits quietly on a network, performing man-in-the-middle attacks on users who visit websites for banks, investment firms, webmail. It could proxy all web pages, rewriting HTTPS links to HTTP. If the user wasn’t watching for the “HTTPS” indicator on their browser’s address bar, they’d be none the wiser. I don’t think it would take long for someone to collect credentials for a few hundred bank or email accounts.

Then what? I don’t know. Maybe ACH transfer money to a single account and withdraw? They’d track down the account owner. You’d have to run and hide. An entertaining prank might be to transfer a ton of money to a single account (not yours). They’d certainly have a hard time explaining that one.

I think it’s only a matter of time before this happens. Protect yourself: always look for the green or blue HTTPS indicators on your browser’s address bar anytime you’re doing something sensitive.

Summary

It’s possible to translate software using Amazon Mechanical Turk, but it’s not ideal.

What is Amazon Mechanical Turk?

It’s a web site run by Amazon (yes, the shopping company). Anyone can create an account and post some questions or a set of tasks. You agree to pay a certain amount for each completed task. Then someone else finds your task in the list, decides it’s worth their time, and does whatever is requested.

The tasks could be anything. Here’s an example that’s well-suited to Mechanical Turk: “Draw bounding boxes around objects in images — Draw a box around counter: table consisting of a horizontal surface over which business is transacted.” And then there is a picture of a kitchen and you’re supposed to draw an outline around the counter.

It’s a pretty cool concept.

What I Did

Late last year I decided that I wanted to try translating software (often described as “localizing”) using Mechanical Turk. I chose to translate Meebo’s Android IM application into Spanish. The application is written in a way that allows it to be localized: Individual chunks of text (usually called “strings”) exist in a single xml file. The source code of the application references this xml file whenever it needs to show a string to the user.

I posted each string to Mechanical Turk as a separate task. I offered $0.10 for short strings and $0.20 for longer strings. To attempt to increase the quality of the results I specified that shorter strings should be translated by 3 different people and longer strings should be translated by 5 different people. That way I could verify that everyone gave the same response, and pick and choose between different phrasing and word choice.

It worked, but I don’t have a high degree of confidence in the translation. I ended up having to use an online English-Spanish dictionary, Google Translate, and my own rusty knowledge of Spanish to decide between different versions of strings. I’m sure I didn’t do justice to my high school Spanish teachers, and I’m sure the result isn’t perfect.

Lessons Learned

• It’s easy to translate text poorly. It’s hard to translate text well. It’s an art. There are many subtle nuances in each word choice, and it’s very difficult to preserve those when translating to another language. And translating computer text is usually different than translating a book.
• Translators do a better job with context. For example, should the word “login” be translated as a noun or a verb? Should “sign in” mean that you’re connecting to another computer, or that you’re writing your name on a sign-in sheet at a bridal show?
• Having the same person translate all strings will provide better consistency between the strings.

Better Options

• If you can afford it, pay a professional software translation team. Professionals know what verb tenses to use for buttons versus menu titles versus dialog titles, etc. You’ll have better consistency if you have just one or two people translate an entire language.
• Have your users translate for you. If you’re a popular open source project this will work well. The translators may or may not be as talented as a professional who translates software for a living, but if they’re users of the software then they’ll be self-motivated to translate it, and will hopefully maintain the translation into the future.
• Have your translators create a glossary of words commonly used in your application (“username,” “e-mail,” “buddy”) and translate this glossary first. That way current and future translators can reference this glossary and maintain consistency across their translations.

I’ve mentioned the One Laptop Per Child (OLPC) project before. It’s very interesting to me.

Originally the project set out to create a $100 laptop (that may have even been the original name of the project?). They did manage to create a functional laptop with quite impressive educational software, but the cost for the laptop remains $200. Recently the founder of the project, Nicholas Negroponte, announced plans for a $75 tablet computer with a 9″ touch screen. The touch screen would also be a dual-mode display, which can function like the Amazon Kindle and use little power in well-lit environments, or can be backlit like traditional LCD screens. Not only that, Negroponte hopes that the screen will be constructed of some sort of ultra-durable plastic rather than glass.

My question: Is this guy crazy? Granted OLPC paved the way for our current netbook market. But I don’t think the touch screen he describes has been done before. That’s a lot of features to pack into an inexpensive device… I don’t know, I don’t think it’s going to happen. Not at $75, anyway.

This reminds me of a few years ago when Negroponte made an effort to use Windows on the XO instead of Linux. Many of the developers behind the project disagreed with him. There is a great summary of the events (and the OLPC and Sugar projects) here. Negroponte may be a driving force behind the project, but he doesn’t seem to be 100% grounded in reality.

On Monday Meebo announced something called XAuth (not to be confused with the X Windows authorization program). What is it? It’s a small JavaScript library intended to be used by website developers to tailor a web page to a specific user, with the end goal of creating a better user experience.

One of the stronger use cases in my mind is:

1. You’re logged into Facebook, but you never use Twitter
2. You read a news article on newsobserver.com
3. The News & Observer website could intelligently decide to show you a “share this on Facebook” button (because you use Facebook), and could decide not to show you a “Tweet This” button (because you don’t use Twitter)

The specification allows more flexibility than that. Website operators decide what information to share, and users are able to opt-out entirely.

More information:

• Meebo XAuth demo page (click “Visit Demo Page” for Google and log in–notice how meebo.com now knows that you have a Google account)
• Official XAuth website
• Long explanation video from Meebo’s CEO
• Meebo blog announcement
• Meebo press release

Press:

• Wired article
• Mashable article
• TechCrunch article
• VentureBeat article
• Google Code blog post
• Google Social web blog post
• Yahoo! Developer Network blog post