[Paper] Dissecting Android Malware: Characterization and Evolution

Title Dissecting Android Malware: Characterization and Evolution [link]
Author Yajin Zhou and Xuxian Jiang from CS in NSCU Email yajin zhou@ncsu.edu
Publishing SP ’12 Proceedings of the 2012 IEEE Symposium on Security and Privacy Year 2012
Abstract The popularity and adoption of smartphones has greatly stimulated the spread of mobile malware, especially on the popular platforms such as Android. In light of their rapid growth, there is a pressing need to develop effective solutions. However, our defense capability is largely constrained by the limited understanding of these emerging mobile malware and the lack of timely access to related samples. In this paper, we focus on the Android platform and aim to systematize or characterize existing Android malware. Particularly, with more than one year effort, we have managed to collect more than 1,200 malware samples that cover the majority of existing Android malware families, ranging from their debut in August 2010 to recent ones in October 2011. In addition, we systematically characterize them from various aspects, including their installation methods, activation mechanisms as well as the nature of carried malicious payloads. The characterization and a subsequent evolution-based study of representative families reveal that they are evolving rapidly to circumvent the detection from existing mobile anti-virus software. Based on the evaluation with four representative mobile security software, our experiments show that the best case detects 79.6% of them while the worst case detects only 20.2% in our dataset. These results clearly call for the need to better develop next-generation anti-mobile-malware solutions.
Summary
1. Goals and contributions
  • Presenting large collection of 1260 Android malware samples in 49 malware families
  • Performing a timeline analysis of discovery based on characterization
  • Performing an evolution-based study of representative Android malare

 androidmalware

2. Malware Characterization

(1) Malware Installation:
  • Repackaging (86%) to piggyback malicious payloads into popular applications
  • Update Attack: Updating component that fetch or download the malicious payloads at runtime
  • Drive-by Download: Enticing users to download “interesting” or “feature-rich” applications
  • Other groups: spyware, fake apps, apps including functionality with purposeful malice, root privilege
(2) Activation: BOOT_COMLETED, SMS_RECEIVED, ACTION_MAIN
(3) Malicious Payloads
  • Privilege Escalation (36.7%): Platform level exploits
  • Remote Control (93%): Bot-like capability (C&C)
  • Financial Charge(45.3%): Premium background SMS
  • Information Collection
(4) Permission Uses
  • Benign and malicious app: INTERNET, READ_PHONE_STATE, ACCESS_NETWORK_STATE, WRITE_EXTERNAL_STORAGE
  • Malicious app only: READ_SMS, WRITE_SMS, RECEIVE_SMS, SEND_SMS
 
3. Malware Detection
(1) Anti-Virus Products
  • AVG Antivirus Free v2.9 (or AVG)
  • Lookout Security & Antivirus v6.9 (or Lookout)
  • Norton Mobile Security Lite v2.5.0.379 (Norton)
  • TrendMicro Mobile Security Personal Edition v2.0.0.1294 (TrendMicro)
(2) signature base: 20.2% – 79.6%
Note

This paper illustrates Android malware features in common, analyzing a large collection (over 1,200) in a chronological order. It  raised a need of systematic Android malware analysis, which is not presence today despite of rapid growing in number. The authors collected 1,200 malware samples and classified them into 49 families (categories). A variety of findings has been shown in terms of characterization including malware installation, activation, malicious payloads, and permission use, which provides useful insight to identify Android malware in the near future when deciding if an application is suspicious.

Although the authors mentioned that existing mobile anti-virus application poorly detected malware, the biggest reason might be due to lack of samples as anti-virus detection normally depends on the signatures. It would be great the study could be carried out in a regular basis, making a comparison in changes.

[Paper Review] SoK: Eternal War in Memory

