On June 23, Jakob Nielsen posted an article declaring that password masking on the user interface is more harmful in terms of usability than helpful to the security of an application to which Bruce Schneier, in a June 26 blog post agreed. Both argued that masking the characters when a user enters a password is of little security value and may even be harmful to the usability of an application. I personally believe that displaying password entries in clear text has more detrimental implications to security than lowering the difficulty of shoulder surfing.

I readily agree that a seasoned criminal will focus his/her shoulder-surfing efforts on a user’s keyboard than on his/her screen. For an attacker with keyboard-side access, password masking has zero value anyway. However, I think Bruce underplayed the prevalence of possible daily shoulder-surfing activities such as providing IT support to a user, stopping by a colleague’s workstation to review a document, polishing a presentation while on an airplane, or turning on a computer for children who aren’t entitled to unsupervised access. It is also worth considering that there may be situations where it would be inappropriate to ask your current shoulder-buddy (the CEO or your grandmother, you choose) to look away while you enter a password.

There are some small security advantages that password masking does offer. For example, unskilled attackers will be looking at the screen when you start entering your password. By the time they realize their mistake, they will only see *** and have already missed a good portion of your password. (Hopefully, knowing the end of your password won’t help them decode the beginning.) Password masking also encourages frequent users of a service to memorize their passwords. I have many passwords that I could not tell you no matter how hard I tried. My fingers know them or I may know a mnemonic but the keystrokes are the only thing I retain. This is not as helpful for more casual users though.

My main objection to the demise of password masking is the message that it sends to casual users. We enter a case of do-as-I-say-not-as-I-do. How can we ask our users to secure their password reminders if the entire password appears clear as day on the screen every time they enter it? Masking a password sends the message to the user that it is important that they not share their passwords, that they should not even show these to you, reinforcing the never-give-out-your-password tenet. In many cases, masking discourages copying and pasting passwords though only through naïveté (see here for a laugh).

The usability concern is indeed valid. The question becomes this, Where do we draw the line between security and usability? In my opinion, masking is a valid layer of security, though easily breached, it does raise barriers to entry even if only by a small margin. These barriers are also larger for the casual user. The more slowly a password is entered, the more time it would be on the screen, if unmasked. More importantly, it sends a firm message to users that their passwords should be protected.

Also, let’s not forget the principle of minimum astonishment—how many times would you have to use an application before you notice that your password is now being displayed on-screen in clear text? One possible compromise would be to provide a configuration option. However, this would not be friendly to a casual user who needs it most. I encourage application developers to seek out other usability accommodations (e.g., two-factor options, biometrics) before globally unmasking passwords.

If you're new here, you may want to subscribe to our RSS feed. Thanks for visiting!

Cybercriminals once again used the passing of Michael Jackson, the ‘King of Pop,’ a few days ago as an opportunity to go about with their malicious activities and attack innocent users.

We spotted an email (see Figure 1 below) about Michael Jackson’s death written in Spanish claiming to be from CNN Mexico.

Upon closer analysis (see Figure 2 above), we found that the sender of the email isn’t valid – info@hi5.com which is a spammed sender. The email also contained accurate information about Michael Jackson, buying itself credibility in order to lure users into clicking the links contained within the message.

The said email also contained a suspicious-looking link to an ‘exclusive CNN video’ about the event. Most of the other links on the spammed message were inaccessible and could not display the correct website. But one link—el sitio en internet TMZ (translated to English: ‘found in the TMZ website’)—which was a link to the site where the video is supposedly hosted but it redirects the user to another malicious site—http://{BLOCKED}.com/openbb/avatars/imagen/CNN/indexx.php. The threat in the said page is detected by Trend Micro as HTML_DLOADR.ARM.

This site does not contain anything but a black background and a message box telling the user that the Flash player version running on his/her system cannot play the said video. The message box contains three buttons (see Figure 3 above), clicking any of which will trigger the download of a malicious file—flash-installer-windows.exe—which claims to be the right Flash player version that will allow him/her to view the exclusive video. The said malicious file is detected as BKDR_IRCBOT.BW. BKDR_IRCBOT.BW connects to a certain IRC server and then joins an IRC channel where it waits for commands from a remote user.

