Irreal

I’ve written before about the wonders of Unicode but this post is an example of its dark side. Over at the Microsoft Malware Protection Center there is an interesting post about the use of Unicode by malware. It seems that the trojan TrojanDropper:Win32/Vundo.L hijacks the Russian social networking sites vk.com and vkontakte.ru and redirects them to another—presumably malware, the story doesn’t say—site.

The normal way of doing this is to add an entry to the hosts file (%SystemRoot%\system32\drivers\etc\hosts) but when they checked the hosts file it was clean—no entries for the Russian site. Then they displayed hidden files and discovered another hosts file that had been corrupted. How could this be? You can’t, of course, have two files with identical names in the same directory. By now, you’ve guessed the answer: the visible hosts file had the o replaced with the Unicode character 0x043E, which is a Cyrillic character that looks like the Roman character o. That meant that TCP/IP ignored the “clean” hosts file because it had the wrong name and ussed the hidden one instead.

I’ve heard of this trick being used in URLs to snare the unwary into going to a rogue site that appears to be legitimate but this is the first time I’ve seen it used this way. A very simple but effective trick.

Smylers over at the Smylers Blog has an outstanding post on little known things you can do with SSH. Even after years of using SSH daily, there were still a couple of tricks new to me in the post. Smylers mostly assumes you’re using OpenSSH, which unless you’re a Windows user you probably are. Even so, he shows how to do the same things with Putty or Copssh, so this is a worth while read for anyone who connects to a remote system.

Among the things he shows you are:

• How to share a single remote connection with several terminal windows. That’s handy when you want to have several views into your work on the remote server but don’t want to go through the pain of authenticating several times.
• How to SCP over an existing connection.
• How to make an SSH connection persist even if you log out.
• How to set up an SSH key so that you don’t have to give your password when you sign on.
• How to move that key to the remote system automatically. This is a real time saver because doing it manually is a pain.
• How to forward connections from one remote server to another.
• How to set up host aliases so you don’t have to type a long fully qualified host name.
• How to configure the user name you use on the remote host if it’s different from your user name on your local host. This removes the necessity to specify your login name when you connect.
• How to forward X11 connections.
• How to mount remote files locally over an SSH connection.
• How to connect to remote services with a local application. For example, if you have a database on a remote system that expects a connection on a certain port on the remote system you can configure SSH to do port forwarding to enable this.

There are some other tricks as well. Some of the commenters offer additional tricks so be sure to read them too. This is a really great post and if you’re an SSH user you should read it without delay. It has some techniques that will really make your work flow easier.

I just stumbled across a nice post on How Attackers Steal Passwords by Joe Golton over at FilterJoe. It’s an interesting look at the common attacks on user passwords. There’s not a lot new or surprising in the post but it’s a good summary of the various attacks and what users can do to avoid or mitigate them.

The attacks fall roughly into 3 groups

1. Social Engineering
2. Attacks on the Web site servers
3. Malware that the user downloads that then sets up a keystroke logger or other attack.

There’s not much we can do to protect ourselves against the second type of attack except to never reuse passwords and to avoid dealing with companies and sites that have demonstrably poor security practices. Avoiding social engineering attacks is mostly a matter of common sense and staying alert to the danger. Golton recommends just deciding in advance that you will never give anyone your passwords under any circumstances. If you are forced to do so in order to perform some needed chore—to import data, say—then immediately change it afterwards.

The third category is the hardest to deal with. Some password managers can help here with their automatic log on functions, which makes it difficult for keystroke loggers to intercept the passwords. Browsers like Chrome that set up sand boxes can also help but as Golton explains, some of these attacks are Javascript based and so operate entirely within the browser. The safest thing to do is to use a separate machine for banking and other high value transactions but not many people are going to do that. At the least, it may pay to quit your browser and start a new instance before doing any banking in order to get rid of stray Javascript.

Golton’s final note is that six of the nine attacks can be blocked with the correct use of a good password manager. He recommends RoboForm (Windows), 1Password (Mac OS X), KeePass (free), or LastPass for those looking for a cloud-based solution. You can read his reasons for these recommendations here.