These are quick first looks and trend and threats

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

November 21st, 2014

Nowadays, major web players employ invite-only strategy, the hot trend to promote their new web services and apps. The invite-only buzz resonates exclusivity, thus making the forbidden more attractive to young users. Google Inbox, the new email app is currently channeling this fad, getting users excited about invites.

However, we observe some security concerns with this trend, as we notice suspicious campaigns doing the rounds. Few of the users, with or without invite shares, are seen to post hostile links that redirects to unsafe websites or demanding email id’s to distribute invites.

Here is an imaginary scenario that describes what could happen with an excited user who responds to an anonymous link that claims to send an invite. Consider, Sara wants an invite to the new email service “INBOX” and John tweets that he has “INBOX” invites to share as in the pictures below,

Now, Sara looks at the tweet, clicks on the link, shares her personal details with John as instructed. Possibility is that the link itself could be malicious.

Supposing the link is not malicious, it’s uncertain, if Sara would receive a link which redirects to a malicious link or would receive an invite mail from John after giving her personal information.

Wear your safety goggles; don’t share personal data on public platforms and be suspicious of links to invite-only emails and messages from unknown sources.

Priyal Viroja & Archana Sangili, K7 Team

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

November 16th, 2014

Here is the first part of a two-part blog based on my paper submitted for AVAR 2013 that discusses the known vulnerabilities for Android OS with examples of Android malware exploiting them and few of the ways of mitigating the risk including the patch management.

Google’s Android, as any other mobile operating system, also contains a number of vulnerabilities. Android malware writers are now increasing the use of these exploits to evade detection. Early Android malware used simple ways to either spread or compromise the user’s device however with the increase in the Android malware count year-on-year and the advancement in detection techniques used by security software, malware writers have been forced to evolve new approaches to evade detection by mobile security products. A reminder of Darwin’s “Survival of the fittest”.

In the recent past, there have been a few Android malware instances that focus on exploiting vulnerabilities in the Android OS to attain root access or administrative privileges. For example, Android TrojanSpy Droiddream involved Exploid and RageAgainsttheCage exploits to obtain root access of the victim’s device.  To complicate the scenario further, the obfuscated Backdoor.AndroidOS.Obad utilises multiple system vulnerabilities in the Android OS to have its stealthy malicious behaviour. In addition there has been some publicity about the critical vulnerability in Android’s application signature check that could allow a hacker to inject malicious code into the legitimate application without even breaking the signature.

Known vulnerabilities in Android include those related to privilege escalation, common intent and so on. The exploitation of vulnerabilities provides a powerful mechanism for malware writers to compromise a system and deploy malicious code so it is imperative that we understand the scope of these attacks.

This paper provides an account of the known vulnerabilities used in the Android threat landscape with examples of Android malware exploiting them. The paper will also focus on the ways and means of mitigating the risk, including a discussion of patch management for Android.

Severity Evolution of Android Threat

Malware authors started investing time in identifying new ways to install their applications and to trick the user into installing their packages, with the focus on improving the propagation methods. Along with the early SMS Trojans, the severity of the Android threats notably increased with the emergence of other malware like fake applications, Zitmo/Spitmo, Image modifiers and so on, that really improved the complexity of the Android threats. In addition to these categories, targeted attacks, SMS worms were also predicted.

Unfortunately, in the past, there were few occurrences of malicious applications in the Android official market itself which had the outcome of Google’s Bouncer, a behavioural scanner. Even though malware writers can upload their malware package in the third party markets for Android, with the advancement in the security measures, such as Google’s Bouncer, the detection techniques involved by the mobile security products and last but not the least because of the smartphone user’s awareness on malware propagation methods, malware writers are forced to discover a new route that serves them to evade detection techniques and successfully execute their malicious code.

In the past, many Android malware required root access (administrative power) to execute the desired malefide functions on the victim’s device. For instance, Android.Droiddream involves the exploits Exploid or RageAgainsttheCage to exploit the vulnerability in the Android OS to attain root access. Notably, in the recent past, malware authors engage exploitation of the OS vulnerability increasingly to run their piece of malware and they are seen to target other functionalities in the OS apart from the root access.

Known Vulnerabilities

The saying that popularity brings in the danger of threats holds good for Google’s Android as well. Exploiting vulnerability in any OS stands as one of the best possible ways for malware authors to achieve privilege escalation or DoS.

Figure 1 below represents the count of major Android Vulnerability year on year since 20091.

Figure 1: Android Vulnerabilities by year till November 2013

The Vulnerabilities listed above were exploited to cause any adverse effects from remote code execution to denial of service attack.