Quite notable is that even if a user chooses the Cancel button, which should allow him/her to quit from downloading the file, the site will continue to push the download of the codec, leaving users with no choice but to deal with the malicious file downloaded into their system.

The spam message and malicious website used in this attack are already blocked by the Trend Micro Smart Protection Network.

A new ransomware spreading through email is on the loose.

On the outset, the worm detected by Trend Micro as WORM_RANSOM.FD may look like a normal mass-mailing worm but further analysis reveals that this comes with a deadly payload. With only a few exceptions (files with .rwg, .dll, .exe, .ini, .vxd, and .drv extensions are not affected), it encrypts files in the affected system using the Blowfish algorithm, thereby rendering them unusable. A .RWG extension is then appended to the filenames to serve as a marker.

Defying the norm of a typical ransomware however, WORM_RANSOM.FD does not ask for money in exchange for the files. Instead, it gives the affected user three options as to how he or she can retrieve his or her files:

So, unless Windows users are willing to migrate to Linux or wait for the decryptor program that may or may not come, Option 1 may seem the only plausible solution. Resourceful techies may opt to try their hand in manually decrypting the files, but for those stuck with Option 1, Trend Micro already provides a fixtool that will automatically restore the files.

Our experts believe that ransomware is a high-risk/moderate reward business model that will not significantly increase. This is because it goes against one of the key features most cybercriminals are relying on in terms of developing malware, which is stealth. Almost all aspects of a ransomware attack is quite visible.

For one, the payload is visible — users are informed that their files are held hostage, so these users can easily turn to their AV vendors for help in detection/cleanup, mitigating further infection from other users. Another is that cybercriminals have to leave contact details for the payment. These contact details can be used by law enforcement to track down the attackers.

Users who’ve found themselves victims of this attack may either use Trend Micro’s fixtool or ask for assistance.

Aside from the new Twitter component we’ve also seen Koobface download a new component with the filename dns.exe, whose main purpose, it seems, is to modify the system’s DNS registry settings.

It is accomplished by inserting 213.174.139.72 (IP of the rogue DNS server) into the values of NameServer and DhcpNameServer found in the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
Services\Tcpip\Parameters\Interfaces\{Device ID}

What this system modification does is, every time a website is visited, the domain of the website is resolved by asking the rogue DNS, which can then serve a bad IP that will redirect the unsuspecting user to a malicious or phishing site.

As of writing, the rogue DNS IP is inactive, but we recommend anyone who suspects that something fishy is happening while browsing should search for the presence of that bad IP and remove it (do NOT remove your original DNS IP though). The rouge DNS IP has a history of hosting various malware and malicious pages before so whatever it will do when it wakes up will be anything but good.

The said DNS changer is now detected as TROJ_DNSCHANG.UB, thus the Smart Protection Network also protects Trend Micro users from this.

Other notorious DNS-changers in the past can be read here:

• DNS Changer Malware Evolves – Again
• New ZLOB Rigs Routers
• Blended Targeted Attack in Mexico Now a DNS Changer and a Botnet

Recently, we came across JS_VIRTOOL which uses certain Javascript techniques so that encrypted code may not be decrypted and analyzed by a malware analyst.

Here is how this is done:

1. It retrieves the URL where the malicious script is located.
2. It retrieves its own function and adds the string of the URL.
3. It computes the CRC of the function plus the URL.
4. It decrypts an encrypted code in the script body using the CRC that was computed.
5. It executes the decrypted code using the eval() function.

Figure 1. Obfuscated code of JS_VIRTOOL

It uses its function and URL location as a decryption code. In this case, the encrypted code which is the real routine of the malware will not execute if the function is tampered and/or the URL is not correct.

If a malware analyst only has the script file sample without knowing where the file was downloaded from, he will not be able to know the malware’s actual routines since the URL is necessary for the decryption to take place. In addition, if this script is placed on another website aside from the “correct” one, it will not be successfully decrypted.

Currently, we have multiple samples that all use this particular technique, but have different encrypted contents. We suspect that they have the same decrypted data, the only difference being the URL location which will decrypt each sample. We believe that this as a technique which is intended to make it more difficult to track the source and cause of infection. This could potentially increase the time before these malicious scripts are detected and the appropriate solutions are released to users.