These are quick first looks and trend and threats


Read More >>
Written by the security and AV professionals from team K7, meant for the general audience
Read More >>
These are usually articles that go into internals of a virus or deal with security issues
Read More >>
Senior managers speak on areas of interest to them, inside and outside the industry
Read More >>

Archive for the ‘Personally speaking’ Category

Why You Should Not Pay That Ransom Demand

Wednesday, June 10th, 2015

Ransomware attacks appear to be ubiquitous. Ransomware is a type of malware which denies access to your computer resources, say by encrypting your personal documents, until a hefty sum is paid to the criminal gang which caused the infection. We recently blogged about two examples of ransomware, namely CTB Locker and TeslaCrypt.

We constantly advise against paying anything to the malware syndicates for two primary reasons:

  1. Generating income for these cyber crooks would only serve to incentivise their criminal activities, and would fuel their future attacks.
  2. There is absolutely no guarantee that paying up the ransom of potentially hundreds of dollars would actually restore your files.

In this blog we will focus on the latter point, drawing on a real-life case study involving a friend of mine.

A few weeks ago my friend (not a K7 user at the time) was, unfortunately, struck hard by a ransomware pretending to be the mother of modern ransomware, the infamous CryptoLocker. The above image is a screenshot of the ransom demand which was splashed on his screen. The ransomware was not, of course, CryptoLocker, but yet it was lethal enough, encrypting my friend’s personal files with advanced algorithms. The sample was packed with a custom NSIS SFX wrapper which has been used by CTB Locker in the recent past, suggesting a potential link between the two strains of ransomware.

My friend did not care too much about his local files which were hit. However, as (mis)fortune would have it, his plugged-in external drive containing the early photos of his kids was ravaged. Ransomware tend to enumerate and modify as many target files on as many drives as possible. By targeting personal or confidential files such as images, Microsoft Office documents, etc., the criminal elements increase the pressure to pay up. Even police departments have occasionally felt compelled to part with funds.

Given the importance of the images on his external drive, my friend was prepared to satisfy the ransom demand to the tune of US$ 237; no piddling amount. I had urged him against paying up, arguing the case based on the points made above. However he felt that if there were any chance of getting his kids’ pictures back he would have to give it a try.

A couple of days later, after having secured the requisite bitcoin, the ransomware kicked into action displaying a status bar and claiming it was in the process of decrypting all the files it had encrypted earlier. Many hours later, having left the “decryption tool” to do its business overnight, my friend assumed his files had been restored. However he was unable to open most of the images and the documents he attempted to view. I offered to look at the files at the binary level to determine whether any data could be recovered.

He sent me several example files which were failing to open. My analysis showed that for many files absolutely no attempt had been made to decrypt them since they had no visible headers. In other cases some headers were visible but large chunks of the files remained garbled junk. Such was the extent of the damage to the image files that even clever image-fixing-software was not able to recover anything.

To cut a long story short, despite coughing up more than US$ 237, my friend was yet unable to recover his kids’ photos. The moral of the story is: refrain from paying these nasty criminals in any way, shape or form. They are hardened thieves without any sense of compunction or honour, so please do not be fooled by apparent largesse.

As always we highly recommend taking regular backups of your important files on media which are not constantly connected to your computer (external media and/or on online repositories), thus, in the event of a ransomware attack, you could still have your files without paying the bad guys a single paisa.

Samir Mody

Senior Manager, K7TCL

If you wish to subscribe to our blog, please add the URL provided below to your blog reader: http://blog.k7computing.com/feed

ACTing for National Security: Provisions in IT (Amendment) Act 2008

Tuesday, May 26th, 2015

In our previous blog, we mentioned that it might be beneficial for Indian netizens to have a high-level understanding of existing cyber laws that are articulated to protect them. We did write about certain activities deemed to be illegal and the punishments for them.

Today, we provide a bird’s eye view of how the Information Technology (Amendment) Act 2008 aims to safeguard national security. The following provisions, illustrated with an image and its associated description, are the highlights of the Act vis-à-vis national security:

