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 ‘Security’ Category

Shell Team Six:Zero Day After-Party (Part IV)

Friday, March 13th, 2015

This is the fourth part of a six-part blog based on the paper submitted by my colleague Gregory and myself on Advanced Persistent Threats (APT), for AVAR 2014.

Continuing from the third part of our paper…

Security Solutions Bypass

The next layer of defense that an attacker confronts is the end point security provided by third party vendors. Host Intrusion Prevention Systems (HIPS) for example, detect ROP exploitation and prevent shell code execution by injecting their modules into commonly exploited applications and placing hooks at various operating system APIs. However, these inline hooks meant to monitor suspicious activities and detect exploitation attempts are placed under the same privilege as the rest of the code in the process, thereby undermining the security solution’s ability to maintain and intercept all the required APIs.

Hook Hopping

This technique involves the attackers executing standard function prologues of intercepted APIs within self and then transferring control just past the JMP instruction intended to intercept the call.

Fig.10: Control flow depicting bypass of JMP instruction in a hooked API

The DeputyDog campaign [6] which exploited the CVE-2013-0389 vulnerability, employed the above technique to bypass the interception of WinExec() API calls by security software.

Direct SYS Calls

These are a sequence of CPU instructions that transfer control to the kernel directly from the application code instead of using the OS provided user mode APIs.

Payload Delivery via Documents or Sparse Encrypted Fetches

Shell code used as part of the exploitation chain may need to execute a larger payload to establish a backdoor on the machine. To prevent this payload from being detected by security scanners, the attackers can:

  • Embed the payload in popular document formats like PDF, DOC, etc. The shell code when run, locates this payload in the document by scanning for specific magic markers, extracts it and executes it, or
  • Download smaller encrypted chunks of the larger payload stealthily onto the victim’s machine. These chunks are later reassembled and executed on the victim’s machine.

Anti-Virus Bypassing

The attackers use custom cryptors to encrypt their malicious code and attempt to defeat traditional signature based Anti-Virus scanners. At times, these files are digitally signed using trusted stolen certificates to appear legitimate and to circumvent local system policies.

The notorious Stuxnet malware for instance used malicious kernel drivers signed with valid stolen digital certificates to bypass Anti-Virus scanners.

Equipped with information about the security solutions installed in the organization’s end point, these payloads are often tested for detection by the vendor’s security scanner before they are deployed onto the victim’s machine.

Volatile Threats

The attackers execute their malicious payloads directly on the victim’s machine without ever writing the file on the machine’s disk. Traditional security solutions that scan only files on the disk in real-time cannot see these malicious payloads that are directly written and executed in memory. Behavioral analysis systems do not intercept these operations either fearing additional performance overheads.

In the BaneChant APT campaign [7], the shell code downloaded an innocuous XOR encoded binary as the first level payload. This binary in turn downloaded a second level payload which was an executable impersonating an image file meant to bypass security scanners. Once downloaded, this binary was executed directly in memory.

Indicators of Compromise

The initial compromise stage of an APT represents an attacker’s attempts to gain entry into the target organization’s network.  In an environment defended by multiple layers of logging and security, it becomes quite a challenge for an attacker to be successful without leaving behind digital footprints. Provided below are some symptoms that could indicate a compromise in an organization’s network:

Suspicious System Changes

The presence of unauthorized applications that start from uncommon auto-start locations could indicate a compromise. Files names that resemble popular/operating system files like svchost.exe, acrord32.exe, etc. and dwell in unusual locations should also raise suspicion levels.

Fig.11: System file name present in an unusual auto-startup location

Hidden instances of popular applications like Internet Explorer, code-injection attempts into trusted operating system related processes, installation of unauthorized software, loading of driver files without an entry in the Service Control Manager, etc. could also indicate compromise.

Unusual Disk Activity

Exploitation attempts using heap spray techniques tend to use significant amounts of memory.

At times this can lead to high disk activity due to frequent page-file access. Attempts to sweep a user’s profile area for personal or confidential data could also result in increased disk activity, which could indicate compromise.

Compromised Security Components

Partially enabled security features or completely disabled security solutions on endpoints, even for a brief period of time, could indicate that something is wrong.

Loading of Unsigned Drivers in x64 Systems

x64-based Microsoft Windows verifies and allows only digitally signed driver binaries to load during system boot-up. Unsigned malware that want to load early on during the boot process will have to disable this verification process.

Boot kits for instance, tend to bypass the driver signing policy by making persistent system wide changes. Successful loading of a custom unsigned “test” driver on a machine infected with such a boot kit could indicate a compromise.

Fig.12: Windows alerting on loading an unsigned driver

Prevention/Detection

Mock Phishes

Since human behaviour is manipulated to the attacker’s advantage during this stage of an APT, training programs should be conducted at regular intervals to educate the users on the latest intrusion techniques. These programs should aim at explaining the importance of security along with adequate examples, as well as changing user behaviour such that they follow security policies correctly.

Pen test emails mimicking a spear phishing attack could be used to improve the employees’ resilience towards such attacks [8].

Virtualization

Email applications and web browsers could be run in a virtualized environment that is automatically reverted during startup.


Malicious email attachments and drive by downloads would be contained within this environment and reboot resilient code would not survive a revert-to-clean-snapshot assuming that the malware cannot escape the guest VM and infect the host.

Intent to View

Suspicious or unknown email attachments should explicitly be stripped by security solutions.

These attachments should be released to a user only if he/she explicitly requests them.

Detecting Bypassing Attempts

Evasion techniques such as hook-hopping can be identified by breaking some basic assumptions made by the attacker. The security solution can replace the random number of instructions from the function prologue with its own code sequence. This way, shell code that attempts to bypass the initial JMP instruction would still land on the code sequence controlled by the security solution.

Few security solutions use multiple int 0×3 instructions past the initial JMP instruction to trigger a debug exception when executed, breaking the flow of execution.

Hook bypass attempts using direct system calls from user-mode processes can be flagged using a kernel module, if this user-mode to kernel-mode transition does not originate from the native layer.

References:

[6] http://www.fireeye.com/blog/technical/cyber-exploits/2013/09/operation-deputydog-part-2-zero-day-exploit-analysis-cve-2013-3893.html
[7] http://www.fireeye.com/blog/technical/malware-research/2013/04/trojan-apt-banechant-in-memory-trojan-that-observes-for-multiple-mouse-clicks.html
[8] http://phishme.com/product-services/what-is-phishme

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/

