By Will Klieber
Member of the Technical Staff
This blog post was co-authored by Lori Flynn.
Although the Android Operating System continues to dominate the mobile device market (82 percent of worldwide market share in the third quarter of 2013), applications developed for Android have faced some challenging security issues. For example, applications developed for the Android platform continue to struggle with vulnerabilities, such as activity hijacking, which occurs when a malicious app receives a message (in particular, an intent) that was intended for another app but not explicitly designated for it. The attack can result in leakage of sensitive data or loss of secure control of the affected apps. Another vulnerability is exploited when sensitive information is leaked from a sensitive source to a restricted sink. This blog post is the second in a series that details our work to develop techniques and tools for analyzing code for mobile computing platforms. (A previous blog post, Secure Coding for the Android Platform, describes our team’s development of Android rules and guidelines.)
This post is the second in a series on prioritizing malware analysis.
By Jose Andre Morales
Cyber Security Solutions Division
Every day, analysts at major anti-virus companies and research organizations are inundated with new malware samples. From Flame to lesser-known strains, figures indicate that the number of malware samples released each day continues to rise. In 2011, malware authors unleashed approximately 70,000 new strains per day, according to figures reported by Eugene Kaspersky. The following year, McAfee reported that 100,000 new strains of malware were unleashed each day. An article published in the October 2013 issue of IEEE Spectrum, updated that figure to approximately 150,000 new malware strains. Not enough manpower exists to manually address the sheer volume of new malware samples that arrive daily in analysts’ queues. In our work here at CERT, we felt that analysts needed an approach that would allow them to identify and focus first on the most destructive binary files. This blog post is a follow up of my earlier post entitled Prioritizing Malware Analysis. In this post, we describe the results of the research I conducted with fellow researchers at the Carnegie Mellon University (CMU) Software Engineering Institute (SEI) and CMU’s Robotics Institute highlighting our analysis that demonstrated the validity (with 98 percent accuracy) of our approach, which helps analysts distinguish between the malicious and benign nature of a binary file.
By Nader Mehravari
Senior Member of the Technical Staff
CERT Cyber Risk Management Team
October 2010, two packages from Yemen containing explosives were
discovered on U.S.-bound cargo planes of two of the largest worldwide
shipping companies, UPS and FedEx, according to reports by CNN and the Wall Street Journal.
The discovery highlighted a long-standing problem—securing
international cargo—and ushered in a new area of concern for such
entities as the United States Postal Inspection Service (USPIS) and the Universal Postal Union (UPU),
a specialized agency of the United Nations that regulates the postal
services of 192 member countries. In early 2012, the UPU and several
stakeholder organizations developed two standards to improve security in
the transport of international mail and to improve the security of
critical postal facilities. As with any new set of standards, however, a
mechanism was needed to enable implementation of the standards and
measure compliance to them. This blog post describes the method
developed by researchers in the CERT Division at Carnegie Mellon
University’s Software Engineering Institute, in conjunction with the
USPIS, to identify gaps in the security of international mail processing
centers and similar shipping and transportation processing facilities.
By Julien Delange
Member of the Technical Staff
Software Solutions Division
The Architecture Analysis and Design Language (AADL)
is a modeling language that, at its core, allows designers to specify
the structure of a system (components and connections) and analyze its
architecture. From a security point of view, for example, we can use
AADL to verify that a high-security component does not communicate with a
low-security component and, thus, ensure that one type of security leak
is prevented by the architecture. The ability to capture the behavior
of a component allows for even better use of the model. This blog post
describes a tool developed to support the AADL Behavior Annex and allow
architects to import behavior from Simulink (or potentially any other notation) into an architecture model.