The Act also deals with cybercrimes deemed to be perpetrated by foreign actors, i.e. beyond the “Cyber Line of Control”

  • Section 75(1 and 2) applies to foreign nationals if contravention of the Act involves Indian computer resources.
  • Intermediaries providing computing services are also liable.
  • Part III includes amendments to the IPC specifically related to attacks beyond Indian borders.

Policing cybercrime is an extremely difficult task even within India’s bounds, leave alone beyond them. It is critical for Indian cyber sleuths to establish mutually cooperative relationships with law enforcement agencies in other countries to fight cybercriminals and bring them to justice.

Once again, we hope this blog helps netizens to understand the provisions in the IT (Amendment) Act 2008.

Some images (adapted to suit the article) are courtesy of several sites.

Samir Mody
Senior Manager, K7TCL

If you wish to subscribe to our blog, please add the URL provided below to your blog reader: http://blog.k7computing.com/feed

Cyber Crime and Punishment: Provisions in IT (Amendment) Act 2008

Friday, April 17th, 2015

In a previous blog we mentioned that it might be beneficial for Indian netizens to have a very high-level overview of how existing cyber laws are meant to protect them.

The Information Technology (Amendment) Act 2008 has provisions to enable cyber policing, thereby attempting to ensure cyber security, which is defined thus:

“cyber security” means protecting information, equipment, devices, computer, computer resource, communication device and information stored therein from unauthorised access, use, disclosure, modification or destruction

The following images describe activities which are outlawed in the aim of ensuring cyber security:

Anyone found indulging in any of the above illegal activities would attract stiff punishment as mentioned below:

We hope this provides netizens with a better understanding of the provisions in the IT (Amendment) Act 2008. We will continue to explore more niche aspects of the Act in our upcoming blogs.

Images are courtesy of several sites including:
botandbotnets.weebly.com

Samir Mody
Senior Manager, K7TCL

If you wish to subscribe to our blog, please add the URL provided below to your blog reader: http://blog.k7computing.com/feed

Section 66A RIPped by Honourable Supreme Court of India

Wednesday, March 25th, 2015

The controversial Section 66A of the Information Technology Act 2000 (Amendment 2008) has been struck down by the honourable Supreme Court as unconstitutional vis-a-vis Article 19 (Right to Freedom) of the Constitution of India. The honourable Supreme Court has deemed Section 66A to be “nebulous”, and its decision is no doubt related to the numerous high-profile incidents across India related to citizens posting allegedly overly-sensitive content online.

Most netizens are probably completely unaware of Indian cyber laws. Perhaps this is an opportune occasion to provide readers with a short blog series deconstructing the Indian IT Act, focussing on its cyber policing aspects. After all it is important to understand at a high level how existing cyber laws are meant to protect citizens by enhancing IT security.

Samir Mody
Senior Manager, K7TCL

If you wish to subscribe to our blog, please add the URL provided below to your blog reader: http://blog.k7computing.com/feed

SOCK! BASH!! SLAP!! PINCH! Battling Vulnerability Fatigue!

Wednesday, October 15th, 2014

Whilst the ghost of Shellshock still haunts everybody two diametrically opposite vulnerabilities have made the headlines over the past 24 hours or thereabouts:

  1. CVE-2014-4114, a remote code execution vulnerability in the Microsoft OS’s rendering of certain OLE objects, actively exploited in the wild, allegedly by Russian threat actors
  2. CVE-2014-3566, effectively a data leak vulnerability in SSL 3.0 for which a PoC attack to steal secure session cookies has been described by the discoverers of the vulnerability at Google

Let’s discuss CVE-2014-4114 first since its impact is more severe given the remote code execution aspect and the evidence of malicious exploitation in the wild. The good news is that Microsoft has issued the patch for this vulnerability as of yesterday. As members of the Microsoft Active Protections Program (MAPP), we at K7 have also received more information about how the vulnerability can be exploited. We have already secured protection against known bad exploit files, and a heuristic fix is ready, but as an additional paranoid step, if you have the K7 product with firewall installed, it should be possible to add a carefully-configured firewall rule for Microsoft Office OLE rendering applications, e.g. POWERPNT.EXE, EXCEL.EXE and WINWORD.EXE, to prevent them from accessing remote network locations, thus mitigating against the silent download and rendering of malicious files.

