Trend Micro Facebook TrendLabs Twitter Malware Blog RSS Feed You Tube - Trend Micro
Search our blog:

  • Recent Posts

  • Calendar

    April 2014
    S M T W T F S
    « Mar    
  • About Us
    TrendLabs Security Intelligence Blog(breadcrumbs are unavailable)

    Author Archive - Jonathan Leopando (Technical Communications)

    The past few weeks have seen some very high-profile sites adopt two-factor authentication in one form or another. First was Twitter, followed soon by Evernote and Linkedin.

    For users of these sites, these represent a welcome improvement to their security. In the event that their password is (somehow) compromised, an attacker faces another barrier before they can gain access.

    There is still room for improvement. All three services use text message verification – i.e., they send an access code to the user’s phone when somebody tries to log in. Unfortunately, mobile malware can also intercept text messages: it is possible for a clever attacker to intercept these.

    An alternative which some sites use is an authenticator app, which generates the verification code on the device. Some sites require their own app; other sites are compliant with RFC 6238 so that a single app can authenticate multiple services.

    There are also some usability challenges. Not all apps or operating systems allow the user to enter authentication codes (actually, relatively few do). In these cases, you need to create an application/device-specific password – if the service supports it. (Theoretically, a bad implementation of these could pose a risk as well.) In addition, there is the very real problem of people losing their phones. In the United States alone, 1.6 million people lost their smartphones in 2012. A large service rolling out two factor authentication has to consider some way for users to authenticate if they’ve lost their device.

    This highlights the importance of the stolen device problem we talked about recently. Not only are mobile devices in and of themselves valuable and contain the user’s personal data, they can act as the keys to the rest of the user’s accounts.

    Of course, these three services are not the only ones to introduce two-factor authentication. Many other high-profile companies like Blizzard, Facebook, Google, and Microsoft all support some form of two-factor authentication. Users should check which of their services support it and strongly consider activating it.

    Posted in Social | 1 TrackBack »

    Last week, the US government shut down Liberty Reserve, a digital currency service operating out of Costa Rica. Its founder, Arthur Budovsky, was arrested at the Madrid airport as he tried to return to Costa Rica. Other arrests were made in Spain, Costa Rica, and the United States.  The company is accused of laundering over 6 billion dollars in illegal funds, with more than a million users globally – 200,000 of these being in the United States. The company’s site now sports a notice that it has been seized by US law enforcement.

    Liberty Reserve has long been a favorite way for cybercriminals to exchange money securely without exposing their identity. So how are they taking to the shutdown of Liberty Reserve?

    In a word: poorly. Not only did they lose access to Liberty Reserve, making underground transactions more difficult, but they also lost funds as well. Many cybercriminals are claiming they lost thousands of dollars, if not more: we saw one claim that he’d lost $300,000 in the seizure. We have to take the more extravagant claims with some skepticism, but it’s clear many cybercriminals did lose money thanks to Liberty Reserve’s closure. Somewhat amusingly, some are still in denial about the whole affair, saying that the service would return on June 1 with improved security. Obviously, that didn’t happen.

    What are cybercriminals going to replace Liberty Reserve with? Even in the underground forums, that isn’t clear. Both gold and Bitcoins have both been mentioned as possible substitutes. Other digital currency services like PerfectMoney have been mentioned as well. Coincidentally, some of these services have explicitly banned users from the US, perhaps in an attempt to shield themselves from US law.

    In the short term, we may actually see more online theft occur due to cybercriminals trying to make their money back. In the long run, if other digital currencies are targeted, it could make life for cybercriminals very complicated.


    The problem of mobile device theft has become sufficiently severe that legislators have decided to file bills discussing it. Last week, US Senator Charles Schumer re-filed Mobile Device Theft Deterrence Act of 2013, which makes modifying a device’s International Mobile Equipment Identity (IMEI) number a crime punishable by up to five years in federal prison. In theory, this is supposed to make it more difficult for stolen devices to be reused and thus less appealing. The CTIA, a trade group representing the wireless industry, has spoken out in support of the bill.

    Having one’s mobile device stolen has real costs. Replacing a phone can cost hundreds of dollars; any data on the device may be either lost or stolen. Enterprises particularly care about the latter problem, an item we discussed in the report Embracing BYOD: Are You Exposing Critical Data?.

    Even if the bill was passed, it’s unclear how much impact it would have, given how many stolen devices end up “exported” abroad. (Stolen goods being “exported” is not limited to electronics; for example, stolen cars have long been exported to places like Albania, Africa, and other less developed parts of the world.)

    The bigger issue is that other solutions to try and “fix” this problem may actually weaken mobile device security, not strengthen it. It’s frequently suggested that “remote kill” systems that would remotely disable stolen devices be included in new devices. However, these are very problematic from a security perspective: it would mean that the capability to remotely administer a device would have to be built into the device: i.e., a backdoor. If the capability to remotely kill a device is built into a product, it has to be assumed that a sufficiently determined attacker can access it and do what they with that capability.

    There’s also the thorny issue of who would hold the keys: both end user and organizations can be socially engineered and end up with a malicious attacker disabling (or just threatening to disable) a device. We’re supposed to make devices more secure over time, not less; a “remote kill” system brings with it very real potential problems. It may be better to focus on locating the device after it has been stolen; this capability is already built into iOS and Windows Phone, but not Android.

    The real solution to the problem of stolen devices may be found by treating it as a police problem and not necessarily a technological one. Any proposed solution to device theft has to take all mobile security problems into consideration; the law of unintended consequences may strike again.

    Using technology to solve a crime problem may only go so far.

    We’re trying to make the Security Intelligence Blog better. Please take this survey to tell us how.

    Posted in Mobile | Comments Off

    Since its initial release in February 2012 the Raspberry Pi – a very inexpensive, palm-sized computer meant to help teach computer science in schools –  has become a favorite of hobbyists, makers, and tech enthusiasts everywhere. Why wouldn’t it be? The Raspberry Pi offers tinkerers a very low-cost (both to buy and to run) computer in an extremely compact platform. In addition, because of its origins as an educational tool, it’s easy to use and is versatile. Accordingly, it can be used in all sorts of creative ways.

    However, its apparent simplicity and low cost comes with a downside. The Raspberry Pi is not a simple “device” with limited capabilities; it is a fully capable computer. The same pitfalls that befall normal desktop computing can  hit the Raspberry Pi, if it is not properly secured.

    Some uses of the Raspberry Pi actually turn them into servers, and that is something that users may not really know how to secure. For example, some people have made the Raspberry Pi into a server that controls their home automation system, or allows users to watch videos served by the Pi remotely.

    For many uses of the Raspberry Pi, security isn’t much of a concern – it will never be online or even exposed to external input that could be used as an infection vector. The trouble comes when it’s used in situations where it is online – particularly as a server – where it’s at potential risk. For example, some automated scanners are already trying to log in with the pi user.

    In short, the Raspberry Pi is only as secure as the uses you use it for. Good server security is not always easy; consider that even IT professionals make mistakes. Look into known server best practices if you do use a Raspberry Pi for these uses. Considering its origin as an educational tool, learning how to secure a server would be an appropriate use for a Raspberry Pi. You can also check out the infographic we’ve made about this issue here.

    We’re trying to make the Security Intelligence Blog better. Please take this survey to tell us how.


    A few weeks ago, we noted that we believed it was likely that Bitcoin miners using GPUs might become part of the threat landscape. It appears that that has happened, in a somewhat roundabout way.

    The e-sports league ESEA was recently forced to admit that an employee had, without authorization, pushed a Bitcoin miner to users and forced the client machines to mine coins – for his own gain. They claim that the code to do so was born out of internal tests to see if this could be added as a feature to their software clients. ESEA themselves described the affair as a “fiasco“.

    By itself, this would be interesting enough. A legitimate software service was used to push unauthorized software to the machines of end users, much like what happened in Korea recently. However, the payload itself was unusual too: it was a Bitcoin miner, specifically one that was capable of harnessing the GPUs of users.

    This incident may well have been the first that did use GPUs, but we doubt it will be the last. The losses to users may not have been that large, but they were real nonetheless: increased energy usage and wear and tear on their computers. In addition, affected users will also see increased bandwidth usage as effective miners use a noticeable stream of bandwidth.

    Gamers may want to pay particular attention to signs of heavy GPU load on their system in the absence of any gaming activity. These can include excessive levels of heat or noise from their system, as well as poor performance in games. The control panels provided by AMD and nVidia can also be used to check the load on GPUs – under normal, non-gaming circumstances, GPUs should not be heavily loaded.

    We’re trying to make the Security Intelligence Blog better. Please take this survey to tell us how.



    © Copyright 2013 Trend Micro Inc. All rights reserved. Legal Notice