Have you ever noticed how security often takes a backseat when trying something new? When I am trying out a protocol out for the first time, I barely skim the Security Considerations section of the RFC. Just the same, as more of us start experimenting with IPv6, the use of tunneling protocols is likely to rise. That is good for IPv6 adoption but not so hot for security.

I certainly don’t want to discourage anyone from trying IPv6. In fact, I would rather see folks testing the waters now, trying it out and getting comfortable with it, than thrashing and flailing when ICANN announces the exhaustion of IPv4 pools. I do want to make sure everyone is aware of the risks involved so they can take appropriate precautions.

This article will only cover 6to4 (Wikipedia/RFC 3056) not to be confused with 6in4 and Teredo (Wikipedia/RFC 4380) tunneling protocols. A direct tunnel to your providers’ IPv6 systems does not present the same problems and risks as these public protocols do.

Both protocols focus on easing the transition to IPv6 and neither one claims to offer any significant security protection. In fact, the Teredo RFC goes so far as to call itself the IPv6 Provider of Last Resort. This label comes primarily from the crazy stunts required to successfully traverse multiple NAT gateways. However, it is worth considering some other factors as well. 6to4 comes with an entire RFC devoted to security considerations (http://tools.ietf.org/html/rfc3964). Remember, IPv4 firewall rules don’t do anything to IPv6 traffic.

6to4 tunneling requires that the user endpoint exist in publicly routable IP space and be directly reachable by any 6to4 serving device. One advantage of this exposure is that you can make use of more than just one 6to4 gateway, the obvious disadvantage being that you have to trust traffic coming from any address claiming to support the protocol for full functionality.

6to4 can also support routes to networks behind the endpoint. Endpoints are assigned an IPv6 address from the 2002::/16 prefix. The 4 bytes immediately following 2002: are the IPv4 address of the endpoint converted to hex. Thus, 192.168.25.200 would map to 2002:c0a8:19c8::/48 (RFC 1918 IP used for example only, it would be invalid in actual operation). It is reasonable to say that if one was going to create a server and publish it to the IPv6 Internet, it should also be fortified against both IPv4 and IPv6 threats. The take-away here is if you publish a 2002::/16 IPv6 address, we also know the IPv4 address of your endpoint.

Teredo is designed to work just fine with the remote endpoint behind one or more NAT gateways. Unlike 6to4, however, only one host can exist behind the endpoint. Right from the start, we need to worry about tunneling from the public Internet to a host inside a NATed environment. If the host is not well-protected, we could stop right there. We also have endpoint address leakage to contend with. Teredo goes even further than 6to4 by encoding the IPv4 exit point of the NAT gateway, the UDP port used by the external NAT session, and the IPv4 address of the tunnel endpoint used by the client. Some obfuscation is used, XORing UDP port and NAT IP with all 1s. However, this fact is well-known and will only protect you from people afraid of Wikipedia.

The base prefix for a Teredo IP address is 2001:0000::/32. Teredo client addresses are assembled as follows:

1. 2001:0000::/32 — base prefix
2. 2001:0000:c0a8:19c8::/64 — add IP address of the tunnel server (192.168.25.200 -> c0a8:19c8)
3. 2001:0000:c0a8:19c8:0000::/80 — add 16 bits of flags (0×00)
4. 2001:0000:c0a8:19c8:0000:8888::/96 — add external NAT port number XORd with 0xFFFF ( 30583 -> 0×7777 ^ 0xFFFF = 0×8888)
5. 2001:0000:c0a8:19c8:0000:8888:F537:76C8/128 — add external IP of NAT gateway XORd with 0xFFFFFFFF (10.200.137.55 -> 0×0AC88937 ^ 0xFFFFFFFF = 0xF53776C8)

Again, I don’t want to scare anyone off. Just know the risks and take appropriate precautions.

Happy IPv6ing!

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

Trend Micro researchers found spammed messages with a .ZIP file attachment that contains a malware. It bears the subject, “Contract of Settlements,” and purports to come from LSM Company. It informs users to open and check the attached file that holds a contract, which in actual fact, is an executable file (contract_1.exe) detected by Trend Micro as TROJ_FAKEALE.JH.

When executed in the system, TROJ_FAKEALE.JH connects to http://{BLOCKED}edrdosubor.com/K1er0Lj5n8H0NM4E8h0u where users get another FAKEAV variant, TROJ_FAKEAV.BQN.

Accordingly, users cannot scan the attached file because it is password protected. However, a password is included in the email to open the said file. This is probably to trick users into thinking that the said file is legitimate.

As usual, users are advised to refrain from opening any suspicious-looking emails. Trend Micro product users are protected from this spam attack via the Smart Protection Network. Non-Trend Micro product users can utilize HouseCall, Trend Micro’s highly popular and capable on-demand scanner for identifying and removing viruses, Trojans, worms, unwanted browser plugins, and other malware.

In the recent FAKEAV spam campaign, I realized something was off. Once the user clicks the URL and gets the bogus Antivirus 2010 up and running on his/her system, files are added. The additional files I found were related to ClamAV, the open source AV toolkit for UNIX. The files include the ClamAV virus definition file and some newly downloaded DLLs such as htmlayout.dll and pThreadVC2.dll. These files (DLLs and ClamAV definition file) are needed to run the open source antivirus software. So why are legitimate AV-related files included in the routines of a FAKEAV malware?

The files arrived from the first download routine of the FAKEAV installer. It also drops randomly named garbage files into the system that will later be detected as “infected.” Curious about all this, I downloaded the real ClamAV to further test if the fake scan was actually using the definition file to scan. After replacing the FAKEAV definition file for the latest one, it still detected the garbage files as “infected.” The second test I made was to take the FAKEAV definition file and run it in a real ClamAV scan against the files. However, it still showed the same results. Apparently, the ClamAV-related files were not being used at all.

The only conclusion I was left with is that the legitimate files are just a decoy to give a legitimate facade to the whole scam. Cybercriminals are also probably employing this tactic to avoid analysis behavior detection and removal. Some behavior-analyzing software might be deceived that the FAKEAV is real because of the legitimate antivirus files running in the system. I doubt it, but who knows? It might just work.

Microsoft’s new OS, Windows 7, was made available to the general public earlier today. To say that this was eagerly anticipated is an understatement, however, as in the United Kingdom, pre-orders on Amazon for copies exceeded both the last book of the Harry Potter series as well as the Nintendo Wii. This made it the biggest grossing pre-ordered item in the history of the online retailer’s British site.

Trend Micro Senior Threat Researcher David Sancho had this to say about the new OS:

Microsoft has been improving the security of its OS that is why there are fewer network vulnerabilities every time. Having said that though, security cannot be taken for granted and there’s always room for improvement. The Web is today the biggest infection vector therefore hardening the OS needs to be complemented with strengthening the browser and applications used to visualize Web pages (such as Adobe Acrobat, Flash, etc.).

Now, users may wonder if their Trend Micro products will work with Windows 7. The answer is yes. Programs such as Trend Micro Internet Security will work just as well in Windows 7 as in previous versions like XP and Vista. Whether users upgrade or stick with their current OS, they can continue to rely on their existing Trend Micro software. Even HouseCall, our free online scanner, will run under Windows 7.

In this most recent spam campaign, our spam traps caught an uncanny combination of a CapitalOne phish and a ZBOT variant. Below is a screenshot of an email sample making the rounds:

The spam campaign would have you believe that you would need to install a Digital Certificate in order to use CapitalOne’s website. Clicking on the email link brings you to the following site: This is the phishing part. After filling in the required login information, the website now conveniently gives you a download link to the supposedly digital certificate: The download link will lead you not to a digital certificate, but to a ZBOT variant. Running the so-called ‘digital certificate’ will only install the notorious ZBOT malware into your system, and will proceed to log your keystrokes, steal personally-identifiable information, and most especially, steal your personal financial information. Trend Micro now detects the said ZBOT malware as TROJ_ZBOT.CKA. The above website does not only host a CapitalOne phish, but also a Bank of America phish. Earlier this week, the same group also had a spam campaign, but was pushing a BoA phish: The phishing website in that campaign asks a lot of questions–three pages full of these. It basically asks all of your personal information pertinent to your banking account:

The websites for both the CapitalOne and Bank of America phishing attacks are all hosted on fast flux domains, and uses wildcarded subdomains. Here’s a list of some of the domains actually used:

• 11qioz.co.uk
• 11qwod.co.uk
• easder1q.co.uk
• f1iiitl.com
• iiizad1z.co.uk
• ij1tli.com
• ltiil1.com
• nekz1mqv.co.uk
• nezz1cza.co.uk
• racder1c.net
• racder1x.com
• raeder1f.net
• rarder1g.com
• raxsder1.com
• t1fliil.tc
• tj1fiil.co.nz
• uunuyr.com
• yyy1yyrd.co.uk
• yyy1yyre.co.uk
• yyy1yyrf.co.uk
• yyy1yyrg.co.uk
• yyy1yyrj.co.uk
• yyy1yyrk.co.uk
• yyy1yyrl.co.uk
• yyy1yyrm.co.uk
• yyy1yyro.co.uk
• yyy1yyrq.co.uk
• yyy1yyrr.co.uk
• yyy1yyru.co.uk
• yyy1yyrv.co.uk
• yyy1yyrx.co.uk

The IP addresses these fast flux domains point to are comprised of residential broadband IP addresses, suggesting that the machines serving the websites’ contents are hosted on compromised residential PCs. The current spam campaigns (digital certificate lure) and its corresponding websites (fast flux, wildcarded subdomains) share the same characteristics like last year’s SSL Certificate spam campaign. A screenshot of last year’s spam campaign is shown below.

It looks like as though the same group has reemerged using the same tactic they’ve used last year. Maybe last year’s campaign has been successful enough that they’re hoping to duplicate the winning formula in the recent spam wave.

Trend Micro users are now protected from this attack through the Smart Protection Network. Non-users of Trend Micro producs, on the other hand, can opt to stay protected by using the eMail ID and Web Protection Add-On.