Figure 2 shows the effects of exploitation of Android vulnerabilities

Figure 2: Exploitation Effects

Data from the above chart depicts that many of the exploitations are aimed at either remote code execution or performing denial of service. Malware authors may exploit one or a combination of these known vulnerabilities to reach their goal. The same example Android.Droiddream can be quoted here again for the exploitation of privilege escalation vulnerability.

The table below describes a few of the major security vulnerabilities and their security impact on the mobile device.

CVE-2013-4787 Code Execution Master Key Vulnerability – flaw in cryptographic check for application’s signatures
CVE-2012-6301 DoS Browser application in android 4.0.3 allows remote attackers to cause DoS (application crash)
CVE-2012-4222 DoS KGSL kernel mode driver for Android allows remote attacker to cause Denial Of Service through Null pointer dereference
CVE-2012-4221 DoS,

Code Execution

Integer overflow in DIAG kernel mode driver allows remote attacker to cause either DoS attack or remote code execution
CVE-2012-4220 DoS,

Code Execution

DIAG kernel mode driver allows remote attacker to cause DoS/remote code execution by incorrect pointer dereference
CVE-2012-3979 Code execution Flaw in Mozilla before 15.0 allows remote attacker to execute arbitrary code via crafted webpage that loads a javascript dump function
CVE-2011-3918 Dos Zygote process in android accepts fork requests from arbitrary UID, that causes remote attackers to cause DoS by reboot loop
CVE-2011-3874 Code Execution Stack-based buffer overflow allows user-assisted remote attacker to execute arbitrary code.
CVE-2011-2357 Bypass Cross application script vulnerability in the  browser URL loading functionality allows local applications to bypass sandbox and execute  javascript
CVE-2011-1823 Code Execution

Memory Corruption


The vold volume manager daemon on Android 3.0 and 2.x before 2.3.4 trusts messages that are received from a PF_NETLINK socket, which allows local users to execute arbitrary code and gain root privileges
CVE-2011-0680 Flaw in draft cache management by data/ in the Mms application in Android before 2.2.2 and 2.3.x before 2.3.2 allows remote attackers to read SMS messages intended for other recipients in opportunistic circumstances via a standard text messaging service.
CVE-2011-0419 DoS Stack consumption vulnerability
CVE-2010-1807 DoS

Code Execution

Flaw with floating point data validation allows remote attacker to cause DoS attack or remote code execution
CVE-2010-2656 DoS Unspecified issue in the process allows remote attacker to cause Dos via crafted SMS message, which is possibly related to CVE-2010-3698 and CVE-2010-2999
CVE-2009-2348 Bypass Android 1,5 CRBxx allows local users to bypass the android.permission.CAMERA and android.permission.RECORD_AUDIO configuration settings by executing an application

that does not request permission before using camera or microphone

Table 1: Android Security Vulnerabilities list till November 2013

Given below is a list of the vulnerabilities and the handset/installed app that they target:

CVE-2013-4777 Privilege Escalation A certain configuration of Android 2.3.7 on the Motorola Defy XT phone for Republic Wireless uses init to create a /dev/socket/init_runit socket that listens for shell commands, which allows local users to gain privileges by interacting with a LocalSocket object.
CVE-2011-2344 Privilege Escalation Android Picasa in Android 3.0 and 2.x through 2.3.4 uses a cleartext HTTP session when transmitting the authToken obtained from ClientLogin, which allows remote attackers to gain privileges and access private pictures and web albums by sniffing the token from connections with
CVE-2011-1352 Privilege Escalation Memory Corruption The PowerVR SGX driver in Android before 2.3.6 allows attackers to gain root privileges via an application that triggers kernel memory corruption using crafted user data to the pvrsrvkm device.

Table 2: Specific Android Security Vulnerabilities list till November 2013

The list in Table 1 and  Table 2 above are extensive and does not include the vulnerabilities seen after the mentioned time period. Exploiting one of these vulnerabilities may help the attacker in planting the malicious application on the user’s device. Once on the device, they can behave in the way that any malicious app would,  like sending SMS messages without user’s knowledge, stealing personal/user information, Zitmo/Spitmo, etc.,

to be continued…


Images courtesy of:

Senior Threat Researcher, K7TCL

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

November 10th, 2014

The 17th AVAR conference is scheduled for the coming week (12th to 14th November 2014) to be held in Sydney, Australia. Topics discussed includes mobile malware, Advanced Persistent Threats (APT), targeted attacks and other security related topics under the theme “Security Down Under”.

