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)




    Earlier this week the folks over at OpenDNS announced a preview release of their new tool DNSCrypt. This is touted as a huge step forward for privacy and security across the Internet. The premise is simple, encrypt all DNS traffic between the user and their recursive resolver. It’s a nice idea and all, but I think they missed the mark.

    According to OpenDNS, the code is actually the first real-world implementation of the DNSCurve scheme. The stated goals are to provide privacy and authenticity to the entire DNS transaction. Unfortunately, you can’t just wrap an existing protocol with crypto and expect to be more secure than you were before. In this case you need to look at the entire ecosystem. Sure your DNS query will be private, invisible to other users or attackers on the same network. The problem comes a few milliseconds after you get the result. The privacy you gained by encrypting your DNS traffic evaporates when the browser makes its request of the server. An attacker in a position to see your DNS traffic is likely to have the same visibility into other forms of traffic.

    If you are more concerned with authenticity of the data than privacy, there are better ways to get that as well. DNSSEC is ready to answer your call. A major advantage of DNSSEC is that in the case of some TLDs it can authenticate the result all the way to the root (This list includes an indication of which TLDs are signed). According to the DNSCrypt FAQ at OpenDNS, DNSSEC and DNSCrypt function perfectly in concert: “They aren’t conflicting in any way.”

    Read the rest of this entry »

     


    Nov21
    3:11 pm (UTC-7)   |    by

    Researchers at Applidium have published some interesting findings about the protocol used by Siri. For every request the user makes to Siri, the iPhone 4S sends the compressed audio of the request to servers at Apple to first be converted to text. Then, it is mapped into commands that the iPhone can understand, and then sent back to the device.

    This protocol sits on top of HTTPS, and intercepting or spoofing it requires either a valid SSL certificate for guzzoni.apple.com or a way to convince the device to accept your certificate as valid. One must also hijack DNS so that the phone would think guzzoni.apple.com is at an IP address that you control. The post from Applidium covers the details pretty well, so let’s talk about what one could do with this.

    I’ll start with the positive and creative things that can be done. In theory, it should be easy to port Siri to any device if you have a valid iPhone 4S ID. Any device capable of recording audio and running an “app” with Internet connectivity should work. This includes laptops, tablets, smartphones, even refrigerators and washing machines.

    You can even build your own Siri server for existing Siri capable devices to talk to. This can be utilized for home use for commands like “turn on the light”, or “close the garage door.” This can also be done within a business: imagine integrating such a system with your everyday tools to make workflow voice interactive. Anything you can script, you can ask Siri about.

    Read the rest of this entry »

     


    Jun7
    10:57 am (UTC-7)   |    by

    With World IPv6 Day upon us, I thought I’d take a moment to expound on the IPv6 transition so far and what we are likely to see in the near future.

    IPv6 is like a dead animal lying on the road: a group of kids gathered around it, sticks in hand negotiating who gets to poke it first. You have ISPs and carriers waiting for customers to demand it and all of their vendors to support it, you have hardware and software vendors waiting until IPv6 becomes more important to customers than the features their customers are willing to pay extra for then you have other businesses that have to weigh IPv6 activities against anything else on the plates of their IT departments. Given the current security/breach climate, it is no surprise to me that IPv6 is not making huge strides.

    Finally, you have the end user. Without a killer app, there is very little motivation for end users to demand IPv6. Grandma wants pics of the grandkids, what protocol those images arrive over makes no difference to her. At the moment, the hassle of converting just doesn’t seem worth it for most users.

    I myself went through the process of converting. I updated my personal website, email setup, a tunnel to my home network, and even got myself certified at ipv6.he.net. After all was said and done, the only thing I had to show for it was my newfound ability to go to ipv6.google.com or pass the various IPv6 tests. The cool factor of this lasted for 10 minutes. By the time it turned off, I found myself wondering why I wanted to maintain two sets of firewall rules plus RA and DHCP (not all of my devices at home support IPv6) and deal with the extra troubleshooting and maintenance. Having been through the exercise, now I already know what devices I need to replace and what services need to be updated and have a much better idea about how to keep things secure. When the time comes, it should be easier the second time around.

    Read the rest of this entry »

     


    Feb4
    7:38 pm (UTC-7)   |    by

    If you consult the Internet Assigned Numbers Authority (IANA) IPv4 assignment page, you will notice that there are no remaining “UNALLOCATED” blocks in IPv4. This comes as part of the chain of events leading up to IPv6 migration and was triggered by the assignment of 179/8 to LACNIC and 185/8 to RIPE NCC a few days ago. These two assignments took the global unallocated pool down to five /8s, just enough for each regional Internet registry (RIR) to get one last block before the party ended.

    The IPv6 proponents are using this as a call to action to spur the IPv6 transition. I look at the IANA list and wonder why the “Class E” space is still marked “RESERVED.” RFC 1700 declares 240/4 as “Class E addresses are reserved for future use.” I for one can’t think of a better “future” use for this space than to extend the useful life of IPv4 while we work out the kinks in IPv6. IANA allocated nineteen /8s in 2010 so the sixteen /8s that 240/4 comprises wouldn’t buy the global pool much more than a year. There are also concerns that some existing hardware and software won’t accept IP addresses in the 240/4 range though IPv6 suffers from the same problem.

    I tend to agree with Dave Siegel at Global Crossing that the exhaustion of the global IPv4 pool is NOT a reason to panic. It should be used as an opportunity to review your IPv6 plans (You do have an IPv6 plan, right?) and make sure that you are on track. ISPs and RIRs both have a good deal of IP space stockpiled. If you are projecting the need for more IP space in the near future, this is not a good time to procrastinate on your request.

     



    In line with Data Privacy Day this Friday, Facebook announced its rollout of Secure Sockets Layer (SSL) capability for all of its services. Facebook has taken some heat for its lack of SSL support, especially with the release of FireSheep, which we covered here. Facebook does warn that encrypted pages will take slightly longer to load, which is a small price to pay for the added security.

    According to the official Facebook post, there should soon be a check box titled Secure Browsing (https) under the Account Security section of Account Settings. This setting specifies that all future connections be redirected to HTTPS. It should be noted that this rollout has just begun and that this option is not yet available to everyone. It may take some time before this option is made available to everyone.

    In the absence of the Secure Browsing setting, manually changing the URL to https:// seems to work but with mixed results. The main profile page will successfully load with no problems. Unfortunately, things start to get sketchy from there. Many links are relative and will keep the user in the secure browsing environment. Other links, however, are absolute and remove the protection of SSL. Hopefully, Facebook will fix these issues soon or at least makes it more clear when SSL support is not available.

    Facebook also warned that some third-party applications and their own chat functionality currently don’t work if SSL is enabled. Users should be aware of this and take appropriate precautions if they can’t use SSL for those reasons.

     


     

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