Title SoK: Eternal War in Memory [Link]
Author Laszlo Szekeresy, Mathias Payerz, Tao Wei, Dawn Song Email
Publishing SP ’13 Proceedings of the 2013 IEEE Symposium on Security and Privacy Year 2013
Abstract Memory corruption bugs in software written in low-level languages like C or C++ are one of the oldest problems in computer security. The lack of safety in these languages allows attackers to alter the program’s behavior or take full control over it by hijacking its control flow. This problem has existed for more than 30 years and a vast number of potential solutions have been proposed, yet memory corruption attacks continue to pose a serious threat. Real world exploits show that all currently deployed protections can be defeated. This paper sheds light on the primary reasons for this by describing attacks that succeed on today’s systems. We systematize the current knowledge about various protection techniques by setting up a general model for memory corruption attacks. Using this model we show what policies can stop which attacks. The model identifies weaknesses of currently deployed techniques, as well as other proposed protections enforcing stricter policies. We analyze the reasons why protection mechanisms implementing stricter polices are not deployed. To achieve wide adoption, protection mechanisms must support a multitude of features and must satisfy a host of requirements. Especially important is performance, as experience shows that only solutions whose overhead is in reasonable bounds get deployed. A comparison of different enforceable policies helps designers of new protection mechanisms in finding the balance between effectiveness (security) and efficiency. We identify some open research problems, and provide suggestions on improving the adoption of newer techniques.
Summary 1. Attack model demonstrating four exploit types and policies mitigating the attacks in different stages.memorycorruption1

2. The different protection techniques according to their policy and comapres the performance impact, deployment status (DEP), compatibility issues, and main attack vectors that circumvent the protection.

memorycorruption2

Note

This paper systematically clarifies how memory corruption attacks have been performed for the last 30 years at a glance although many kinds of countermeasures have been introduced to mitigate them.It also explains how memory corruption bugs are still hard to fix completely, and discusses a couple of approaches. It illustrates pros and cons of each defense mechanism including data integrity, data-flow integrity, code pointer integrity, and control flow integrity.

The authors introduced a set of defenses which hardens memory corruption attacks like stack cookies, data execution prevention (DEP), address space layout randomization (ASLR). However, they are not enough when attack vectors focus on return-oriented programming (ROP), information leaks, prevalent use of user scripting and just-in-time (JIT) compilation. Still the defense against attacks using ROP and JIT is active research area.

[PAPER REVIEW] Tor: The Second-Generation Onion Router

Title Tor: The Second-Generation Onion Router [Link]
Author Roger Dingledine, Nick Mathewson and Paul Syverson Email arma@freehaven.net
Publishing 13th USENIX Security Symposium Year 2004
Abstract We present Tor, a circuit-based low-latency anonymous communication service. This second-generation Onion Routing system addresses limitations in the original design by adding perfect forward secrecy, congestion control, directory servers, integrity checking, configurable exit policies, and a practical design for location-hidden services via rendezvous points. Tor works on the real-world Internet, requires no special privileges or kernel modifications, requires little synchronization or coordination between nodes, and provides a reasonable tradeoff between anonymity, usability, and efficiency. We briefly describe our experiences with an international network of more than 30 nodes. We close with a list of open problems in anonymous communication.
Summary I. Overview

  • Circuit based, fixed-size cells
  • Design: Perfect forward secrecy, Separation of “protocol cleaning” from anonymity, No mixing, padding, or traffic shaping, Many TCP streams can share one circuit, Leaky-pipe circuit topology, Congestion Control, Directory Servers, Variable exit policies, End-to-end integrity checking, Rendezvous points and hidden services

2. Related Work

Mix-Net, Babel, Mix-master, Mixminion, Anonymizer, Java Anon Proxy, PipeNet, ISDN mixes,    Tarzan, MorphMix, Crowds, Hordes, Herbivore, P5, Freedom, Cebolla, Anonymity Network, …

3. Design goals and assumptions

  • Goals: Deployability, Usability, Flexibility, Simple Design
  • Non-goals: Not peer-to-peer, Not secure against end-to-end attacks, No protocol normalization, Not steganographic