K7 representatives, Lokesh Kumar, Systems Manager, K7TCL and Gregory Panakkal, Senior Software Architect will be presenting a paper titled “Shell Team Six: Zero Day After-Party “ on the 13th of November at 14:55, along with other security experts from the Asia-Pacific Region.

We hope to see you all there.

Archana Sangili
Content Writer

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

November 7th, 2014

In a nice gesture, the editor of the acclaimed Virus Bulletin magazine has blogged about the presentation of our reserve speaker duo who were meant to present a paper and a short demo, in the event of an absent speaker at the 2014 Virus Bulletin International Conference held recently in Seattle, USA. VB2014 has already been discussed, highlighting the presentation by K7’s Gregory Panakkal. Nevertheless, this post is dedicated to the reserve speakers from K7 Threat Control Lab, Samir Mody, Senior Manager and V.Dhanalakshmi, Senior Threat Researcher.

Their paper, “Early launch Android malware: your phone is 0wned”, demonstrates the difficulties in
removing an active Android ransomware, “’Koler/Simple Locker”, infection that prevents a user from
uninstalling it. It also proposes a new framework which Google could induct to help mobile security vendors defeat Android malware strategies.

View the full presentation and demo at our official YouTube channel.

Archana Sangili
Content Writer

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

October 21st, 2014

The next sweet to taste after Kitkat, “Lollipop” (Android 5.0), loaded on Nexus devices, is expected to hit the market next month, as announced by Google on October 15, 2014.

The much awaited Lollipop carries many improved and new ingredients, but we’ll concentrate on the security implications of the new OS:

  • The “Factory Reset Protection” (opt-in Kill Switch) requires the user to enable and enter the Google login and a pass code to factory reset his/her device.
  • “Automatic Data Encryption” shields the user data when the device is lost or stolen.
  • Enforced SELinux” for all applications to defend against exploits and malware.
  • “Smart Lock Feature” allows only trusted devices for device pairing (user’s phone can be unlocked through the paired bluetooth device).

In addition to these “features”, we are eager to know if the experimental DM-Verity introduced in Kitkat (4.4) to protect the integrity of the device’s boot process is still imposed by default in Lollipop.

Another new feature, “Device sharing”, allows users to share the device among family members or friends under “Guest user” accounts. “Screen Pinning” restricts the guest to view only the pinned screens of the user. However, going further, Lollipop permits the user to login to another Android device remotely to access synced data contents. As one would know, Android malware utilizes every possible way to infiltrate the user’s device, and therefore the above said remote login raises eyebrows about the security implications in authenticating and controlling remote sessions.

The notable news for the corporate IT admins is that, with Lollipop, users can partition work and personal spaces within the device. However, the implications as far as the BYOD concept is concerned have yet to be spelled out.

Android Lollipop’s new security enhancements and features have raised a few questions. We are anticipating the answers!

Happy Diwali!!!

Images courtesy of:

Senior Threat Researcher, K7TCL

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

October 17th, 2014

The annual Virus Bulletin International Conference was held this year on 24-26 September, in Seattle, USA. As usual, VB2014 featured presentations from several notable vendors in the anti-threat sphere, describing their recent research and development in the field of IT security. Anti-Malware tools and techniques, botnets, mobile security, network security, spam and hacking were some of the highlighted topics that were contemplated upon.

Every year, K7 Computing shares the knowledge and technical advances made by our R&D teams. This year, Gregory Panakkal, a Senior Software Architect at K7 Computing, who extensively develops the handling  of anti-malware components in the K7 security suite, presented on the topic, Leaving our ZIP undone: how to abuse ZIP to deliver malware apps. His paper deals with the ZIP format which is employed in Android applications and the possible crafted malformations of the ZIP format that can be used to bypass AV detection, without breaking trust for the Android OS. It discusses the challenges for AV components in handling such scenarios, as well as introducing the concept of the “Chameleon ZIP” which complicates the contextual handling of a crafted amalgamated ZIP package which can be interpreted differently based on the application which opens it.

Gregory’s presentation can be found on the VB website.

Archana Sangili, Content Writer

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

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:

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 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 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 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.

[13] Information on
[14] Information on

Lokesh Kumar
K7 Threat Control Lab

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

September 19th, 2014

A thus far undisclosed, potentially serious security flaw has been discovered on eBay according to BBC News. Hackers were apparently successful in exploiting a weakness on eBay’s website that enabled them to multi-redirect customers, via a landing page listing iPhones, to phishing pages purporting to be those of eBay so as to steal their login credentials.