Now then, CVE-2014-3566; the Google PoC describes a Man-in-the-Middle attack which can be used to steal a supposedly secure session cookie (but this can be any encrypted data) IF the encryption channel is SSL 3.0 based. Serious as this sounds, CVE-2014-3566 is not as potent as the bash vulnerability suite, and not as valuable as Heartbleed in the grand scheme of things. The reasons for this is that there are several mitigating factors:

  1. The communication has to be via SSL 3.0 which is an antiquated, discredited protocol long since replaced by the more secure TLS. Of course client-side browsers may be duped into believing that the server supports only SSL 3.0, and therefore switch to this protocol
  2. The attacker has to insert himself/herself between the client and the server in order to control the format of the traffic and derive the tasty data byte-by-byte
  3. The encrypted traffic itself, separated into blocks, needs to lend itself to the attack in the sense that certain content deemed interesting to the attacker must be at deterministic locations in the encrypted blocks, with a rinse and repeat function as part of the modus operandi.

At the recently-concluded Virus Bulletin 2014 conference, at which we were Shellshocked for the first time, the managing of vulnerability disclosures was extensively discussed. The above couple of vulnerability disclosures have been suitably managed, minimising the impact on the general public.

Samir Mody
Senior Manager, K7TCL

If you wish to subscribe to our blog, please add the URL provided below to your blog reader:

http://blog.k7computing.com/feed

https://icann-deal.with.it (Part 3)

Thursday, October 9th, 2014

This is the final part of a three-part blog based on my paper for AVAR 2012 that discusses the security challenges involved in adopting two relatively new technologies, namely, Internet Protocol Version 6 and Internationalized Domain Names.

Continuing from the second part of my paper..

Social Engineering. Malware authors/Spammers/Phishers who now have a larger character set to play with are likely to register domains resembling an original site to trick users into divulging information.

Fig.10 below shows the domain information for baidu.com and an IDN equivalent. Considering that the name servers, the e-mail address used to register the domain, etc, do not match, even security savvy users are likely to find it tricky to validate a URL from such IDNs before visiting it.

Fig.10: whois information on the original baidu.com and the squatted IDN version

Thanks to social networking sites like Facebook, twitter etc., which enable instant sharing of information among millions of users from different backgrounds, uncommon URLs could invoke a click from curious users even if they don’t recognise the character set. Malware campaigns such as these, though short lived, could still cause enough damage globally.

Fig.11: Representative example of an attack based on socially engineered IDNs

Matching Incongruence

URL scanners could focus more on consistency or the lack thereof while dealing with phishing and malware related URLs arriving from IDNs. Language mismatch between the message body of the e-mail and the URL, or the URL and the contents of the page that the URL points to, can be deemed suspicious.

Restrictions may be imposed on visiting IDNs which don’t match a user-defined list of allowed languages. Similarly, domains created by combining visually similar characters from different character sets can also be curbed. Popularly known as a Homograph attack, most common browsers already defend users against such threats. While this protection is only limited to within the browser, it can be extended to protect e-mail, social networking and other layers as well [12].

Fig.12 below shows two domains, one created entirely using the Latin character set and the other using a combination of Latin and Cyrillic character sets. Though both domains visually appear to be similar, their Puny Code representation proves otherwise.

Fig.12: Example of two visually similar domains and their Puny Code representation [13]

Security vendors could also continue existing practices of assigning a poor reputation to domains that originate from certain high-risk countries. Such domains are usually created due to nonexistent or inadequate cyber laws in the host country, which result in malware authors abusing them. Reputation can also be assigned to registrars of IDNs based on their commitment to handling abuse reports, enforcement and verification of registrant details, ease of registering domains in bulk, etc.

A solution to address the e-mail spam problem could involve creating a white list of registered mail servers. The Ipv6whitelist.eu project, for example, works on the assumption that all computers send out spam, unless they have been previously registered on the white list [14]. In addition, since there are few mail servers catering to a significantly large user base, one could argue that e-mail could continue using IPv4, which could breath new life into the practice of IP blacklisting, at least for e-mail spam.

There is a Certainty in Uncertainty

