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

Associate Security Consultant, Varutra Consulting Pvt. Ltd.

01/30/16

How To Develop Secure Software – Action Plan To Make Secure

The purpose of this article is to provide a guideline for secure software development. Easily avoided software defects are a primary cause of commonly exploited software vulnerabilities. By identifying insecure coding practices and developing secure alternatives, software developers can take practical steps to reduce or eliminate vulnerabilities while developing software product.

According to a study released last year by WhiteHat Security, Cross-Site Scripting regains the number one spot after being overtaken by Information Leakage last year in all but one language. .Net has Information Leakage as the number one vulnerability, followed by Cross-Site Scripting. ColdFusion has a rate of 11% SQL Injection vulnerabilities, the highest observed, followed by ASP with 8% and .NET 6%. Perl has an observed rate of 67% Cross-Site Scripting vulnerabilities, over 17% more than any other language. There was less than a 2% difference among the languages with Cross-Site Request Forgery. Many vulnerabilities classes were not affected by language choice.

The most effective way to reduce application security risk is to implement a formal development process that includes security best practices to avoid application vulnerabilities. Secure Development process and Security Testing are powerful tools to monitor and search for application flaws and they should be used together to increase the security level of business critical applications/software.

Secure coding is the practice of writing code for applications in such a way as to ensure the confidentiality, integrity and accessibility of data and information related to those systems. Programmers fluent in secure coding practices can avoid common security flaws in programming languages and follow best practices to avoid the number of targeted attacks that focus on application vulnerabilities.

Application security is a process that begins from the application development lifecycle to ensure the highest security possible of the development process (coding), the system, hardware the application runs on and the network it uses to connect, authenticate and authorize users. Building secure software and incorporating security best practices in development process is the responsibility of all the stakeholders involved with the Software Development Lifecycle (SDLC).

1

Figure: SDLC Stakeholders

INTRODUCTION

The current trend is to identify issues by performing a security assessment of applications after they are developed and then fix these issues. Patching software in this way can help, but it is a costlier approach to address the issues.

This cycle of Testing – Patching – Re-testing runs into multiple iterations and can be avoided to a great extent by addressing issues earlier in the Life Cycle. This next section covers a very important aspect – the need for programs like S-SDLC.

As an old saying goes – “Need is the mother of invention” – this is applicable for Secure software development as well. There were days when organizations were just interested in developing an application and selling it to the client and forgetting about rest of the complexities. Those days are gone.

A very simple answer to the question is – “The threat landscape has changed drastically.” There are people out there whose only intention is to break into computer systems and networks to damage them, whether it is for fun or profit. These could be novice hackers who are looking for a shortcut to fame by doing so and bragging about it on the internet. These could also be a group of organized criminals who work silently on the wire. They don’t make noise but when their job is done, it reflects into a huge loss for the organization in question – not to mention a huge profit for such criminals.

This is where secure development comes into the picture. While employing a team of ethical hackers helps, having processes like secure development can help organizations in addressing the above discussed issues in a much more cost-efficient manner as identifying security issues earlier in the development life cycle reduces the cost.

Want to build secure application and keep your application from getting hacked? Here’s a guideline to build secure application and how to get serious about secure apps.

Let’s get serious about building secure Web applications.

 

THINGS YOU NEED TO DO IN A SECURE SOFTWARE DEVELOPMENT

1. AUTHENTICATION AND AUTHORIZATION:

Don’t hardcode credentials: Never allow credentials to be stored directly within the application code.
Example: Hard coded passwords in networking devices https://www.us-cert.gov/control_systems/pdf/ICSA-12-243-01.pdf

Implement a strong password policy: A password policy should be created and implemented so that passwords meet specific strength criteria. Implement account lockout against brute force attacks: Account lockout needs to be implemented to guard against brute forcing attacks against both the authentication and password reset functionality. After several tries on a specific user account, the account should be locked for a period of time or until manually unlocked.

2. SESSION MANAGEMENT:

Invalidate the session after logout: When the user logs out of the application the session and corresponding data on the server must be destroyed. This ensures that the session cannot be accidentally revived.

Implement an idle session timeout: When a user is not active, the application should automatically log the user out. Be aware that Ajax applications may make recurring calls to the application effectively resetting the timeout counter automatically.