4. The Tor Design

  • Overlay network: each OR runs as a normal user-level process, and OP(Onion Proxy) to fetch directories and establish circuits.
  • Two keys: long-term identity key to sign TLS certificate and OR’s router descriptor, short-term onion key to decrypt requests
  • Cells:
    tor1
  • Circuits and streams: Once a sender established a circuit, he can send relay cells
    tor2
  • Brief Steps:
    (a) Opening and closing streams
    (b) Integrity checking on streams
    (c) Rate limiting and fairness:
    (d) Circuit-level throttling: packaging window, delivery window)
    (e) Stream-level throttling: relay sendme cells to implement end-to-end flow control

5. Rendezvous Points and hidden services

  • Goals: Access-control, Robustness, Smear-resistance, Application-transparency
  • Integration with user applications:
    FQDN (x.y.onion where x=authorization cookie, y=hash of the public key)
  • Procedures
    Bob generates a long-term public key pair to identify his service
    Bob chooses some introduction points, and advertises them on the lookup service
    Bob builds a circuit to each of his introduction points, and tells them to wait for requests
    Alice learns about Bob’s service out of band, retrieving the details from the lookup service
    Alice chooses an OR as the rendezvous point (RP) for her connection to Bob’s service
    Alice opens an anonymous stream to one of Bob’s introduction points
    Alice gives it a message including her RP, rendezvous cookie, and then a DH handshake
    The RP connects Alice’s circuit to Bob’s. (RP can’t recognize Alice, Bob, or the data)
    Alice sends a relay begin cell along the circuit, arriving at Bob’s OP and Bob’s webserver.
    An anonymous stream has been established, then Alice and Bob communicate as normal.

6. Other design decisions

  • Denial of Service
    (a) CPU-consuming denial-of-service attacks: requiring clients to solve a puzzle while TLS handshaking or accepting create cells
    (b) Disrupting a single circuit or link breaks all streams passing along that part of the circuit (end-to-end TCP ACK protocol)
  • Exit-policies and abuse
    (a) Attackers can harm the Tor network by implicating exit servers for their abuse. (This remains an arms race (unsolved))
    (b) Mitigation: each onion router’s exit policy describes to which external addresses and ports the router will connect.
  • Directory Servers
    (a) Partitioning attack to deceive a client about the router membership list, topology, or current network state
    (b) Act as an HTTP server, so clients can fetch current network state and router lists, and so other ORs can upload state info.

7. Attacks and Defenses

  • Passive Attacks
    • Observing user traffic patterns.
    • Observing user content.
    • Option distinguishability.
    • End-to-end timing correlation.
    • End-to-end size correlation.
    • Website fingerprinting.
  • Active Attacks
    • Compromise keys.
    • Iterated compromise.
    • Run a recipient.
    • Run an onion proxy.
    • DoS non-observed nodes.
    • Run a hostile OR.
    • Introduce timing into messages.
    • Tagging attacks.
    • Replace contents of unauthenticated protocols.
    • Replay attacks.
    • Smear attacks.
    • Distribute hostile code..
  • Directory Attacks
    • Destroy directory servers.
    • Subvert a directory server.
    • Subvert a majority of directory servers.
    • Encourage directory server dissent.
    • Trick the directory servers into listing a hostile OR.
    • Convince the directories that a malfunctioning OR is working.
  • Attacks against R/P
    • Make many introduction requests.
    • Attack an introduction point.
    • Compromise an introduction point.
    • Compromise a rendezvous point.
Note One of the best papers in terms of anonymity implementation. The tor is currently one of the largest deployed anonymous network over the world. Although there are a variety of conceptually anonymous networks and several ones in practice, tor is the most popular (as of now having millions of users) amongst them.This paper presents a circuit-based low-latency anonymous communication service. It addresses the limitations for the first tor implementation by adding a large number of features such as perfect forward secrecy, directory servers, integrity checking, configurable exit policies, and location-hidden services via rendezvous points.As authors mentioned, one of the biggest problem would be exit abuse, however, this might be remediated if end-to-end confidentiality have been used. One of side effects is to take advantage of high-level anonymity for the malicious purpose like spreading malware, exploit routes to avoid being kept track and/or IP laundry, which seems obvious now.