The implications of the transition from IPv4 to IPv6, and the introduction of IDNs, are bound to be of major significance to the Internet infrastructure. These changes engender the continuous growth of the Internet by accommodating an increasing number of inter-connected devices, and variegated foreign languages.

As with any change, given the absence of a crystal ball, the move to these new technologies involves risk.Without doubt spammers, phishers and malware authors, seeking to make a quick buck, will exploit the larger attack surface provided by a vastly increased IP address space and language diversity via IDNs. We in the AV industry must take cognizance of this to determine the security implications and forge robust solutions.

As discussed in this paper, the new technologies will put pressure on current methods to counter spam, phishing and malicious URLs, especially where reputation is of prime importance. Fortunately, AV vendors have generally been able to adapt to the regular inflow of new issues, with new responses for these constantly on the anvil.

The changes about to be witnessed and the solutions proposed are likely to have security companies relying heavily on aggressive heuristics and policy-based restrictions, which could increase the number of false positives. However in corporate environments, rules can be configured to suit the risk appetite of the user in question.

Things are about to get a whole lot more difficult. However, greater vigilance, user education, and as ever, timely security industry data sharing, will help in controlling the fallout. The challenge is indeed a major one, but it is certainly not insurmountable. we.can.deal.with.it

References:
[12] http://en.wikipedia.org/wiki/IDN_homograph_attack#Defending_against_the_attack
[13] Information on http://en.wikipedia.org/wiki/IDN_homograph_attack
[14] Information on http://www.ipv6whitelist.eu

Lokesh Kumar
K7 Threat Control Lab

If you wish to subscribe to our blog, please add the URL provided below to your blog reader:
http://blog.k7computing.com/feed/

https://icann-deal.with.it (Part 2)

Thursday, September 4th, 2014

This is the second part of a three-part blog based on my paper for AVAR 2012 that discusses the security challenges involved in adopting two relatively new technologies, namely, Internet Protocol Version 6 and Internationalized Domain Names.

Continuing from the first part of my paper…

Internet Metamorphosis

The Internet is witnessing a critical phase in the transition from an old technology to a new one, and users must understand the security implications involved. These implications could manifest themselves either during the implementation stage or after.

Tunnel Vision. IP tunnelling implementation involves encapsulating the IPv6 packets into IPv4, which is similar to creating a Virtual Private Network (VPN). Teredo, for example, is a tunnelling protocol that is installed by default on Windows Vista and Windows 7 operating systems, and provides IPv6 connectivity to a native IPv4 device [7].

Fig.4: Example of tunnelled IPv6 traffic[8]

Since the IPv6 contents are disguised inside the IPv4 packets, most security devices struggle to analyse and detect them. This in turn opens the door for attacks when these tunnels are used to transport malware.

There have been known instances of malware which enable IPv6 on a compromised host to communicate with its creator using these IP tunnels. The fact that IPv6 is enabled by default on most new operating systems makes it easier for malware to spread without being noticed. The infamous Zeus, for example, is known to support IPv6 from early 2010 onwards. This malware not only boasts of having the capability to sniff IPv6 traffic, but also supports an IPv6 Peer-to-Peer network [9].

Stack ’em Up. Dual Stack Implementation involves running both IPv4 and IPv6 in parallel, with one protocol taking preference over the other. Communication is done using the preferred protocol first, failing which it is retried using the secondary protocol.

Fig.5: Example of dual stack traffic[8]

Considering that communications happen natively either in IPv4 or in IPv6, and that both protocols co-exist in the network, until sufficient machines become IPv6 compliant, at which point IPv4 can be pensioned off, this is the preferred method of transition.

To NAT or Not. Network Address Translation (NAT) is a technique that allows multiple devices within an internal network to get online by sharing a single public IP address. This public IP address would be provided to a router at the gateway level, which in turn directs traffic to machines inside the network that use non-routable IP addresses.

On a small scale, NAT is used within a Small Office Home Office (SOHO) environment, and on a large scale, often referred to as Carrier Grade NAT (CGN), it is used by ISPs who have a limited number of IPv4 addresses.

Fig.6: Simple implementation of NAT within a SOHO environment