Use secure cookie attributes (i.e. httponly and secure flags): The session cookie should be set with both the HttpOnly and the secure flags. This ensures that the session id will not be accessible to client-side scripts and it will only be transmitted over SSL, respectively.

3. INPUT AND OUTPUT HANDLING/VALIDATION:

Prefer whitelists over blacklists: For each user input field, there should be validation on the input content. Whitelisting input is the preferred approach. Only accept data that meets a certain criteria. For input that needs more flexibility, blacklisting can also be applied where known bad input patterns or characters are blocked.

Use parameterized SQL queries: SQL queries should be crafted with user content passed into a bind variable. Queries written this way are safe against SQL injection attacks. SQL queries should not be created dynamically using string concatenation. Similarly, the SQL query string used in a bound or parameterized query should never be dynamically built from user input.

Use CSRF tokens to prevent forged requests: In order to prevent Cross-Site Request Forgery attacks, you must embed a random value that is not known to third parties into the HTML form. This CSRF protection token must be unique to each request. This prevents a forged CSRF request from being submitted because the attacker does not know the value of the token.

Validate uploaded files: When accepting file uploads from the user make sure to validate the size of the file, the file type, and the file contents as well as ensuring that it is not possible to override the destination path for the file.

Validate the source of input: The source of the input must be validated. For example, if input is expected from a POST request, do not accept the input variable from a GET request.

X-XSS- Protection headers: Content Security Policy (CSP) and X-XSS-Protection headers help defend against many common reflected Cross-Site Scripting (XSS) attacks.

4. ACCESS CONTROL:

Apply the principle of least privilege: Make use of a Mandatory Access Control system. All access decisions will be based on the principle of least privilege.
Don’t use direct object references for access control checks: Do not allow direct references to files or parameters that can be manipulated to grant excessive access. Access control decisions must be based on the authenticated user identity and trusted server side information.

Use only trusted system objects, e.g. server side session objects, for making access authorization decisions. Use a single site-wide component to check access authorization. This includes libraries that call external authorization services.

5. PROPER ERROR HANDLING AND LOGGING:

Error messages should not reveal details about the internal state of the application. For example, file system path and stack information should not be exposed to the user through error messages.

Logs should be stored and maintained appropriately to avoid information loss or tampering by intruder. Log retention should also follow the retention policy set forth by the organization to meet regulatory requirements and provide enough information for forensic and incident response activities.

Do not disclose sensitive information in error responses, including system details, session identifiers or account information.
Logging controls should support both success and failure of specified security events.

6. DATA PROTECTION:

Ideally, SSL should be used for your entire application. If you have to limit where it’s used, then SSL must be applied to any authentication pages as well as all pages after the user is authenticated. If sensitive information (e.g. personal information) can be submitted before authentication, those features must also be sent over SSL.

Implement least privilege; restrict users to only the functionality, data and system information that are required to perform their tasks.

Encrypt highly sensitive stored information, like authentication verification data, even on the server side. Always use well vetted algorithms, see “Cryptographic Practices” for additional guidance.

7. BUSINESS LOGIC:

Business logic vulnerability is one that allows the attacker to misuse an application by circumventing the business rules. Most security problems are weaknesses in an application that result from a broken or missing security control.

This will help to identify the minimum standard that is required to neutralize vulnerabilities in your critical applications. Phases been addressed? Have you made all the proper configuration settings in the database, web server, etc.?

 

ACTION PLAN TO MAKE SECURE SOFTWARE

These help organizations to think about security early on in the project. They represent specific security goals and constraints that affect the confidentiality, integrity and availability of important application data and the means by which that is accessed. If these requirements aren’t specified they won’t be built or tested.

“The key problem is that, at the network level, data used to exploit security flaws is often indistinguishable from legitimate application data. Our only hope is to tackle vulnerabilities at their root – in the applications themselves.”

STEP 1. THREAT MODELLING:

Threat modelling is an approach for analysing the security of an application. It is a structured approach that enables you to identify, quantify, and address the security risks associated with an application. Threat modelling is not an approach to reviewing code, but it does complement the security code review process. The inclusion of threat modelling in the SDLC can help to ensure that applications are being developed with security built-in from the very beginning.
There are several good reference guides to help with threat modelling, including a free threat modelling reference from the National Institute of Standards and Technology (NIST).

