|Title||Dissecting Android Malware: Characterization and Evolution [link]|
|Author||Yajin Zhou and Xuxian Jiang from CS in NSCU||yajin email@example.com|
|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.|
1. Goals and contributions
2. Malware Characterization
(1) Malware Installation:
(2) Activation: BOOT_COMLETED, SMS_RECEIVED, ACTION_MAIN
(3) Malicious Payloads
(4) Permission Uses
3. Malware Detection
(1) Anti-Virus Products
(2) signature base: 20.2% – 79.6%
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.
|Title||SoK: Eternal War in Memory [Link]|
|Author||Laszlo Szekeresy, Mathias Payerz, Tao Wei, Dawn Song|
|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.
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.
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.
|Title||Tor: The Second-Generation Onion Router [Link]|
|Author||Roger Dingledine, Nick Mathewson and Paul Syversonfirstname.lastname@example.org|
|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.|
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
4. The Tor Design
5. Rendezvous Points and hidden services
6. Other design decisions
7. Attacks and Defenses
|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.|