Apart from cutting down on the number of routable IPv4 addresses used, this technology also provided a certain degree of privacy and security to the users in the internal network. Automated port scans and information gathering attempts are deterred at the gateway, and would only succeed from inside the private network.

The gargantuan number of addresses available in IPv6 means that ISPs could technically do away with NAT, and assign a static IP address to each of its users, and yet never run out of addresses in the foreseeable future.

While this would promote end to end connectivity, which was how the Internet was originally envisaged, it could also open up the flood gates of machines which were never previously directly connected to the Internet, for now they would be vulnerable to prying eyes and groping hands.

The silver lining, however, is that since an IPv6 address can now be mapped to each user, tracking down malicious traffic & the victims of a malware incident also becomes easier. It could be a boon or a bane, depending on how one perceives it.

The Whois Who of Malware URLs , Phishing & Spam

Over the years as communication media within the Internet expanded from e-mails to other forms such as instant messaging, forums, blogging, social networking, etc., spammers followed suit with campaigns targeting these channels. These campaigns include the relatively innocuous comment spam posted in blogs/forums, Pump ’n Dump scams, attempts to sell Viagra and the like, phishers vying for sensitive user information, and malware related spam which go for the jugular.

The current volume of spam received via various communication channels is kept to a minimum thanks to a combination of techniques which involves, but is not limited to, content based and list based filtering. Given the plethora of malware URLs and spam messages disseminated everyday, most of this filtering is done using automated systems.

Fig.7 below shows a steady rise in the number of malware/phishing URLs for the first half of the year 2012

Fig.7: Number of malicious URLs crawled by K7 from January 2012 to June 2012 [10]

Content Based Filtering. This works on analyzing different characteristics of a message or a URL. For example, messages with keywords such as Viagra, Rolex, etc, somewhere in the MIME envelope could automatically be declared as spam. Similarly, a URL with words like PayPal or Facebook in the sub-domain component, combined with a recently registered domain name having a minimum validity can be deemed suspicious. However, when these keywords are represented in another language, automated content based filtering could become more challenging since we would now have to recognise the representation of a keyword in as many different character sets or Puny Code equivalents, as possible.

List Based Filtering. This aims to assign a reputation to the source of the e-mail message or the URL. For example, when a stream of messages detected as spam originates from a single IP address, that address may then be assigned a bad reputation, and would go into a blacklist. Similarly, a malicious domain or IP could go into this list.

Subsequent messages from a blacklisted IP address would automatically be labeled as spam & dropped when e-mail servers query the blacklist in real time. Likewise, URLs containing blacklisted domains or IP addresses would also be blocked as malicious.

Fig.8: One blacklisted IP address used to both send spam and host malware [10]

Once a domain/IP address gets blacklisted, the attacker shifts to a new address from which to send the spam or on which to host malware until that gets blacklisted too. They do this by either releasing and renewing their IP from their service provider, if the machine used to send the spam or host the malware is physically owned and controlled by them, or by selecting a new bot, a machine from their botnet consisting of many infected machines, from which to send the spam vicariously or to host malware on the attacker’s behalf.

On an IPv4 network the attacker has a theoretical maximum of only 4 billion addresses to cycle through. This number increases manifold within an IPv6 network. The increase in the number of domain names, due to the introduction of IDNs, is also likely to add to the blacklist woes, especially when these domains originate from an IPv6 network.

Fig.9 below shows the steady rise in the number of IDNs in the first half of the year 2012. Though currently small, the numbers are expected to increase significantly over time.

Fig.9: Number of malicious IDNs crawled by K7 from January 2012 to June 2012 [10]

Another problem with respect to blacklists is the amount of disk space occupied by these lists and the time taken to look them up. Even in the case of the relatively impoverished IPv4, assuming that all 4 billion addresses get blacklisted, a flat CSV file containing all these addresses occupies a minimum of approximately 60 Gigabytes of disk space on a Unix platform [11]. Consider further the amount of time taken in creating, maintaining, and querying such a big database in real time. Such a system would be nigh on unworkable for IPv6.

Click here to read the third part of this blog.