STEP 2. ARCHITECTURE AND DESIGN REVIEW PROCESS:

The architecture and design review process analyses the architecture and design from a security perspective. If you have just completed the design, the design documentation can help you with this process. Regardless of how comprehensive your design documentation is, you must be able to decompose your application and be able to identify key items, including trust boundaries, data flow, entry points, and privileged code. You must also know the physical deployment configuration of your application. Pay attention to the design approaches you have adopted for those areas that most commonly exhibit vulnerabilities. This guide refers to these as application vulnerability categories. There are many excellent resources available for code reviews including those from Microsoft.

STEP 3. GET DEVELOPERS SECURITY-SAVVY:

The most effective solution is to train developers from the beginning on secure coding techniques. The securitysavvy software developer leads all developers in the creation of secure software, implementing secure programming techniques that are free from logical design and technical implementation flaws. This expert is
ultimately responsible for ensuring customer software is free from vulnerabilities that can be exploited by an attacker. At the implementation stage, security is largely a developer awareness problem. Given a specific requirement or design, code can be written in a vast number of ways to meet that objective. Each of these can lead to an application that meets its functional requirements.

By implementing these secure coding standards in your organisation and enforcing them through secure code reviews and static analysis tools, you can suppress one of the most common causes of released vulnerabilities in software.

“Security design reviews give an early insight into potential problems, as does threat modelling, and both can be performed early where security defects are easier and less costly to fix.”

STEP 4. PENETRATION TESTING:

Penetration testing (also called pen testing) is the practice of testing a computer system, network or Web application to find vulnerabilities that an attacker could exploit. Pen tests can be automated with software applications or they can be performed manually. Either way, the process includes gathering information about the target before the test (reconnaissance), identifying possible entry points, attempting to break in (either virtually or for real) and reporting back the findings.

This puts the application through the paces of a series of attacks. Output from the threat models can be reused here to establish the focus and scope of the testing. For example, did the tester try a series of SQL injection attacks vs. Cross Site Scripting? Did the tester attack the user interface vs. the database server?

 

diagram_steps

Figure: Penetration Testing

STEP 5. FINAL SECURITY REVIEW:

This step is conducted prior to deployment and is the last look in the mirror before walking out the door. Have all those weak spots found in the threat modeling and penetration testing.

 

SECURITY PRINCIPLES FOR SECURE CODE DEVELOPMENT

1. MINIMIZE ATTACK SURFACE AREA:

Every feature that is added to an application adds a certain amount of risk to the overall application. The aim for secure development is to reduce the overall risk by reducing the attack space.

2. PRINCIPLE OF LEAST PRIVILEGE:

The principle of least privilege recommends that accounts have the least amount of privilege required to perform their business processes. This encompasses user rights, resource permissions, such as CPU limits, memory, network, and file system permissions.

3. PRINCIPLE OF DEFENSE IN DEPTH:

The principle of Defense in Depth suggests that where one control would be reasonable, more controls that approach risks in different fashions are better.
Controls, when used in depth, can make severe vulnerabilities extraordinarily difficult to exploit and thus unlikely to occur. With secure coding, this may take the form of tier-based validation, centralized auditing controls, and requiring users to be logged on all pages.

4. FAIL SECURELY

Applications regularly fail to process transactions for many reasons. How they fail can determine if an application is secure or not. External systems are insecure. Many organizations utilize the processing capabilities of third-party partners, who more than likely have differing security policies and posture. It is unlikely that an external third party can be influenced or controlled; implicit trust of externally run systems is not warranted. All external systems should be treated in a similar fashion.

5. SEPARATION OF DUTIES

A key fraud control is separation of duties. For example, someone who requests a computer cannot also sign for it, nor should they directly receive the computer. This prevents the user from requesting many computers, and claiming they never arrived. Certain roles have different levels of trust than normal users. In particular, Administrators are different to normal users. In general, administrators should not be users of the application.

6. DO NOT TRUST SECURITY THROUGH OBSCURITY

Security through obscurity is a weak security control, and nearly always fails when it is the only control. This is not to say that keeping secrets is a bad idea, it simply means that the security of key systems should not be reliant upon keeping details hidden.

7. SIMPLICITY