Shell Team Six:Zero Day After-Party (Part III)

Monday, February 23rd, 2015

This is the third part of a six-part blog based on the paper submitted by my colleague Gregory and myself on Advanced Persistent Threats (APT), for AVAR 2014.

Continuing from the second part of our paper…

Exploiting Popular Applications

Popular applications such as web browsers, word processors, etc. in an attempt to provide rich functionality, at times fail to handle untrusted data properly. The attackers probe these applications with a variety of mechanisms such as fuzzing, reverse-engineering, study of any stolen code, etc. in order to discover bugs that allow them to execute malicious code without any user interaction.

Lack of buffer boundary checks in the application’s code is exploited, critical memory area is over written to hijack the control flow of the program and  execute the attacker’s shell code.

Likewise, bugs in handling multiple references to the same object have lead to Use-After-Free class of vulnerabilities which after seeding memory areas with malicious code can be exploited to execute the attacker’s shell code.

Data Execution Prevention (DEP) Bypass

DEP is a security feature provided by the operating system to thwart buffer overflow attacks that store and execute malicious code from a non-executable memory location. The OS leverages the No-eXecute technology in modern day CPUs to enforce hardware assisted DEP that prevents memory areas without explicit execute-privilege from executing. Attempts to transfer control to an instruction in a memory page without execute-privilege will generate an access fault, thereby rendering the attack ineffective.

Bypassing the DEP feature in a process involves locating already existing pieces of executable code from process memory space and manipulating them to use attacker controlled data to achieve arbitrary code execution. This is accomplished using one of the following techniques:

  • Return-to-libc
  • Branch Oriented Programming (BOP)
    • Return Oriented Programming (ROP)
    • Jump Oriented Programming (JOP)

Return-to-libc

This evasion technique involves replacing the return address on the call stack with that of an existing routine in a loaded binary. The parameters/arguments that are passed to such routines are controlled by the exploit data strategically placed on the stack.  A system function like WinExec() can be invoked to load and run a malicious component without running non-executable exploit data.


Fig.6: The stack layout when using return-to-libc attack to invoke system() in GNU Linux (32-bit).

Branch Oriented Programming

This bypassing method involves an attacker gaining control of the call stack and executing carefully stitched pieces of executable code called “gadgets”. These gadgets contain one or two instructions which typically end in a return instruction (ROP) or a jump instruction (JOP) and are located in a subroutine within an existing program or a shared library. Chained together, these gadgets allow an attacker to perform arbitrary operations on a machine.

Fig.7: ROP gadget execution sequence based on exploit controlled stack layout

Address Space Layout Randomization (ASLR) Bypass

In order to thwart BOP attacks, the concept of randomizing executable code locations, by randomizing the base address of the loaded binary, on every system reboot was introduced. This security measure known as ASLR made it difficult for the attacker to predict where the required gadget sequence resides in memory. However, APTs have been observed bypassing this protection using the following techniques:

Loading Non-ASLR modules

Dynamic-Link Libraries compiled without the dynamic-base option cannot take advantage of the protection offered by ASLR and as a result, are usually loaded at a fixed memory space. For example, Microsoft’s MSVCR71.DLL shipped with Java Runtime Environment 1.6 is usually loaded at a fixed address in the context of Internet Explorer making it easy to construct the required gadget chain in memory.

Fig.8: An ASLR incompatible version of MSVCR71.dll

DLL Base Address calculation via Memory Address Leakage

This technique involves determining the base address of any loaded ASLR-compatible DLL based on any leaked address of a memory variable or API within that DLL. Based on the address of this known entity, the relative addresses of all the required gadgets can be calculated and a ROP attack constructed.

Attack techniques such as modifying the BSTR length or null termination allows access to memory areas outside the original boundaries, leading to the memory address of known items being revealed to the exploit code. This can then be used to pinpoint the DLL’s location to use ROP gadgets within it. Array() object also has a length component that can be overwritten to leak memory addresses beyond its bounds.

Browser Security Bypass

Leveraging the operating system’s security, popular web browsers run certain parts of their code, JavaScript execution and HTML rendering for example, as a sandboxed background process. This process runs with limited privileges and has restricted access to the file system, network, etc.  A master controller acting as an intermediary interacts with the user and manages these sandboxed processes. By using this master-slave architecture and providing a controlled environment, users are protected from exploit attempts by limiting a shell code’s capability to access host system resources and confining its damage to within the sandbox.

Since these browsers rely on the operating system’s security model, exploiting unpatched kernel vulnerabilities will result in the malicious code escaping its confined environment. The infamous Duqu malware relied on vulnerability (CVE-2011-3402) in the Win32k.sys driver that improperly handles specially crafted True Type Font (TTF) files. This allowed the malware to escape a user-mode sandboxed environment implemented by the Microsoft Word process and compromise the host.

Fig.9: Vulnerable code snippet from win32k.sys that lead to the Duqu TTF exploit

Enhanced Mitigation Experience Toolkit (EMET) Bypass

EMET is a Microsoft tool that provides additional security to commonly-exploited third-party applications such as web browsers, word processors, etc. It extends the operating system’s protection mechanisms to these vulnerable applications and makes exploitation attempts extremely difficult.

The following table lists the protections offered by EMET and known bypassing techniques [4]:

Click here to read the fourth part of this blog

References:
[4] http://bromiumlabs.files.wordpress.com/2014/02/bypassing-emet-4-1.pdf
[5] http://0xdabbad00.com/wp-content/uploads/2013/11/emet_4_1_uncovered.pdf

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/

Shell Team Six:Zero Day After-Party (Part II)

Wednesday, February 11th, 2015

This is the second part of a six-part blog based on the paper submitted by my colleague Gregory and myself on Advanced Persistent Threats (APT), for AVAR 2014.

Continuing from the first part of our paper

Initial Compromise

Armed with information obtained from the previous stage, the perpetrators may adopt several techniques to sneak into the organization. Traditional attacks involve actively targeting vulnerable applications and exploiting Internet facing resources like webservers, SQL servers, FTP servers, etc. As log analysis and security around these external resources have caught on, the attackers have had to evolve their tactics in order to be successful.