References:
[7] Information on http://www.us-cert.gov/reading_room/IPv6Malware-Tunneling.pdf
[8] Information on http://www.cybertelecom.org/dns/ipv6_transition.htm
[9] https://blog.damballa.com/archives/438
[10] Internal data
[11] http://www.circleid.com/posts/digging_through_the_problem_of_ipv6_and_email_part_1

Lokesh Kumar
K7 Threat Control Lab

If you wish to subscribe to our blog, please add the URL provided below to your blog reader:
http://blog.k7computing.com/feed/

The Awesome Power of Nature

Tuesday, September 2nd, 2014

No, there’s no new sobriquet for some obscure “Advanced Persistent Threat”. Instead, via the medium of this blog we at K7 Threat Control Lab would like to invite you into our space, both physical and mental, to better introduce ourselves, thus dispelling certain stereotypes associated with lab personnel.

K7 Computing is now 22 years old. Hoorah!! In celebration of this momentous milestone several departments, formed into teams, devoted space and time to decorate parts of our head office (in Chennai, INDIA) based on assigned themes.

The theme assigned to the lab team (TEAM RED) was “Nature” so we decided to depict her awesome power, highlighting the non-negotiable limits on human expropriation and control. Within the confines of the Threat Control Lab we modelled an earthquake, a tsunami, a tornado, thunder and lightning, and a volcano.

The photo below shows our version of a “volcano” constructed smack bang in the middle of the Threat Control Lab, for which we temporarily commandeered the overhead monitors that are meant to display real-time threat intelligence data:

Image courtesy of Kaarthik, Threat Researcher, K7TCL

Note, no aircraft were affected in any way by our volcano despite the tons of “aish“.

Samir Mody
Senior Manager, K7TCL

If you wish to subscribe to our blog, please add the URL provided below to your blog reader:

http://blog.k7computing.com/feed

“Now You See Me, Now You … Errr … See Me”

Wednesday, August 6th, 2014

Much has already been written about Win32/Poweliks, the touted fileless persistent malware.

The malware uses an embedded NUL within the key under the following registry path:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run

This non-standard use of NUL as part of the key name is not new. A similar trick was likely used by variants of more advanced malware such as ZeroAccess, when creating helper files on disk. Regedit, a usermode process, is unable to read this keyname, but it doesn’t mean the entry is invisible. In fact K7′s rootkit scanner reveals the key with ease:

The other important point is that the infection chain involves a malicious Microsoft Office document containing a dropper Windows executable file, both of which must exist on disk as normal files, albeit ephemerally, and executed before the above-mentioned registry entry can be created. This provides a fleeting opportunity to detect these vital components easily, and detect them we do as

Trojan ( 0001140e1 )

and

Trojan ( 0049882d1 )

respectively.

The techniques used by the malware to execute a JS-decoded DLL via a registry entry are indeed interesting, but there are still quite a few opportunities to flag the infection at various stages of the infection chain, including at the entry spam email stage itself. It remains to be seen if the malware evolves to employ more sophisticated techniques in future.

Samir Mody
Senior Manager, K7TCL

If you wish to subscribe to our blog, please add the URL provided below to your blog reader:

http://blog.k7computing.com/feed

https://icann-deal.with.it (Part 1)

Tuesday, July 22nd, 2014

This is the first part of a three-part blog based on my paper for AVAR 2012 that discusses the security challenges involved in adopting two relatively new technologies, namely, Internet Protocol Version 6 and Internationalized Domain Names.

The Internet landscape is about to witness profound changes with the mass adoption of Internet Protocol Version 6 (IPv6) and Internationalised Domain Names (IDNs) in the near future. While these developments have the potential to be immensely beneficial, they also present certain challenges to the security industry which need to be addressed. These changes not only increase the attack surface for malware authors and spammers, but also render traditional methods of URL and spam blocking obsolete.

The exhaustion of the 32 bit IPv4 addresses assigned by the Internet Assigned Numbers Authority (IANA) has led to the roll-out of its 128 bit successor, IPv6. This provides a significant increase in the address pool available to assign unique IP addresses, not only to computers, but also to other Internet-connected devices. Spammers and malware authors would now have a larger address space to infect and cycle through, vitiating existing methods of detecting spam/malware URLs.