Attack surface area and simplicity go hand-in-hand. Certain software engineering fads prefer overly complex approaches to what would otherwise be relatively straightforward and simple code. Developers should avoid the use of double negatives and complex architectures when a simpler approach would be faster and simpler.

8. FIX SECURITY ISSUES CORRECTLY

Once a security issue has been identified, it is important to develop a test for it, and to understand the root cause of the issue. When design patterns are used, it is likely that the security issue is widespread amongst all code bases, so developing the right fix without introducing regressions is essential.

THE TEN BEST PRACTICES
1. Protect the Brand Your Customers Trust
2. Know Your Business and Support it with Secure Solutions
3. Understand the Technology of the Software
4. Ensure Compliance to Governance, Regulations, and Privacy
5. Know the Basic Tenets of Software Security
6. Ensure the Protection of Sensitive Information
7. Design Software with Secure Features
8. Develop Software with Secure Features
9. Deploy Software with Secure Features
10. Educate Yourself and Others on How to Build Secure Software

BENEFITS OF SECURE SDLC

1. Build more secure software
2. Help address security compliance requirements
3. Reduce costs of maintenance
4. Awareness of potential engineering challenges caused by mandatory security controls
5. Identification of shared security services and reuse of security strategies and tools
6. Early identification and mitigation of security vulnerabilities and problem
7. Documentation of important security decisions made during the development

CONCLUSION:

Security and development teams can work together—they just need to look for common areas in which they can make improvements. Security teams focus on confidentiality and integrity of data, which can sometimes require development teams to slow down and assess code differently. At the same time, business units require developers to produce and revise code more quickly than ever, resulting in developers focusing on what works best instead of what is most secure.
This difference in focus does not mean that either side is wrong. In fact, both teams are doing exactly what they’re supposed to do. However, in order to facilitate teams accomplishing both sets of goals and working together more fluidly, changes to tools and processes are necessary.

REFERENCES:

1. http://info.whitehatsec.com/rs/whitehatsecurity/images/statsreport2014-20140410.pdf
2. https://www.owasp.org/images/7/7c/OWASP-Building-Secure-Web-Apps-070110.pdf
3. https://www.us-cert.gov/control_systems/pdf/ICSA-12-243-01.pdf
4. https://www.owasp.org/index.php/The_Owasp_Code_Review_Top_9
5. https://www.owasp.org/index.php/Testing_for_authentication
6. https://www.owasp.org/index.php/Web_Application_Security_Testing_Cheat_Sheet
7. https://www.owasp.org/index.php/Application_Threat_Modeling

 

AUTHOR:

Security Consultant, Varutra Consulting, Pvt. Ltd.

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:

Mr. Chetan Gulhane

Security Consultant, Varutra Consulting Pvt. Ltd.

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

07/18/14

Mobile Application Security Assessment – Proxying for Windows Phone

While conducting mobile application penetration testing of Windows Phone capturing application traffic will allow penetration tester to modify the traffic and analyze the responses from the server. This is important to understand the behavior of application and to find out possible vulnerabilities in it.

In this blog we will learn how to capture application’s traffic on Windows Phone.

Burp Proxy Setting :

1.  Select Proxy tab and under Proxy tab select Option tab. Now click on Add.

2.  Enter proxy port (eg. 8080) and select All Interfaces. Now click on OK.

http://varutra.com/blog/wp-content/uploads/2014/07/Proxy.jpg

3.  Select the Proxy Listener you have created just now.

Capturing Windows Phone Traffic Using Burp Proxy :

1.  On Windows Phone navigate to Settings

Mobile Hacking-2

2.  Tap the Setting and select the WiFi

3.  After Selecting WiFi all the WiFi Network details will be shown

Mobile Hacking-3

4.  Select the WiFi Network you are connected after selecting the WiFi Network you are connected  tap to on the Proxy

5.  Under Edit Network enter Proxy IP and Port. (e.g. 10.1.1.132:8080)

Mobile Hacking-4

6.  Now http/https traffic from windows phone can be intercepted. Happy Testing  🙂 🙂 🙂

http://varutra.com/blog/wp-content/uploads/2014/07/Mobile-Hacking-5.jpg

 Author: Snehal Raut

Security Consultant, Varutra Consulting

 

To read about how to proxy for Android and iOS Devices.