Unfortunately is it likely that several users would have been duped into surrendering their credentials, thus handing over control of their accounts to the bad guys. However, K7 users would have been protected since one of the redirector URLs was blocked by the malicious URL-blocking feature which has the overall effect of nullifying the multi-step redirector chain and protecting users.

From the user’s side it’s difficult to differentiate between legit redirection and non-legit redirection so this is best left to the site blockers in internet security products such as K7 Total Security.

In addition to that we also found directory listing and outdated plugins (such as JWplayer) on the destination website to which users were being redirected. Based on website fingerprinting, it seems websites hosting the phishing pages were almost certainly compromised by the attackers to hide their tracks.

The phishing pages have now been removed, but the domains are still live and we aren’t sure whether the core vulnerability which allowed the hackers in in the first place has been patched. In other words the webserver may be vulnerable to being hacked once more.

At the time of writing this blog we are unsure whether the cross-site scripting (XSS) flaw exists in other eBay item listings which may or may not be currently in the process of being maliciously exploited. Given the popularity of a site such as eBay, the impact of such an attack can be far reaching and varied; it is possible to leverage redirections to deliver malware via drive-by-download attacks.

The question which pops up is, “Was this just a phishing attack ??” It could have been much much more damaging.

Image courtesy of

Priyal Viroja, Vulnerability Researcher, K7TCL

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

September 15th, 2014

Recently, a researcher colleague at K7 Threat Control Lab faced a minor glitch in accessing his online banking account at one of India’s leading banks. This led him to explore the bank’s online banking website, and he was surprised to find that not only was the main logging information portal vulnerable to simple exploitation but the authentication process also seemed weak in certain areas.

Driven by curiosity, we experimented with the entry level data validation mechanism at the online banking websites of major banks in India to discover if their online banking services are as sound as they claim them to be. Our very basic, high-level “field trials” made us realize that both the bank’s online security methods and user practices could potentially compromise the security of the bank’s online services.

We observed a few simple logic flaws in the online security process which could present loopholes for the bad guys to exploit, thus potentially bruising the bank’s online defences. Note: These logic flaws do not involve the exploit of web application vulnerabilities such as XSS, SQL, RCE, etc.

Field Value Enumeration

A customer trying to access his account is required to submit a login form to confirm his authenticity. We noticed that most of the banking sites validated each entry of the login credentials separately. This kind of independent validation could lead to ‘Field Value Enumeration’ and could subsequently lead to attackers deliberately locking out user accounts. For example, if the account policy of a bank holds that users will be locked out after five failed login attempts, an attacker could lockout an account by deliberately sending an invalid password on five attempts for a valid username. On a large scale, mass account lockouts could amount  to a ‘Denial of Service’ attack, which, if successful, would harm the reputation of the targeted banking institution.

Weak Usernames

Nearly 50% of the internet banking portals have a feeble username-strength validation process. Usernames should be unique, and ideally not be enumerable or guessable, and should never be a “Bank Client ID”, “Bank Customer ID”, “Email ID”. By setting username standards by including alphanumeric and special characters, the strength of usernames can be improved, thus making it that much more challenging for the miscreants to abuse.

Easy-to-Remember Passwords

The password is usually the critical barrier which blocks malicious intruders at entry. However, customers generally opt for passwords which are simple and easy to remember, which makes the hacker’s job a tad easier. For a sturdy password, it should be made mandatory for users to employ criteria such as uppercase, lowercase, numbers and symbols, and minimum length in their passwords as a precaution against brute-force and dictionary attacks.

Additional validation from server side

User validations are mostly coded on client side scripting languages, and are therefore easily circumvented. Additional duplicate user validation processes should ideally be implemented at the server end as well to enhance the overall user validation process.


Almost 60% of the online banking websites lack CAPTCHA implementations. Incorporating a CAPTCHA as an additional step in the user authentication process can significantly mitigate against bots and brute-force attacks.

Mail Notification for “Authentication”

Almost all online banking services have a mail delivery process for each user transaction that occurs. However, we noticed that 60% of net banking services are not sending mail notifications on unsuccessful authentication. Such a notification can be useful for users to be apprised of any unauthorized login attempt. There is unlikely to be a bombarding of the user’s inbox with notifications given that the probability of a legitimate user repeatedly typing in the wrong username and/or password is pretty low.

In conclusion a more secure online banking service can exist by employing enhanced protection strategies and by encouraging customers to adopt good security practices for usernames and passwords, thereby protecting their medium of access to these online banking websites.

Image courtesy of

Priyal Viroja & Archana Sangili, K7 Team

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