The Internet Corporation for Assigned Names and Numbers (ICANN) has expanded domain names to include non-ASCII based IDNs in a user’s native language script. While these transitions have the potential to localise the global Internet, they also provide cyber criminals (spammers/phishers/malware distributors) enhanced opportunities for exploitation, especially via social engineering.

These cyber criminals will now have the ability to redirect a user to a URL with a character set unfamiliar to him/her. Given the exponential increase in the number of URLs shared among users in our socially inter-networked world, validation of these URLs by the user prima facie now becomes much more complicated, leading to a higher compromise success rate for cyber criminals.

This paper describes the imminent major changes to the Internet networking infrastructure. It attempts to explore the security challenges involved in these milestone developments and presents potential solutions to address them.

The IPv4 Clock is Ticking

The expansion of the Internet from an esoteric academic project to a publicly accessible resource, coupled with the surge of Internet enabled devices over the last decade have contributed to the shrinking pool of available IPv4 addresses.

Fig.1 depicts the number of expected Internet enabled devices and Internet users by 2016, and how they measure up with the number of IPv4 addresses available.

Fig.1: Number of connected devices & Internet users by 2016 [1]

Conservation efforts like Network Address Translation (NAT), Classless Inter Domain Routing (CIDR), reclaiming unused addresses etc., only prolonged what was unavoidable – the depletion, and eventual exhaustion, of IPv4 addresses.

Given that ICANN, which is responsible for distributing IP addresses, gave away the last block of IPv4 addresses to the five Regional Internet Registries (RIR) in early 2011 [2], the need for change is rather pressing.

IPv6 to the Rescue

This IPv4 address crunch has been anticipated for many years, and the Internet Engineering Task Force (IETF) has been working on refining IPv6, the successor to IPv4, since the early 1990s [3]. This version of the Internet Protocol can support up to 300 undecillion addresses compared to the relatively miniscule 4 billion, a number smaller than the current world population, offered by its predecessor. Apart from this massive increase in the address space, the IETF also embedded other features to IPv6 such as support for IPSec, auto-configuration of devices, etc. [4]

These benefits, along with the availability of IPv6 from ISPs, increased end-user device support & IPv6 content, will ensure the adoption of IPv6 in the years to come, eventually making it the dominant Internet Protocol.

Fig.2 shows that, as expected, the percentage of users accessing Google over a native IPv6 connection has seen a steep rise over recent times.

Fig.2: Percentage of IPv6 users accessing Google [5]

What’s in a Domain Name

The demand for Internationalised Domain Names (IDNs) has always existed in view of the fact that 60% of the countries around the world have an official language other than English [6]. ICANN, which has domain names within its remit, has recently started allowing IDNs to satisfy this unmet demand.

The introduction of IDNs allows non-ASCII character sets like Arabic, Cyrillic, Tamil, Hindi, Chinese, etc, to be included in a domain name, potentially paving the way for a truly globalised Internet.

These IDNs are converted into ASCII using Puny Code, an encoding syntax invisible to the user, which allows for standard domain name resolutions.

Fig.3 shows a domain name in English, its nonexistent IDN equivalent in the Tamil script, and the Puny Code representation of the IDN which is used for a domain name resolution.

Fig3: Domain Name, IDN, Puny Code representation

The current demand for IDNs, combined with registrars throwing them away at a price cheaper than the regular domains, could see a surge in the number of non-English sites registering domain names in their local language.

Click here to read the second part of this blog.

References:
[1] http://www.google.com/intl/en/ipv6/images/graph.png
[2] http://en.wikipedia.org/wiki/IPv6#Exhaustion_of_IPv4_addresses
[3] http://en.wikipedia.org/wiki/IPv6#Working-group_proposal
[4] Information on http://en.wikipedia.org/wiki/IPv6
[5] http://www.google.com/intl/en/ipv6/statistics.html
[6] http://en.wikipedia.org/wiki/List_of_countries_where_English_is_an_official_language

Images courtesy of icann.org & worldipv6launch.org

Lokesh Kumar
Manager, K7 Threat Control Lab

If you wish to subscribe to our blog, please add the URL provided below to your blog reader:

http://blog.k7computing.com/feed/