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

  • Mobile Vulnerabilities

  • Zero-Day Alerts

  • Recent Posts

  • Calendar

    August 2015
    S M T W T F S
    « Jul    
  • Email Subscription

  • About Us

    Author Archive - Ben April (Threat Researcher)

    12:30 am (UTC-7)   |    by

    At least two tools have been released in the past week that make stealing Facebook, Twitter, or just about any other Web 2.0 account while you surf from your local coffee shop a drag-and-drop proposition. From a technical standpoint, it has never been difficult to do. With these new tools, however, it becomes trivial. I’im talking about something my grandmother can use.

    Idiocy bills itself as a warning shot to people browsing the Internet unsecurely. The premise is simple—it is a 130-line Python script that will sniff open wireless networks for Twitter login cookies and will use that information to hijack any session it finds and to send a single Tweet. The message is simple—I browsed Twitter unsecurely on a public network and all I got was this lousy tweet.

    Screenshot of default tweet

    The other tool, Firesheep (detected as HKTL_FYRSNIFF), is a more sophisticated tool. It is a Firefox plug-in that is capable of collecting session cookies from a much larger set of sites and that gives you the ability to fully hijack the session into your own browser. The list of sites that it can attack is even extensible by the user.

    Click for larger view

    Read the rest of this entry »


    Over the years, many changes have been made to the Domain Name System (DNS). Some of these changes were made to allow internationalized domain names (IDNs). The concept behind these is simple—to allow language-specific scripts or characters that are not part of the usual Latin alphabet to become part of domain names.

    However, the security and cybercrime implications of international domain names have to be considered. We know that criminals jump at every new technological development to make money… and that some open the doors to cybercrime more easily than others.

    This is a subject I’ve been thinking about for a while now. There are a number of facets to the IDN discussion and a number of associated risks.

    Top-Level Internationalized Domain Names

    Initially, country-code top level domains (ccTLDs) were not part of IDN implementation. For example, you could use Cyrillic characters in an .ru domain but the country code would not be in Cyrillic. (IDN support would be decided by the bodies managing each specific ccTLDs.)

    Several internationalized domain names have already been approved for use by the following countries:

    • China (中国 and 中國)
    • Egypt (‏مصر)
    • Hong Kong (香港)
    • Russia (рф)
    • Saudi Arabia (السعودية)
    • Taiwan (台灣 and 台湾)
    • United Arab Emirates (امارات)

    The first threat that comes to mind is domain squatting in these new country-code domains. Let’s consider a theoretical example of the (fictional) company Bingo. бах is Bingo in Russian. Suppose someone registers бах.рф before Bingo gets around to it.

    The customers of Bingo would be exposed to phishing from бах.рф before the legitimate Bingo organization is able to register its domain. (This threat would occur anytime a new TLD is approved that is applicable to an existing organization.)

    (Note: The previous two paragraphs originally appeared with “” as the example. This was incorrect, as it is not possible to register If the top-level component is internationalized, the second-level component must be as well.)

    It gets worse. With a valid registration, it would not be hard to prove that a domain is legitimately owned and thus get an SSL certificate. This could lead users to believe they are visiting the legitimate site. The only real solution here is vigilance on the part of the domain owners and registrars and careful scrutiny on the part of computer users.

    However, we know that most users do not closely examine all of the URLs they see. Many are still unaware of the risks phishing poses or are too trusting of information they receive by email and by other communication channels. Consider the following list of targets cybercriminals attacked via phishing in August:

    Click for larger view

    Cybercriminals would not persist with this method of attack if it were not profitable.
    Read the rest of this entry »


    Last week at the BlackHat and DEFCON security conferences, independent researcher Craig Heffner demonstrated a new attack against home routers that combined DNS rebinding and Cross-Site Request Forgery (CSRF). This attack used JavaScript to trick the user’s browser into establishing a communication channel between the attacker and the admin console of his/her home router. If the router password is easy to guess (e.g., router or password) or still set to the factory default, the attacker can quickly gain full control of the device and by doing so expose every device on the network to attack. (For example, the attacker might be able to change the DNS settings of the router, making everyone connected to it vulnerable to phishing attacks.)

    The Attack: Complex but Practical and Effective

    First, the attacker has to assume a position where he/she is capable of changing the DNS records of the domain that will be used for the attack. Next, the attacker will need to create various pages on the malicious domain that will host the Web side of the attack and link these with DNS. Finally, the attacker must have sufficient control of the Web server such that he/she can cause it to send a TCP reset (RST) command on demand.

    The attack begins when the user visits the malicious site. Heffner used DNS to collect the victim’s public IP address but there other ways to do this as well. Once the attacker has the victim’s public IP address, he/she needs to quickly create a new subdomain on the attack domain with 2 A records, which map a hostname to an IP address. The first A record points to the server while the second points to the public IP address of the victim’s router. The Web server now redirects the victim’s browser to a page with JavaScript code that will execute the CSRF portion of the attack.

    Now we get to the interesting part. The browser begins to execute the JavaScript code that tries to connect to the temporary subdomain. The attacking server will reply with an RST command and end the session. This user’s system will then try the other IP address that it knows about for the hostname, which happens to be the external IP address of the victim’s router. Any result is channeled to the attacking server via a portal. The attacker can try different user name and password combination until he/she successfully connects or the browser window/tab is closed.

    How Users Can Protect Themselves

    Normally, the admin console is not exposed to the Internet because many consumer routers include a default setting (or provide an option) that prevents any IP address outside of the local network from connecting to it. However, many services on these devices listen for connections on all interfaces. Packet filtering will prevent external users from accessing the admin console but internal users can often access the console using an external IP address.

    Here are some suggestions that will reduce risks brought about by this attack based on the list of suggestions provided by Craig Heffner:

    • Enable the HTTPS admin console on your device and don’t forget to disable the HTTP console (if possible).
    • Use a strong password for your router. Change the user name to something other than the factory default, if possible. If you worry about forgetting the new password, write it down and put it on the device itself.
    • Disable access to your router’s admin console from any external network. This option is often accessible from the admin console.
    • If you choose not to use the DNS servers automatically provided by your ISP, use another recursive resolver (with permission) or a resolver offered for public use such as OpenDNS. This will protect you from the published version of this attack code and the root servers will thank you.
    • If possible, add a firewall rule preventing devices on your local network from sending packets to the block that your public IP address is a member of. This will prevent any IP addresses on your LAN from contacting the external IP address of your router. If your ISP changes the block used in your neighborhood, however, you will need to edit this rule. As an added benefit, this rule will prevent your systems from inadvertently broadcasting to your neighbors.
    • Keep the firmware of your router and other network devices up-to-date.

    Updates as of August 5, 2010, 2:05 a.m. UTC

    Since this attack involves the usage of a malicious JavaScript, installing the NoScript plugin should be helpful in preventing being victimized by such attacks.

    OpenDNS also discussed this same issue, and stated that using OpenDNS may be a valid solution to prevent these attacks.


    Over the past few years, there has been plenty of talk about the exhaustion of IPv4 addresses and the need to adopt IPv6. One thing that is clear is that we will run out of space within 1–2 years, if not sooner.

    How IPv4 addresses will run out

    We know how IPv4 addresses will be exhausted. By policy, when there are only five remaining unallocated /8 IP blocks, the Internet Assigned Numbers Authority (IANA) will assign each of the five regional Internet registries (RIRs) their final IPv4 address spaces. (As of this writing, there are 16 unallocated /8 blocks.) From that point on, each registrar is on its own. This will be the first concrete indicator that we will be exhausting IPv4 space soon.

    At this point, a rush to buy IPv4 space will happen. Most RIRs have between one and two /8 blocks in reserve. Service providers who want to keep IPv4 will be looking to snatch up extra space to ensure that they have room to grow. We should see IPv6 growth here, as IPv4 users watching from the sidelines will need to start moving before their services are affected.

    Unfortunately, this means we should expect a full suite of related scams and frauds. These will most likely play on fears of network instability or (un)preparedness such as:

    • Pay us $XXX to convert your existing IP addresses to IPv6.
    • For a fee, we will guarantee that you can keep your IPv4 addresses.

    There is also a potential for a gray/black market dealing in the IPv4 space. This could eventually lead to prefix hijacking. An offer to buy unused IPv4 space for a seemingly large payout may be legitimate. However, you will still be the registered owner of that block in the whois and RIR databases. Any malicious activity found there may cause you a knock on the door from a government agency.

    Challenges of IPv6 migration

    I expect IPv4 to be alive and well for a decade if not more. Too many legacy systems that do not face end users and work perfectly gain nothing from IPv6. Many services and service providers are not yet IPv6 capable. In addition, some long-standing issues with IPv6 keep getting kicked down the road in the hope that someone will solve them remain unsolved. These will slow the transition down. One such issue will sound very familiar to folks who have experience from the mid 1990s.

    RIRs started allocating /24 blocks to end users that, in theory, they could take to any ISP (these blocks are said to be Provider Independent or PI). However, some of the larger tier 1 ISPs wouldn’t accept a route that small, forcing users to ask for IP space from the ISP (these were Provider Assigned or PA). Users were caught in a position where they had their own IP space but no way to connect to it or were using IP space from a single provider. This made it hard to create an alternate route through another provider or to get new numbers if they wanted to change service providers.

    Do you have a plan to expand your operations into IPv6?

    Posted in Bad Sites | Comments Off on The Ticking Time Bomb of IPv6 Migration

    I recently made up two nonsensical domain and—can you spot the difference between them?

    In a modern Unicode-capable browser, they are likely to appear identical but if you copy and paste each one into a search engine, you will get different results. The domain on the right was created using Cyrillic characters while the one on the left was created using Western characters. While most Cyrillic characters vastly differ from US-ASCII characters, a handful of symbols look at home in either character set (see page 2 of the chart).

    When viewed in hexdump, you can clearly see the difference between the two domain names. As shown, .com is written in ASCII code in both names (see Figure 1).

    Click for larger view Click for larger view

    I then created a simple HTML file with links to each domain name. Note that the ASCII domain name is italicized in the anchor tag while the Unicode domain name is not (see Figure 2).

    When I first pulled it up in Firefox 3.5, the character encoding was set to ISO-8859-1(Western) so the Unicode link clearly differed (see Figure 3).

    Click for larger view Click for larger view

    A quick change of my character encoding to Unicode(UTF-8), however, resulted in an altogether different scenario (see Figure 4).

    GIZMODO points out that this works with other strings as well. An attacker thus only needs to find commonly used code pages that they can use to piece together the characters they will need to spoof legitimate sites. In my brief testing, I found that using more than one Unicode block in a single URL produces unpredictable results.

    Recent discussions about the Internet Corporation for Assigned Names and Numbers (ICANN)’s approval of the use of internationalized domain names (IDNs) and how they can pose additional security risks have been ensuing. Some believe that allowing the use of IDNs can make antiphishing efforts harder.

    Simply put, IDNs work by converting Unicode strings into punycode strings before the browser queries a Domain Name System (DNS). For instance, the punycode version of is At, they have a handy tool for converting Unicode strings into punycode and back.

    It took some digging but I did find a few registrars that support punycoded domain names on existing top-level domain names (.com, .net, etc.). Should a cybercriminal register, he/she can create a pass-through of the ASCII page and use email, instant messaging (IM), or social networking to entice users to click a Unicode link that will connect them to a look-alike phishing page. Simply double-checking a site’s name may thus no longer be enough.

    If you want to see how real IDNs react in your browsers and other tools, take a look here for some active samples.



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