Infiltration Methodology

The attackers now target the most vulnerable element of any organization – the human. Social engineering tactics are used to entice an individual or a group of users into running code, which will allow the attackers to introduce their malware into the organization’s network. The most commonly used attack techniques are:

  • Spear Phishing
  • Watering Hole

Spear Phishing

Spear phishing involves the attacker compromising a machine by sending a well-crafted email to a targeted user and convincing him/her to:

  • Open an embedded link that points to a website loaded with zero-day exploits, or
  • Open a malicious attachment (EXE, PDF, DOCX etc.)

both of which exploit the rendering application to drop or download, and execute a payload with backdoor capabilities

Watering Hole

 

Watering hole attack involves the attacker placing exploits, possibly zero-day in nature, on a trusted website which is frequented by the users of the organization.  When a targeted user visits the site, the exploit code is automatically invoked and the malware installed on his/her machine.

Case Study

The U.S. Veterans of Foreign Wars’ website was recently compromised to serve a zero-day exploit (CVE-2014-0322). A similar watering hole attack exploiting zero-day vulnerabilities has occurred in the past targeting a specific group of people by compromising the website of the Council for Foreign Relations.

Fig.2 shows publicly available website access logs of users along with their non-routable IP addresses. This information can be used to evaluate the browsing habits of individuals in the company and eventually to execute a watering hole attack.


 
Fig.2: Publicly available map of internal IP addresses and their website logs

Security Bypassing

Email attachments, file downloads, HTTP requests, etc. originating from users undergo rigorous checks at various layers that include:

  • Network/Gateway layer scanners
    • Email/File/URL scanners
    • Sandboxed file analysis
  • Endpoint/Desktop layer scanner
    • Anti-Virus/HIPS/firewall
    • Application security features
    • Operating system security features

Once the human element falls prey to social engineering, and is coaxed into downloading a file/email or visiting an exploit site, the attackers are faced with challenge of defeating a series of network and end point security solutions before conquering the victim’s machine. Listed below are some of the tactics used by the perpetrators to bypass these layers of security.

Attachment Archive File Format Abuse

Discrepancies in the way in which a security product handles a compressed file versus that of an un-archiving application has led to abuse of the popular ZIP file format.  Un-archiving apps identify ZIP file types by scanning the last 64KB of the file for a special magic marker. Security scanners on the other hand, with a need for speed, identify the file type by inspecting only the first few bytes from the beginning of the file.

An attacker abuses this disparity by creating a malicious ZIP file and manipulating its headers by adding junk data at the beginning of the ZIP file. This specially crafted file deceives security scanners into thinking that it is of an unknown type and escapes detection, but un-archiving applications are able to successfully extract the malicious code at the end point.

Fig.3 shows a Proof-of-Concept [2] archive file that is capable of evading security scanners

Fig.3: Crafted ZIP file with NULL data prefixed.

Gateway Sandboxing Bypass

Suspicious files that match certain criteria are typically executed within a sandboxed environment for a short period of time. Depending on their behavior, the files are either blocked from the user or released to him/her.

Attackers can craft malicious files which detect such controlled settings by looking for specific registry keys, in-memory code changes, mouse pointer movement, etc.

For example if the malicious file identifies that it is being executed in a sandboxed environment, it stays idle without performing any activity thereby bypassing this check. The Up-Clicker Trojan [3] attempts to evade sandbox analysis by staying idle and waiting for a mouse click before activating itself.

Fig.4: Code showing Up-Clicker Trojan set to activate on mouse click

Browser Multi-Purpose Internet Mail Extensions (MIME) Sniffing

This attack exploits differences in the way in which security scanners and web browsers identify the content returned by an HTTP server.

Security scanners parse the magic headers available at the beginning of a file returned by the web server, to identify the file type. This means that a specially crafted malicious HTML file containing the magic marker commonly found in a GIF image will be identified by the scanner as an image file, exempted from scanning and let through into the network.

Web browsers on the other hand, depend on the MIME type in the HTTP response header returned by the web server to identify the file type. When this information is absent as is the case of a response from an attacker controlled web server, the web browser resorts to content sniffing to determine the MIME type. So, the same malicious HTML containing the GIF magic marker will now be identified as HTML content by the user’s browser and rendered accurately to execute the exploit code.

Fig.5: Malicious script containing bogus RAR and GIF magic markers.

Click here to read the third part of this blog

References:
[2] http://www.reversinglabs.com/news/vulnerability/reversinglabs-vulnerability-advisories.html
[3] http://www.infosecurity-magazine.com/news/trojan-upclicker-ties-malware-to-the-mouse

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/

Exorcising CTB Locker from your Computer: What you Need to Know

Friday, January 30th, 2015

Ransomware, a type of malware which holds your files to ransom by encrypting them and then demanding a ransom for their “release”, i.e. by decryption, is nothing new. Cyber criminals make a lot of money by extorting funds from victims all over the world.

The latest family of widely distributed ransomware is called CTB Locker. In this blog we have decided to provide information about CTB Locker in the form of an FAQ so that our customers and the general public globally may be well-informed about the dangers of this malware family, learn how to avoid it, and be reassured about our robust response to it.

FAQ

  • How do you prevent your computer from becoming infected by CTB Locker?

Let’s begin with this question as it is the most important one to keep your computer safe. Prevention is always better than cure.

The initial spreading vector for CTB Locker is a spam email with enticing content which uses social engineering techniques to convince the potential victim to unzip a ZIP archive attachment (extension ‘.zip’) and execute its embedded file.

This embedded file, which is currently around 40KB in size, may have misleading extensions such as ‘.scr’ in order to masquerade as a screensaver application. This file is the downloader component for CTB Locker’s main payload, which then does the actual file encryption and makes ransom demands. We urge you to be vigilant against such spam emails as it is very first line of defence against CTB Locker as well as a host of other malware families which also use the same old time-tested technique to spread.

If an email comes from an unknown or unexpected source containing an attachment or a website link requesting you to open the attachment or click on the link, please exercise extreme caution. We would suggest simply deleting such emails if they are not already quarantined by your spam filter.

The spam emails tend to be targeted at English-speaking countries and at least 3 European countries given that the malware payload provides its ransom messages in German, Dutch and Italian.

