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

  • Recent Posts

  • Calendar

    October 2014
    S M T W T F S
    « Sep    
     1234
    567891011
    12131415161718
    19202122232425
    262728293031  
  • About Us
    TrendLabs Security Intelligence Blog(breadcrumbs are unavailable)

    Author Archive - Ben April (Threat Researcher)




    By now, you’ve likely seen Google’s announcement that they now support a seven-day timeline for disclosure of critical vulnerabilities. Our CTO Raimund Genes believes that seven days is pretty aggressive and that rushing patches often leads to painful collateral damage.

    I agree that with the current environment many firms would have a hard time understanding the vulnerability, creating a patch and running quality assurance in that seven-day window. Hopefully, someday we will look back and wonder why it took us so long to get to a 24 hour patch cycle. Today, fixes are rarely given the level of resource that a new feature would have. But how do we effect a change here?

    I would like to float a proposal to change the social contract. My proposal is simple: when reporting a vulnerability to a vendor, the individual finding the flaw should wait at least until the day after the next Patch Tuesday before releasing their report publicly. There should be a declaration in the initial report indicating the intent to publish based on this protocol. I should add that if there are less than fifteen days to the next Patch Tuesday, one should wait one more cycle. That’s it, clean and simple.

    Note that this suggested timeline is a minimum wait period for unilateral action on the part of the reporting party. Discussion and negotiation with the vendor is encouraged. If the vendor fixes it sooner and clears release earlier, then by all means publish. If the vendor asks for more time, it is up to the reporting party to balance the risks to the public and the concerns of the vendor and decide whether to grant the extension or go ahead with publication.

    Vendors cover a wide spectrum in terms of responsiveness to reported vulnerabilities. Some are super responsive, others do a good job of emulating /dev/null. My proposal aims to level the playing field. Researchers would have the responsibility to provide notice to the vendor and a reasonable time to repair, this would give them the right to publish on a set timeline. Vendors would have the right to expect advanced notice and the responsibility to fix within the agreed timeline.

    One final thought: I used Patch Tuesday because it is well-known and prevalent. If the vendor has an established patch cycle, it would be good form to use their cycle, provided it is reasonable. If the cycle is too long (e.g. updates are released on January 1st every other year), then I suggest falling back to the Patch Tuesday model.

     
    Posted in Exploits, Vulnerabilities | Comments Off


    Apr2
    10:25 am (UTC-7)   |    by

    The market capitalization of the Bitcoin ecosystem crossed 1 billion US dollars recently. As the value of the each Bitcoin nears 100 US dollars, many have begun to take notice.

    One likely source of this sudden interest is the Cypriot banking crisis. As depositors scramble to hedge their investments, the steadily growing notoriety of bitcoin raises some interesting opportunities. The two most alluring aspects that make the Bitcoin economy unique are the concept of mining and, interestingly enough, the automatic limits on mining.

    Unlike other forms of currency, bitcoin users can create new money. By solving complex math problems users, or miners as they are often called, create new bitcoins where there used to be none. This operation is not strictly free “as in beer”. Miners need to invest time, electricity, and equipment into the endeavor. Profit is also not guaranteed. The nature of the math problems being solved mean that a single miner may never create new bitcoins on their own.

    This self-limiting aspect of Bitcoin creates a fascinating set of contradictions. First there is a hard limit. There will never be more than 21 million bitcoins in circulation. It is important to note that each Bitcoin can be divided almost ad-infinitum. Some software only supports fractional bitcoins to 8 decimal places, but there is no hard limit in the Bitcoin system itself. Once all bitcoins have been mined it is expected that the value will increase as smaller and smaller fractions are transacted.

    Read the rest of this entry »

     
    Posted in Bad Sites | Comments Off



    Currently, we have been seeing an uptick in the number of denial-of-service attacks using DNS reflection or amplification. There are many variants, but the general outline of the attack is the same:

    1. An attacker creates a DNS query with a fake source IP address – that of the intended victim. (Consider this as being analogous to a fake return-to-sender address.)
    2. The query is sent to a DNS server that accepts queries from external addresses (i.e., those from a different ISP/network than its own). In addition, the query is crafted to generate the largest reply possible. Frequently, DNSSEC is used, as returns using it  tend to be much larger than other DNS replies.
    3. The intended victim is flooded with packets. These can either be replies from the DNS server, or error messages sent along the way which are sent back to the “sender.”
    4. Using DNS reflection, it is possible to use a relatively small number of hosts (often compromised) to generate huge volumes of traffic aimed at victims. Often, the abused DNS servers don’t even know they are involved in an ongoing attack.
    5. This type of attack is very hard to trace as the source is well masked and you need lots of cooperation from the DNS server operators as well as their network service providers to trace attack to a source.

    Both network operators and the administrators of DNS servers can help mitigate these attacks.

    Network Operators

    It is estimated that 14.1% of netblocks, which total 16.8% of all IP addresses, can be spoofed. That may sound small, but the Internet is a big place. An attack using DNS reflection can cause a large amount of damage, even if much less than 1% of IP addresses are used.

    Ingress filtering applied at the router or firewall is one way to prevent networks from being a source of this type of attack. It prevents packets from transiting the router if the source address of the packet does not belong on the interface on which the packet was received. By analogy, this would be like a post office rejecting outgoing mail that had return addresses from out of town.

    This doesn’t stop spoofing attacks from machines on the same network, it does prevent machines from initiating spoofing-based attacks against outside networks. One of the best resources here is BCP-38, which describes in detail how to implement this type of filtering.

    Read the rest of this entry »

     
    Posted in Targeted Attacks | Comments Off


    Nov15
    2:28 am (UTC-7)   |    by

    Earlier, we talked about how ordinary users can use NFC securely. However, truly widespread adaptation of NFC is only going to happen if businesses adopt it for their own use. How can businesses safely use NFC for their own purposes?

    For one of the most popular uses of NFC – mobile payments – businesses really aren’t in a position to use their own solution; what’s more likely is that businesses will adapt some sort of existing mobile payment system. Both credit card and mobile providers are trying to enter this space, but both groups will support NFC. In such a situation, what businesses can do is ensure that their solution is from a reputable vendor, and to keep themselves informed about any potential security loopholes in the solution they adopt.

    However, payment systems are far from the only use of NFC in businesses. At the simple end, it can be something like letting people visit a website without typing a URL or scanning a QR code. However, as the standard develops, something like this becomes possible: a shop wants to offer free WiFi to its customers, but doesn’t necessarily want to expose it to the entire world. What they can do is put an NFC tag at the entrance that customers entering can swipe to set their phone’s WiFi settings.

    NFC tags could also be used to automatically update someone’s social media – it’s easy to imagine a tag for Twitter, another for Facebook, and another for Foursquare (just to cite three popular social networks that one might be interested in using on the go). All of this can be done either now, or are quite likely to become possible in the near future.

    Read the rest of this entry »

     
    Posted in Mobile | Comments Off


    Nov6
    1:53 am (UTC-7)   |    by

    Recently, I spoke at the hashdays security conference in Switzerland to talk about the security of Near field communication (NFC) – specifically, how people and businesses can use it securely.

    While NFC is not quite yet seeing widespread usage, early adopters – like many readers of this blog – are already using it in their lives. Some mobile manufacturers are touting the addition of NFC in their mobile devices. For my talk, I discussed what aspects of NFC usage can be considered secure, and what can be considered just “convenient”; what businesses can do to keep their customers safe; and what features of NFC should designers implement or completely avoid.

    For home users, though, the most important part of my talk was what they can do to keep themselves safe. It’s never too early to pick up good NFC habits. What are these habits that can keep you secure? They are:

    • Lock your mobile device. In general, devices have to be turned on or unlocked before they can read any NFC tags. A simple screen lock – even without any password being used – can protect users against these threats.
    • For passive tags, use an RFID/NFC-blocking device (such as a wallet). Passive tags will emit fixed information in the presence of a NFC field, which means that there is a slight privacy risk carrying around these devices – if a blocking device is not used. (Anti-static bags can also block RFID devices.) This isn’t the case for mobile devices as their NFC reader automatically turns off once devices are locked, so this precaution is not necessary.
    • Use an NFC reader app on your mobile device. By default, most mobile devices will simply open a URL if one is detected on an NFC tag. If you wouldn’t lick a tag, you shouldn’t open it blindly – instead, use an app like NFC TagInfo or NFC TagInfo by NXP to read the tag first. The apps will be able to tell you what information is on the tag – allowing you to make an informed decision if you want to scan it or not.

    We’ve seen no indication that NFC has been used in the wild by attackers, but it’s never too early to develop good habits when using this emerging – and promising – technology.

     
    Posted in Mobile | Comments Off


     

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