Will IPv6 Cause Chaos for the Browsing Public?

Wednesday, January 19, 2011

Rafal Los

0a8cae998f9c51e3b3c0ccbaddf521aa

Tricking a person into clicking a link is the name of the game.

Whether you're installing a drive-by trojan malware via 0day, collecting revenue from pay-per-click schemes, or XSS'ing your way into their bank account - the goal of this game is to make money on that person.  

Let's face it, business is good.

Here's the question - as IPv6 becomes a reality (probably even in our lifetime...) for the general browsing public - what sort of new chaos will this create?  

Or does it even make any difference with the current encoding schemes that can be used to trick even the savvy web browser?

Current Methods of URL Trickery

  • Faking Authentication - Using a trick from basic authentication (something most users won't recognize anyway) a trickster can push out a URL like http://www.goodsite.tld@xxx.evilsite.tld with the user being none-the-wiser. In most cases, the average user won't look past the @ as they wouldn't know how to treat or understand that.  This is an all-too-common method in modern URL trickery
  • URL (Over)Encoding - While many people in security are familiar with the concept or URL encoding for securing against Cross-Site Scripting (XSS) an interesting way to obfuscate and obscure a URL against someone being able to read it is by converting everything in the URL line not just the special characters.  This is of course entirely unnecessary - but it's a great way to make sure that someone can't easily tell what they're clicking on until the browser converts it and it's too late... as an example -http://www.google.com becomes http://%57%57%57.%47%4F%4F%47%4C%45.%43%4F%4D (try it!)
  • Fun with Math - Variations on this include dotted octal format, dotted hexadecimal, or converting the entire string to a single number.  So using one of Google.com's IP addresses it would look something like this (using a quick converter[2]): dotted octal (http://0321.0125.0341.0143), dotted hexadecimal (), and single decimal (HTTP://3512066403) - and they all resolve the same... 

Combinations of these and variations of course are quite common too!  Let's not even mention extended character sets with Unicode transformations and ASCII best-fit mappings [3] best presented by Chris Weber, which there has been extensive work in, and which has fooled even the most technically savvy security person (myself included!).

It's downright scary

What does IPv6 Add?

In a word ...nothing that exciting.  Things get slightly more complicated for the user - and where we had IPv4 addresses that people started to recognize (not really, but at least those that were tech-savvy could) such as http://10.1.1.0/index.html, you will now start seeing monstrosities like this[4]:

http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html

Can you imagine trying to figure out if that's really your web server, or some what?  Since the rules are all different such as CIDR notation and netblock allocation, it's going to be an entirely different ball game.  Then again - so what, it's been a mess from the start!

So what's really changing?  Complexity is going to ratchet up, the tricks will likely increase and the user will probably get roped into clicking on more dangerous things.  Sounds like the nightly weather forecast, doesn't it?  More bad things... think the users will notice?

References:

[x] http://www.faqs.org/rfcs/rfc2732.html

[2] http://www.csgnetwork.com/ipaddconv.html

[3] http://www.casaba.com/blog/2010/12/list-of-characters-for-testing-unicode-transformations-and-best-f...

[4] http://www.ietf.org/rfc/rfc2732.txt

Cross-posted from Following the White Rabbit

Possibly Related Articles:
8017
Vulnerabilities
XSS fraud Authentication Trojans malware IPv6
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.