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

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/

Don’t Let Heartbleed Give You Nosebleed

Thursday, April 24th, 2014

Much has already been written about the infamous Heartbleed vulnerability (CVE-2014-0160), the best technical piece being on Cloudflare’s blog. Unfortunately, as always in such cases, there has also been a lot of junk spewed out causing undue panic amongst the masses. A glaring example of this was a recent article in a well-known Indian daily newspaper reprehensibly titled the “Heartbleed Virus”, at which point one ought to stop reading the article.

Heartbleed is NOT a virus! It cannot spread from machine to machine, from device to device, and it cannot directly damage your computer. That is not to say that Heartbleed is not a serious issue. It is! Rather, the gravity of the situation very much depends on who you are. If you are an average individual surfing the internet on your home computer, one could argue that Heartbleed is unlikely to affect you very much. We must perforce qualify this opinion.

Heartbleed is a vulnerability in the OpenSSL library, which is used to encrypt vast amounts of internet traffic to protect it from being snooped upon, unless the NSA is involved that is. The SSL/TLS protocols use Public Key Infrastructure (PKI) which is a proven technology for achieving Pretty Good Privacy, and hence is ubiquitous on the internet. Heartbleed, by potentially allowing the exposure of private keys on a secure webserver to a remote attacker, threatens the integrity of PKI-protected communication over a network. One could picture a heavily-reinforced steel vault, with the master key visible under the door mat outside.

It would be entities such as corporates, governments, etc, that have webservers using a vulnerable version of OpenSSL that are most at risk of potentially revealing critical confidential data, especially private keys. If you are such an entity we urge you to upgrade your version of OpenSSL immediately, and make a call on revoking and reissuing your private keys. Unfortunately attempted exploitation of Heartbleed does not necessarily leave evidence behind, and the nature of the vulnerability is such that it may be virtually impossible to tell what, if any, data has been leaked. Note, the vulnerability itself has been around for a couple of years before its discovery.

Let us now address the risk posed to the individual surfer. Although there is indeed some risk of your password and other data being leaked from some website you have logged into if the server hosting the site was being targeted, the chances are rather slim. This is because successful Heartbleed exploitation tends to reveal only ephemeral data, and on a webserver hosting a popular site with several concurrent logged-in sessions, especially one where the average individual logs out after visiting the page (assuming this frees up the session resources on the server for the next user), the probability of leaking confidential data, and that too data specifically pertaining to you, is low. Notwithstanding, to be on the safe side, you may yet wish to change your passwords if the site in question has admitted to being vulnerable earlier and has since patched the flaw. After all, based on GitHub’s advice, we in the Taggant Library Maintenance Committee (part of the IEEE Anti-Malware Support Service) did change our passwords for the following repository:

https://github.com/IEEEICSG/IEEE_Taggant_System

In addition client-side devices, including those running certain versions of Android (reportedly 4.1.0 and 4.1.1), could also be vulnerable to Heartbleed-based data leakage, and ought to be patched ASAP, even though exploitation on the client side is an even more remote possibility.

Images courtesy of:

heartbleed.com
forums.warpportal.com/index.php?/topic/131907-ragnarok-roll-cosplay

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

VAIN Vote for Industrial Action

Tuesday, April 1st, 2014

Virus Authors’ International Network (VAIN), the body looking after the interests of malware authors around the world, has unanimously voted for strike action with immediate effect. The number of malware written today, the 1st of April 2014, could be badly affected.

Otto Runn Würm, General Secretary of and spokesperson for VAIN, said

“It’s about job security, pensions, … and, of course, about better conditions in jail. Our members seek comfort at all times.”

Unfortunately malware writing services are expected to return to normal by tomorrow, if they haven’t done so already.

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

Click Without a Trace

Friday, March 2nd, 2012

The recent outbreak of the Xpaj virus in India due to the mass distribution of certain infected software provided me with an incentive to look at the virus code in a bit more detail.

Xpaj is not a new virus. It is at least a couple of years old and it has already been written about by my security industry colleagues. However there may be some space for me to provide my views on some of the technical aspects of this virus.

Xpaj is a midinfecting, polymorphic virus with a difference. Most viruses, including the common ones like Virut and Sality, leave behind clear, tell-tale signs, sometimes infection markers, in the infected host to indicate that there is something amiss. For example the entrypoint being modified to point to the last section which has rwx attributes smells somewhat rotten. Xpaj, however, is very clever in making all the modifications in the host whilst remaining extremely well camouflaged.

Changes to the code and data sections have been managed so that all looks normal:

  1. The original EP remains unchanged. Xpaj is a midinfector which patches certain relative calls in the host file’s code.
  2. There are no changes made to the attributes of any section. The required page permission changes are invoked dynamically via a call to ZwVirtualProtectMemory.
  3. Sections after the one containing the bulk of the virus are shifted down with ease, and corrections are made in the metadata areas, including relocating the resources, if any.
  4. Xpaj has no problems infecting DLLs with relocations, and can infect SYS files which run in kernel mode.
  5. Even the clusters of polymorphic virus code in the host file’s code section looks like bona fide High-Level Language (HLL) code.

Here is an example of some of the Xpaj code pointed to after judicious host-call-patching:

The above snippet conforms to HLL patterns in certain files compiled with Microsoft Visual C++ 8.

The virus code goes on to execute a mini virtual machine which does the decryption and makes the call to ZwVirtualProtectMemory before transferring control to the bulk of the virus code.

The Xpaj virus authors went through a lot of trouble, including a fair amount of QA, to develop their “product”. Xpaj is indeed a sophisticated virus. Of that there is no doubt. It demonstrates the lengths to which malware authors are prepared to go to spread obfuscated malicious code. Interestingly, a denuded Xpaj, divested of its obfuscatory vestments, is nothing more than a clicker.

Well before the outbreak, K7 customers who had their real-time scanner active would, of course, have already been protected. K7 products detect and clean Xpaj-infected files as “Virus ( 700000051 )”.

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/

Malware Authors and Multiple Scanners

Friday, January 27th, 2012

One of the items on a malware authors checklist while distributing malicious code is to make sure that their malware remains undetected, for as long as possible. Scanning their creation using a multiple Anti-Virus scanning system is one among the many techniques in their arsenal which ensures just that.

Although time consuming and resource intensive, the malware author installs various Anti-Virus software and keeps them updated. The malicious files are scanned on this system before they are distributed to the victim.

For malware authors/script kiddies who can’t afford to build such a system, there are underground sites which mimic genuine online file/URL scanning services. A significant difference being, these underground sites in exchange for money, promise not to distribute the scanned files to the Anti-Virus vendors. Given below are screen shots of two such sites:

Then there are tools which incorporate multiple scanners & are distributed for free. Given below is a screen shot of one such tool:

If their malicious code is detected by the Anti-Virus vendors during the initial stage of the attack, the malware authors are quick to change their binary.

While traditional checksum based detections alone might be ineffective against such files, a combination of several detection methods, which include a behaviour based approach will prove far more effective.

R.V Shyam Charan
K7 TCL

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