This ransomware is not targeted at Indian users per se but given the ubiquitous nature of spam there will be “collateral damage” resulting in not just Indian victims but also many other hapless victims in other non-target countries.

  • What should you do when you discover your computer is infected with CTB Locker?

If you have seen messages demanding a ransom as shown above, it is likely that many, if not all, of your personal files such as Microsoft Office documents, PDF, TXT, ZIP and even ‘C’ source code files will be in an encrypted state, i.e. appear to contain random binary junk. Files encrypted by CTB Locker will have filenames such as yourfile.ext.<7 random lowercase letters>, e.g. 253667.PDF.iryrzpi

Executable files, e.g. EXE, DLL, OCX, etc, and files with extensions unknown to the malware will not be touched.

First and foremost, we would request that you do not attempt to pay the ransom to get your files back. Even if the cyber criminals do actually decrypt your files, the money they get from you will only serve to encourage them to continue their nefarious practices, investing R&D in enhancing their capabilities and global reach. Cyber criminals must be stripped of their Return on Investment incentive to create malware.

Once you have decided not to pay the ransom we would recommend removing the malware immediately. This can be done most easily by:

  1. updating your product
  2. rebooting into Safemode
  3. performing an on-demand scan on your computer
  4. removing the detected components. Note, the main CTB Locker payload is detected as ‘Trojan ( 0049d83b1 )’ and its downloader component is detected as ‘Trojan-Downloader ( 00499db21 )’

  • Is it possible to decrypt files encrypted by CTB Locker?

The malware itself demonstrates that files can be decrypted by randomly choosing 5 samples to decrypt.

However, the malware uses a high-grade encryption algorithm with a key which is unique to your computer, rendering it effectively impossible to force a decryption en masse.

  • How to restore files encrypted by CTB Locker?

It may not be possible to restore all files encrypted by CTB Locker. However, if your Windows operating system supports System Restore it is possible to recover the contents of many of your folders to a recent restore point before the infection took place.

The most reliable solution, though, is to restore your critical files from regular backups. If you don’t backup your important files regularly then we urge you to start doing so ASAP. Apart from a CTB Locker infection, there are numerous other factors which could render your files irrecoverable in the future, including a hard disk failure. Note, it may also be possible to use deep forensics tools to recover some critical files if they still exist on sectors on the hard disk, but this is not an alternative to regular backups.

  • Will paying the ransom actually decrypt your files?

We refuse to pay any ransom so we are unable to confirm whether payment will actually result in your files being released. Once again, we would request you to not attempt to pay the ransom for the reasons mentioned earlier.

  • Why did K7 not detect and remove CTB Locker?

At K7 Threat Control Lab we are constantly monitoring and acting against CTB Locker infections, including coding robust generic detection for all components of CTB Locker. However, the cyber criminals behind the CTB Locker family have been investing considerable resources in morphing, i.e. changing the appearance of, all their components and spam emails such that they may sometimes be able to get past security scanners, not just K7’s, albeit for a very short period of time. We at K7, and our colleagues at other security companies, are working hard to stay ahead of CTB Locker in order to protect all our customers across the planet.

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

Hacked Websites: Consequences and Mitigation

Wednesday, January 28th, 2015

This is the final chapter of my blog series on “Hacked Websites” describing the consequences faced by users of visiting a hacked website, along with a few mitigation guidelines for the developers and webmasters, following on from the previous chapter covering the vulnerabilities and exploits involved in a website compromise.

Back in the old days, hackers used to hack to try to solve problems, to improve internet security and experience, and to boost their own self-esteem. Over time, hackers’ intentions changed and they began to hack for many more troublesome reasons such as to deface a website and convey a specific message, to steal confidential data or services, to host illicit material, for malicious redirects, to utilize a server’s resources for malicious intent, DDos, etc; by and large for money, theft of intellectual property, curiosity, prestige and as a publicity stunt.

Consequences for a user in visiting such a compromised website are that a user may

  • become a victim of a socially engineered phishing attack and give away his/her banking credentials, personal information and credit/debit card data on fraudulent sites.
  • become a victim of unintentional malicious downloads and installs (aka ‘drive-by download’), including becoming part of zombie botnet armies.
  • To ensure a safe and secure visit for a user to their website, webmasters must periodically verify their websites’ integrity. Below are a few of the mitigation guidelines for both developers and webmasters.

    For developers :

    ●     Implementation of effective input/output validation and sanitization approach.
    ●     Implementation of effective account management, authentication and authorization practices.
    ●     Encrypting users’ secret session values and sensitive data.
    ●     Securely handling exceptions, errors and logs.
    ●     Following the standards described in OWASP, CERT guidelines.

    For webmasters :

    ● Do not entertain cloaking, link farming, content autogeneration and other SEO tactics that may welcome SEO Poisoning attacks.
    ● Carefully deliver content from open, restricted and forbidden areas.
    ● Serve sensitive content over secure pipelines such as HTTPS.
    ● Encrypt data (using industry grade encryption algorithms) before storing into database.
    ● Update and patch servers within regular scheduled time intervals.
    ● Perform web application security audits and penetration testing on a regular basis.

    As one would expect, in the event of any compromise of their website, webmasters should carry out the process of clean up and recovery of the hacked website at the earliest with a custom recovery process or by following the guidelines available online.

    I hope this blog series helps people, both laymen as well as webmasters and web developers, in understanding what a hacked website is, the vulnerabilities and exploits involved, and the consequences to a user of visiting a hacked website, and finally the mitigation guidelines for developers and webmasters to reduce the risk of their websites getting hacked.

    Image courtesy of:
    gfi.com

    Priyal Viroja, Vulnerability Researcher, K7TCL

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

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

    Shell Team Six:Zero Day After-Party (Part I)

    Wednesday, January 21st, 2015

    This is the first part of a six-part blog based on the paper submitted by my colleague Gregory and myself on Advanced Persistent Threats (APT), for AVAR 2014. This first part introduces the reader to the different phases of an APT and discusses the methodology, prevention and detection techniques of the initial phase of an attack in detail.

    The IT security industry is faced with the challenge of dealing with old invasion tactics that have been reborn in new avatars as Advanced Persistent Threats (APTs). APT attacks are tenacious at pursuing their targets and are played out in stages, possibly over a long period of time. With financial backing from state actors and criminal rings, APTs tend to be compound, sophisticated and difficult to detect. Each facet of the intrusion, in an idealist scenario, may be refined to such an extent that the end goal is achieved without a trace before, during or after the event.

    Despite the complexity of these types of attacks, certain parameters always need to be satisfied to deliver the payload and retrieve the expected results, leading to the emergence of an attack pattern which may be placed under the microscope and flagged. These parameters include executing arbitrary code by invoking zero-day exploits for popular software, defeating security measures such as DEP & ASLR, e.g. via heap spray and ROP/JOP chains, exploiting EoP vulnerabilities, establishing remote C&C communication channels to issue commands or to exfiltrate stolen data in encrypted form, etc.

    Drawing on evidence from documented real-world case studies, this paper details techniques that assist an assailant during the different phases of an APT, bypassing protection mechanisms like application-sandboxing, EMET, IDS, etc. thus attempting to fly under the defense radar at all times. Equipped with this information, we hope to explore methods of discovering each part of the life-cycle of a targeted attack as it is in progress or in the post mortem, thus reducing their efficacy and impact.

    Introduction

    “If you know your enemies and know yourself, you will not be imperiled in a hundred battles… if you do not know your enemies nor yourself, you will be imperiled in every single battle.” Sun Tzu

    As technologies implemented in organizations are becoming advanced, the threats are rapidly evolving too. Through tenacious and coordinated attacks on one’s infrastructure, APTs are able to infiltrate and overwhelm the organization.

    The threat landscape has changed. But the general principles of war remain the same.  Knowing the modus-operandi of your faceless attackers helps one evaluate, and harden one’s security measures, and gear up towards facing the attackers head on.  This paper aims to help you do just that.

    APT Life-Cycle

    The stages of an APT can broadly be classified as follows:

    •   Target reconnaissance
    •   Initial compromise
    •   Expanding access and strengthening foothold
    •   Data exfiltration and cleanup

     

     Target Reconnaissance

    The reconnaissance phase of a targeted attack sets the stage for the rest of the threat campaign and therefore involves a high degree of planning. The perpetrators spend significant amounts of time learning about their target, collecting as much information as possible about the human, physical and virtual resources of the organization. The intelligence garnered during this stage not only helps the assailants determine key points of entry into the target network but also empowers them to navigate the victim’s network once inside more effectively & efficiently.

    Reconnaissance Methodology

    The target’s virtual network is plotted using publicly available resources. These resources include:

    •   DNS records
    •   WHOIS information
    •   Email messages
    •   Inadequately protected network logs
    •   Misconfigured servers, etc.

    The organizational structure is also studied to determine employees and their organizational access levels, using social media, search engines and the target’s own website. Profile intelligence gathered could include potential passwords, personal and official email addresses, whether the user is a regular employee, a SOHO user, or a contractor.

    Based on this harvested intelligence the infrastructure needed for the attack will be acquired, the course of action to successfully execute the campaign will be determined & evasion techniques that could be followed during the attack will be planned. New domains may be registered, command and control servers set up, exploits crafted, vulnerable employees identified, custom social engineering schemes plotted for these target employees, malicious files created, etc.
     
    Recently, US airport workers from over 75 airports were targeted via malicious emails based on information such as their names, titles, and email addresses that were harvested via publicly-available documents [1].

    Fig.1 shows how a simple search engine query can divulge information like emails exchanged between personnel in public forums which may seem innocuous, but can be used to launch a spear phishing attack. Popular mailing lists mask this sensitive information to avoid it from being scraped and abused by bots. Valid users on the other hand are allowed access after solving a simple CAPTCHA.

    Fig.1: Search result revealing email addresses and other information about employees of an organization.

    Prevention/Detection

    Most of the intelligence collected by the assailants during this stage is publicly available and in general doesn’t involve the attackers touching any of the internal systems. Information that was gathered from previous APT campaigns but applicable to the current one could also be reused. This makes detecting an APT during these early stages of the attack challenging.

    Usual best security practices such as conducting periodic penetration tests, hardening the applications & the operating systems, etc. are still relevant, but these measures by themselves don’t stand a chance against this adversary.

    Organizations should take care to both restrict the amount of information that is flowing outside and be aware of publicly available sensitive information which could potentially be used against them.

    Profile Scraper

    Automated bots can be used to collect publicly available information on the company, the employees, etc. from popular social networking sites and search engines, etc. The data collected can automatically be analyzed for potential sensitive leaks.

    Honey Profiles

    Fake profiles at different organizational levels meant to be trip wires can be set up on popular social networking sites and connection attempts and profile hits can be analyzed. This could allow organizations to both recognize if they are being targeted and predict which individual or group of individuals are being targeted.

    Click here to read the second part of this blog.

    References:
    1] http://www.seculert.com/blog/2014/07/extended-apt-campaign-targeted-us-airports.html

    Images courtesy of google.com

    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/

    Hacked Websites: Vulnerabilities and Exploits

    Monday, January 12th, 2015

    This is the second chapter of my blog series focusing on the vulnerabilities and exploits involved in a website compromise following on from the previous chapter covering the reasons for which website access can be blocked.

    New age Internet, a web of images, videos and user-friendly interactive content, is delivered by tools like image/video gallery, sliders, gadgets, CMS, etc., for quick design and implementation.

    Because of the complexity of these evolving web technologies, there is a high possibility that security vulnerabilities in web applications might be overlooked by both the developers and the quality assurance process. Such vulnerable web applications are susceptible to hackers and bots to break into a victim’s computer and to infect websites to spread malicious files or send spam messages.

    The most common web application vulnerabilities are described below.

    Code Injection

    A huge number of data breaches happen via code injection attacks, i.e. the injection of malicious code specific to a vulnerable application either on the victim’s computer or on the website host server into a web application in order to carry out silent execution of the injected malicious code. This kind of attack includes Cross-Site Scripting (XSS), SQL Injection, XML injection, RCI, Header Injection, Log Injection and Full Path Disclosure. To have a clearer picture of code injection, let us look at the XML injection example shown below.

    Let us consider the following form and actual inputs:

    Name: test
    Password: test123
    Mail: test@test.com

    Data is sent to the web host as follows:

    http://vulnerable.site/add?name=test&password=test123&mail=test@test.com

    Expected XML result at the server side is:

    <user>

    <name>test</name>
    <password>test123</password>
    <id>101</id>
    <mail>test@test.com</mail>
    </user>

    A valid user id 101 is created for the user “test”.

    Now, let us suppose a hacker submits an XML code as input in one of the aforesaid form fields to control a user account.

    Name: test
    Password: test123</password><id>0</id><!–
    Mail: –><mail>test@test.com

    Now, the data sent would be in the format,

    http://vulnerable.site/add?name=test&password=test123</password><id>0</id><!–&mail=–></mail>test@test.com

    Modified XML result is:

    <user>
    <name>test</name>
    <password>test123</password>

    <id>0</id>
    <!–</password><id>101</id><mail>–>
    <mail>test@test.com</mail>
    </user>

    In the above example, as the hacker has entered the XML code “</password><id>0</id><!–” along with the password “test123” in the password field and “–><mail>” along with the mail “test@test.com”, the website server generated id “101” is commented out and a possibly pre-existing id “0” is assigned to the user “test” via password and mail parameters provided by the attacker. Now the hacker can avail the privileges or the functionality associated with the id “0”, thus severely violating the security objective of access control.

    Broken Authentication and Session Management

    Many developers prefer relying on their own, custom authentication and session management schemes than using the standard authentication and session management methods. As seen in cases earlier, custom schemes regularly fail in functionalities such as password management, sign in, logout, timeouts, secret question, account update, etc.

    Some common flaws attributed to the failure cases are listed below:

    ●     Storing credentials in plain text, i.e. without hashing or encrypting them.

    ●     Weak account management modules (e.g. account creation, account deletion, change/update password, recover password, etc)

    ●     Session IDs

    1. exposed in a URL
    2. that do not properly timeout or are not validated during logout
    3. that are not updated after a specific time period once logged in.

    ●     Confidential data transfer over unencrypted connections.

    In the example below, a movie-booking application exposes the session ID in the final URL as shown below,

    http://mvie.com/hindi/book/?movie=pk(2014)&time=3,6,9 &sessionid=2QZABDJ3NDXYXK5CJ8N290

    Now, if an authenticated user shares the above link with others, the allotted sessionid will also be visible to the receiver. When the receiver accesses the shared link, he/she will have the privileges associate with that session ID and can therefore hijack the session. These scenarios can cause adverse effects in case of gift vouchers, saved credit card details, etc associated with the authenticated user.

    Security Misconfiguration

    Secure configuration of an application stack including operating system platform, web server, application server, database, framework and code is one of the primary goals for  developers and system administrators. Security misconfiguration can occur at any level of an application stack. Exploiting such misconfigurations, ranging from failure to apply appropriate patches, use of default accounts, failure to set useful security headers on a web server, use of unnecessary services and disabling platform functionality could grant unauthorised access to an attacker.

    For example, consider the scenario where the server XYZ has a few java class files (compiled Java source code files) hosted, but unfortunately has directory listing is enabled, unknown to the administrator. If an attacker manages to discover that the server XYZ’s directory listing is enabled, the attacker would be able to collect the compiled code and reverse engineer it to get source code.

    Format String

    Exploitation of Format String occurs when the submitted input string is misinterpreted as a command by which the attacker can trick the concerned application to read values off the stack, induce a segmentation fault, or execute a user supplied string as a code, to cause an unexpected behavior that could compromise the stability and security of an application, thus potentially allowing execution of malicious code by a remote attacker.

    Intelligent fuzzers are used to automate fuzzy input supply to the application, with the intention of crashing the application and generating errors that can disclose sensitive information. The most common C runtime functions printf(), fprintf(), sprintf(), snprintf(), scanf(), etc., process data based on a format string and %x, %s, %n, %%, %p, %d, %c, %u  are some of the most common parameters used in this attack.

    For example,

    Let us discuss the following C code,

    #include<stdio.h>
    #include<string.h>
    int main(int argc, char** argv)
    {
    char buffer[100];
    strncpy(buffer, argv[1], 100);

    printf(buffer);
    return 0;
    }

    In the above C code, the printf() function takes one argument “buffer” instead of the usual two arguments, format specifier and the associated variables. An attacker can trick the printf() function in the above code by passing an input string “%p %p %p %p %p”  to the buffer where %p is the format specifier of a pointer. During execution, printf() will look at the argument as  “%p %p %p %p %p”, consider that it has 5 arguments and will print the next 5 addresses on the stack (for 32-bit architecture) from the current position. Possible output could be:

    => ./output.out “%p %p %p %p %p”
    0xffffdddd 0xf7ec 0×1279 0xffffdbdf 0xffffdbde

    Thus, a format string vulnerability gives the attacker the ability to read an arbitrary value from an arbitrary address and potentially perform malicious activity.

    Apart from exploiting web application vulnerabilities, hackers may also avail of weak password policies, insecure FTP/HTTP connections, outdated third party add-ons and server vulnerabilities to compromise access to a website host. To accomplish an attack successfully, attackers may combine two or more vulnerabilities together on the target webserver.

    In the next chapter of my blog series, I will describe the consequences faced by users  visiting a hacked website, along with a few mitigation guidelines for the webmaster.

    Images Courtesy:
    ronkealao.com

    Priyal Viroja, Vulnerability Researcher, K7TCL

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

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

    Hacked Websites: When Access is Denied

    Tuesday, December 23rd, 2014

    Are you excited about the new social networking platforms, games, mobile apps and the Internet of Things? Yes? Great, but BEWARE, hackers too are excited! With the K7 product installed, while visiting a website have you ever hit upon the message, “Access denied! The access to this page has been denied by K7Total Security Safe Search”? If you have, good, you’re safe.

    We at K7TCL process a huge number of suspicious website URLs everyday and identify many  malicious ones, some of which are hosted at compromised or hacked websites (websites which are owned by legitimate entities but have been forcibly taken over by hackers without the owners’ knowledge). To provide better protection to the user, URLs identified as malicious, including phishing, fraudulent and malware-payload links are blacklisted and the product denies access to them. We have stringent quality assurance processes to ensure that we don’t block access to clean websites.

    As we blogged earlier, we occasionally receive URL false positive reports from our clients for the websites that are indeed compromised. So we thought it would be a good idea to educate the public with a blog series covering:

    1. How a website is typically hacked
    2. Factors to identify a hacked website
    3. Role of software vulnerabilities (defects in software that can be exploited by hackers) involved
    4. Consequences to the user in visiting a hacked website, along with a few mitigation guidelines for the webmaster

    This is the first chapter of my blog series that briefly describes hacked websites and the reasons for a website to be blacklisted.

    Usually hackers and their automated bots, which are malware designed to infect a user’s computer and connect back to a central command and control (C&C) server, break into targeted website hosting by exploiting a web application vulnerability on the target. Targeting a massive user base, hackers often prefer to hack renowned legitimate sites that own heavy network traffic to propagate the hosted malware and infect a large number of users, or fraudulently suck information from them, even before it is identified that the website is hacked, as in the case of the recent Ebay hack. Compromised websites are either injected with a malicious script that downloads another malware on to a user’s computer or ends up redirecting to another malicious site. Such a hacked website remains infected until the webmaster identifies, assesses, and remediates threats to his/her systems.

    In response to the aforesaid incidents, we duly inform the concerned authority, i.e. the webmasters, of such infected websites about the scenario and the recommended course of action. Therefore we recommend that webmasters provide accurate, up-to-date contact details on their domain registrations and DNS records so that we know whom to contact when the need arises.

    To an end user visiting a compromised website with a vulnerable browser or browser plug-in may leave the user’s computer infected with a malware without his/her knowledge. So, it is advisable that users regularly apply update patches for their operating system and the other software they use.

    A blacklisted website/URL satisfies one or more of the following criteria:

    1) It redirects to a malicious link or points to a malicious payload
    2) It is used in spam or phishing campaigns
    3) It is hosted on a compromised web server
    4) It contains malicious JavaScript code

    Alexa, a well-known provider of web traffic information, ranks 1 million domains and sub-domains on a daily basis according to their popularity. To get an idea of the number of compromised and popular websites used in malicious attacks, we looked at how many malicious URLs are hosted on websites listed on Alexa’s top 1 million. From our latest lab data and instrumentation, we observe that currently approximately 7500 popular domains are compromised and 10791 exploit-related URLs are blocked by our product’s site blocker. Furthermore, out of these,16 sub-domains and 16 blocked URLs have domains ranked within Alexa’s top 100.

    In the next chapter of my blog series, I will describe how websites get hacked in the first place, focussing on the vulnerabilities and exploits involved.

    Priyal Viroja, Vulnerability Researcher, K7TCL

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

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

    DEATHRING: The Android You Bought Can Spy on You!

    Wednesday, December 10th, 2014

    Recently, DeathRing, the latest pre-installed Android malware supposedly from China, was spotted in popular low-end smartphones sold in Asian and African countries including India, Vietnam, Indonesia, Nigeria, Taiwan and China.

    This mobile Trojan disguises itself as a ringtone application and attempts to download other malware APKs, or target the user’s personal information and act as per the remote commands from a Command & Control server operated by cyber criminals. To avoid being uninstalled by the user, this malware is packed in the device as a system application.

    One should now be paranoid about trusting a new smartphone. A precautionary action of scanning the new smartphone with a Mobile AV before use, or may be even before purchase, would stand as a temporary solution, but the Antivirus might not be able to remove the malware as it resides in the restricted-privilege system area.

    Now, let us look briefly at what this malware does to achieve its malicious behavior. Even though this application is pre-loaded, supposing a user installs this application at will, the group permissions requested from the user during installation will be as shown in Figure 1 below.

    Figure 1.Permissions requested from user during installation

    Few of the important permissions to be granted by the user are shown in Figure 2 below. With these permissions, this Trojan app gains the ability to unmount and mount the phone’s file system with its desired privileges to install another malware APK in the system area, kill other running processes, interfere with a user’s outgoing calls and receive BOOT_COMPLETE information on device power-on.

    Figure 2.Permissions list

    Interestingly, this malware also requests permission to inject into user events (key, touch or trackball)  to deliver the event stream  to  the main activity of the Trojan.

    Figure 3.Permission to inject into a user key event

    Further analysis of this malware reveals that it also registers more than one callback and several services with the android system to start its malevolent behaviour with all possible intents that include ACTION_SHUTDOWN, NEW_OUTGOING_CALL etc., as shown in Figure 4.

    Figure 4.Callbacks registered by the DeathRing malware

    This malware carries the code to receive the key events in the main activity by declaring click listeners to trigger the corresponding relative activity.

    Figure 5.Code to receive Click Listener

    One of the relative activities listens for the key press events like onClick and onKeyDown from the SHUTDOWN key as a part of its malicious functionality as shown in Figure 6.

    Figure 6.Code listening on shutdown button

    This malware is also interested in the network state of the user’s device by first checking the user’s network type and subscriber ID, and then enabling the network connectivity based on the subscriber’s ID type.

    Figure 7.Code identifying wi-fi connection

    Figure 8.Code enabling network state

    As proposed to Google in our last VB paper, an updated boot and broadcast framework that enabled the AV component to load earlier than any other application, even system applications, could help detecting and removing such malware.

    Also, identifying and correcting the loophole through which the malware is loaded into the life-cycle of manufacturing and delivering the device at the earliest would help prevent pre-loaded malware, unless the presence of pre-loaded malware is not accidental.

    K7 Mobile Security users are protected against this malware with the detection “Trojan (0001140e1)”.

    V.Dhanalakshmi
    Senior Threat Researcher, K7TCL

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

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

    How Vulnerable is Android to Attack? (Part 2)

    Monday, November 24th, 2014

    Here is the second part of a two-part blog based on my paper for AVAR 2013.

    Continuing from the first part of my paper…

    Exploits for Android

    This section would demonstrate few of the major security vulnerabilities in the Android OS.

    Master Key Vulnerability:

    This vulnerability has attracted a lot of interest from both security researchers and from the news media. This vulnerability resides in the cryptographic signature verification of Android Application Packages (APK). The problem here is that the files in the APK (Zip archive) are parsed (unzip of a file) and verified using Java ZipFile implementation from libcore, whereas the code that loads the data from the package is from a different C re-implementation2. The way in which these implementations handle multiple files with the same name differs, which results in verifying signature for one file with a name as per Java and installing the contents of a different file with the same name as per C.

    In general, a zip format will not allow two or more files with the same name to be within an archive. But this can be circumvented with the help of some utilities available or a bit of tweaking. For example, the Android malware called Andr/MstrKey-A (Sophos) travels across with two copies of files named “AndroidManifest.xml” and “classes.dex”.

    Figure 3: Malware APK with multiple files of same name

    While the AndroidManifest.XML of size 2644 bytes and classes.dex of size 45228 bytes are the original files, the other two files were added by the malware author.

    Manifest and Dex2Jar Vulnerability:

    Android malware Backdoor.Android.Obad, called to be the most sophisticated, was found to exploit more than one vulnerability in the system to achieve the malevolent behaviour. The dexguarded Obad is seen to engage three of the vulnerabilities in the system to send out premium rate SMS without user’s knowledge.

    Apparently, dexguard protection on this malware encrypts the strings and the class names involved, making static analysis challenging.

    The figure below is a code snippet of Obad backdoor sample in Java format, highlighting some of the encrypted strings and class names.

    Figure 4: Java code snippet of Backdoor Obad sample

    The AndroidManifest.xml is a file which defines an application’s structure, permissions required and the launch parameters. This file plays a vital role during the installation process of the application. OBAD targets an error in the processing of AndroidManifest.XML file by modifying the XML file in such a way that it does not comply with Google standards but still gets executed properly and installs the application as usual, which stands as the first vulnerability availed.

    Secondly, the Dex2Jar utility, that helps researchers to convert .dex to .jar files, has an error that it fails to convert the dex to jar properly, which takes the second place in the vulnerability order.

    As third one, this malware registers as a device admin and utilises a vulnerability that it does not appear in the administrator list. By Android Framework, only user level applications (non-administrators) can be uninstalled by the user through uninstall option under settings whereas for the device administrators, uninstallation is possible only from the device administrator list. As this malware does not have any icon and runs in the background, absence of the application name in the administrator list makes it tough for an end user to identify the infection and delete the application.

    It is also under discussion that because of the flaw in the XML encoding in dexguard 5.2.00 and the fact that the application is missing the associated label, which is required to display the application name in the Device administrators list, this malwares enjoying the administrator privileges without being listed under the administrators. Even though the malware does not aim at hiding itself or exploiting a vulnerability in the system, the vulnerabilities in the development environment and the supporting tools, may make it relatively tough to statically analyse a malware.

    Privilege Escalation Vulnerability:

    To procure the root access, there were malware instances that invoked other application in the victim’s device that require root access or driving the user to grant the root access to the application. As a step ahead, exploiting vulnerability in the Android OS to acquire administrative rights was also witnessed in case of Android TrojanSpy Droiddream that carries Exploid and RageAgainsttheCage.

    The daemon process, Android Debug Bridge in Android, when started runs with the root permissions but later, the daemon drops its root permissions with the help of setuid() to run as a user process.The problem arises when there are maximum number of user processes are already running in the system.

    Exactly the same happens in case of the malware Android Droiddream where RageAgainsttheCage confirms the max count of user processes (RLIMIT_NPROC) and forges the required number of processes to reach its limit. Now the exploit kills one of the processes and restarts the adb process. But as the target user’s process had already reached its maximum (RLIMIT_NPROC), setuid() fails. However, setuid() function’s return value is not verified and the adbd also fails to drop its privileges and continues to run as root.

    Technical Analysis of Droiddream malware describes that RageAgainsttheCage is tried first and at the failure of which, is called Exploid, an udev exploit. This second exploit executes by using hotplug that is run by changing the state of the wi-fi adapter and resuming to its original state.  Successful execution of these exploits aids the malware with root access.

    The above described vulnerabilities had a huge impact on the malware approach to silently have venomous actions in the compromised device.

    Android OS Update

    According to Google’s architecture for OS update, a user will receive updates from the respective device manufacturers/carriers. The reason behind is to aid the handset manufacturers/OEM versions to customize the updates for their device design. But many a time, the update process is slow that it resulted in a delay for a user to receive updates or at times the user could miss the update at all, that leaves them exposed to the dangerous vulnerabilities. Considering the data security of an Android user, Google should release increased and regular security updates without waiting for any upcoming GUI/OS update. Also it is debated many a times that updates should be directly available to the user instead of routing through the device company. User responsibility also has a share in this topic, to regularly check for updates and update the device, if any to avoid any uncool situations.

    Risk Mitigation

    Apparently, to mitigate the risk of vulnerability, there should be technology improvements in the Android OS that enhances the security context. The implementation of most awaited deployment SELinux3, Mandatory Access control (MAC) in Android OS could help solve the problem. With SELinux, MAC layer can control the user access to both their and the system data. Interestingly, with extra layer of security, it is possible to define system-wide policies, applicable for Super User (root) even.

    It works by defining policies that describes the type of interactions a process is allowed to. For example, if a daemon process has a system-wide policy defined to access only a file with a specific label, then the process cannot access any other file. This acts as a solution to the privilege escalation vulnerability, but unfortunately SELinux is implemented only in the permissive mode. Removing the permissive mode and imposing the SELinux along with the regular OS/Security update with no delay could reduce the opportunities for exploits in the malware spread. Eventually, Google could come up with a vulnerability scanner for different versions of Android OS, which the users can make use of and proceed further to their carriers to patch the unpatched device.

    Conclusion

    Evidently, there is a rise in the smartphone usage around the world in both personal and business sectors. As quoted earlier, Google’s Android also contains vulnerabilities. It is a known fact that there are mobile malware in the rounds targeting the OS vulnerabilities to accomplish their noxious activities. These malware, even though, avail exploitation techniques to infect a device, their ultimate aim is at financial benefits by stealing user’s banking details, or stealing user data or personal information. Victimizing smartphones that are engaged in business communication can still intricate the situation. It is demonstrated already by Android malware to adapt to advanced evasion technique, which is expected to continue in the future as well. Hence, to overcome this scenario, regular security and/or OS updates should be made available to the user, to patch the disclosed vulnerability(s). With the enforcement of the SELinux technique in Android could considerably reduce the vulnerability risk in the system.

    References:
    2.  http://www.saurik.com/id/17
    3. http://source.android.com/devices/tech/security/se-linux.html

    Images courtesy of:
    Moneycrashers.com

    V.Dhanalakshmi
    Senior Threat Researcher, K7TCL

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

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