We are co-organizing the First International Workshop on Agile Secure Software Development (ASSD’15) with Prof. Röning from University of Oulu, Finland. The workshop is organized in conjunction with ARES 2015, which will be hosted in Toulouse, France from 24th to 28th August, 2015. We are looking for papers related to applying the agile approach and methods to develop secure software. We encourage you to submit your paper to the workshop.
Cross-posted from SEEBlog
Read on here for an extensive interview with Steven Arzt in the Süddeutsche Zeitung about the recent malware threat we discovered and about Android malware in general. Spiegel Online also has an article that draws information from the interview.
Cross-posted from SEEBlog
Our micro-benchmark suite DroidBench (published with FlowDroid at PLDI’14) aims at testing the precision and recall of static taint tracking tools for Android. It provides categorized, tested, and well-documented test cases for the various hard challenges in program analysis. The ground truth is provides makes it easy to check and compare the results of the various information-flow analysis tools proposed both in research and available commercially.
The suite has been used by various research groups all over the world and we have seen tools greatly improve on the precision and recall they achieve on DroidBench. With many tools now achieving very good results, it is time for new challenges.
We are thus happy to announce that DroidBench 2.0 is now available from Github. It features 120 test cases in 13 categories including aliasing, implicit data flows, Android lifecycle handling, inter-component communication, and reflective method calls. We would like to thank all the researchers world wide that have contributed to DroidBench and would like to extend this call: Feel free to propose and/or submit new test cases to extend the suite even further so that it can continue to serve as a standardized benchmark suite for research in the field of static taint tracking.
All kinds of contributions are welcome. We have started to also add test cases challenging dynamic analysis tools, for instance emulator-detection mechanisms. In the future, we also plan to add test cases that leverage native code to hide data flows.
Cross-posted from SEEBlog
We are happy to announce that our paper “DroidSearch: A Tool for Scaling Android App Triage to Real-World App Stores” has been accepted for publication at the IEEE Technically Co-Sponsored “Science and Information Conference 2015″ (SAI) in London, UK.
While many precise analysis tools for detecting malware and finding vulnerabilities in Android applications exist, they usually do not scale to the large number of applications in today’s real-world markets such as Google Play. We therefore present DroidSearch, a search engine that aids a multi-staged analysis in which fast pre-filtering techniques allow security experts to quickly retrieve candidate applications that should be subjected to further automated and/or manual analysis. DROIDSEARCH is supported by DROIDBASE, a middleware and back-end database which associates apps with metadata and the results of lightweight analyses on bytecode and configuration files that DROIDBASE automatically manages and executes.
Experiments on more than 235,000 applications from six different application stores including Google Play reveal many interesting findings. For instance, DROIDSEARCH identifies 40 known malware applications in Google Play and detects over 35,000 applications that use both http and https connections for accessing the same resources, effectively rendering the https protection ineffective. It also reveals 11,995 applications providing access to potentially sensitive data through unprotected content providers.
Cross-posted from SEEBlog
It’s time to get clean again… This year, Anders Møller and Mayur Naik have taken on the heroic task of organizing the 4th ACM SIGPLAN International Workshop on the
State Of the Art in Program Analysis (SOAP 2015). Thanks to both! We are looking for papers related to program analysis, especially interesting challenges with respect to their design and implementation. We encourage you all to submit!
Cross-posted from SEEBlog
With the help of our new CodeInspect tool, we – together with the McAfee Research Lab – have identified a new threat campaign currently underway in South Korea;
attempting to exploit the huge media frenzy surrounding the release of the movie ‘The Interview’.
Shortly after the news broke that The Interview, originally scheduled to be released on Christmas Day, would appear online from Sony Pictures, numerous sites claimed to offer a pirated copy–fueled by the rumors that the movie might be distributed free online due to the circumstances surrounding the film’s change in distribution. One claim making the rounds in South Korea turned out to be an Android Trojan we have designed Android/BadAccents (named after the main component in the first stage of the Trojan).
Android/BadAccent claims to download a copy of The Interview but instead is the first-stage downloader of a two-stage banking Trojan. The second-stage component, which was distributed using Amazon Web Services, targets account holders of prominent local banks in South Korea as well as one international bank.
One element of the threat’s code caught our attention: the presence of a detection routine that checked the device manufacture before infecting the device. We had at first overlooked this because we had not heard of the manufactures Samjiyon or Arirang; we later found they are not located in South Korea. If the device manufacture was set to either 삼지연 (Samjiyon) or 아리랑 (Arirang ), then the threat would not infect the device and instead prompt the user with a message that an attempt to connect to the server had failed, as we see in the following image.
When installing on any other brand of device, the infection is completed immediately following the download and execution of the second-stage payload.
Currently we don’t believe that this is a politically motivated threat–limiting the infection to devices sold only in South Korea–but purely a business strategy. Because the malicious payload targets account holders in South Korea, why waste bandwidth on an audience outside of the country?
Using the new specialized tool CodeInspect developed by the Secure Software Engineering Group at CASED, the joint IT-security research center between Technische Universität Darmstadt and Fraunhofer SIT, we were able to decrypt the account information that was used by the malware’s authors to relay information to a mail account hosted outside of South Korea.
Despite the fact that this campaign appeared to be relatively new when we discovered it, the number of infected devices that relayed data was about 20,000. Because accounts related to this threat are hosted outside of South Korean, authorities cannot easily dismantle the campaign and prevent further infections. This tactic has become very popular with threats targeting mobile devices in Korea.
Our investigation of the second-stage component indicates that the malware’s components as well the Amazon Web Security services may have been used in previous campaigns targeting banks in South Korea as early as October. McAfee has notified Amazon Web Security and the Korea Internet & Security Agency of our findings. We are working with them to stop the distribution and prevent further infections of this campaign.
The post Fake “The Interview” App Delivers Mobile Malware in South Korea appeared first on McAfee.
Very soon, in a second post on this topic, we will take a deep technical dive into the code and tactics used in this campaign.
Also other media have reported about it:
Cross-posted from SEEBlog
At 31C3 this year, Eric Filiol and Paul Irolla from Laboratoire de Cryptologie et Virologie Opérationnelles presented on (In)security of mobile banking app security. While I appreciate the effort to draw more attention to the insecurity of mobile applications in general, I am afraid that the talk itself was based on quite a few misconceptions, and thus gave a very wrong impression of how app development actually works and about why the code we see is as insecure as it is. Unfortunately, these misconceptions were readily amplified through the mass media (the Zeit, for instance), which is why I think someone with more experience in the field should probably clarify a few things in this respect.
First of all, Filiol and Irolla showed no single banking-related vulnerability. What they showed were a series of potential vulnerabilities, none of which they showed to be exploitable. Both authors also mentioned that it was hard to get access to banking staff that could fix the problems that they found. Well, this is not surprising, and both in combination is dangerous.
First of all, why is it not surprising? Well, guess what, it’s not the banks who actually develop banking apps. Banks are known to be in the business of investing and making money, not in the business of software development. In result, 99% of them will outsource the development of such apps completely. While it makes sense to approach the banks directly if a security flaw is found, it’s not surprising that no one there will be able to solve the problem at hand. This problem then gets amplified if researchers such as Filiol and Irolla go public with alleged (!) insecurities for which they have not really shown that they are exploitable. When talking to banks (or any company for that matter) about the insecurity of their software it really helps to have convincing arguments. And also then, responsible disclosure should be preferable to a rushed talk at 31C3.
The second major problem with the talk was that all the alleged vulnerabilities presented were basically not in the apps’ code itself but was in third-party code, and were not even vulnerabilities. The authors complained about “extra functionality” that was present in the apps and which seemed dangerous and not privacy preserving. They showed instances of the RootTools library being used, and instances of the usage of geo-location services by Yandex (in an app by Sberbank). For using RootTools, however, the authors themselves presented some good reasons, and Sberban is a Russian bank, and Yandex is a russian geo-location service. So there should be little surprise that Yandex code is present in such an app. There is also good reason for most banking apps to use geo location information: many of those apps have a functionality to show you the branch closest to your current location.
So the problem is not really that banks would somehow be evil and include malicious code in their apps, it’s instead simply that the companies who develop apps for banks use somewhat sub-optimal ways of achieving the functionalities of those apps. I agree that this is bad, but nevertheless this paints a picture much different from and much more muted than what was presented in the talk.
To conclude, the primary problem with the apps that Filiol and Irolla actually presented is not that banks are somehow incapable of developing secure apps or even have evil hidden plans. The main problem is one of outsourcing and bad tools for quality control. And this is a problem seen throughout the software development industry. It’s not specific to banking and not specific to mobile apps. To counter this problem, the following is required:
So in result, as much as I myself would like to blame this all on the banks, I don’t think this is a fair assessment. It seems like if anyone is to blame then it is the software development industry (for following bad practices), politics (for not promoting better standards) and researchers, for bragging about alleged vulnerabilities rather than spending their time showing constructive ways to counter them. Plus, there is the press: While writing about vulnerabilities is considered sexy, writing about good security practices seems much less so. So also they are setting the wrong incentives!
Cross-posted from SEEBlog
We are very happy to announce a new tool in our toolchain: CodeInspect – A Jimple-based Reverse-Engineering framework for Android and Java applications.
Developing an Android application in an IDE is very convenient since features like code completion, “Open Declaration“, renaming variables, searching files etc. help the developer a lot. Especially code-debugging is a very important feature in IDEs. Usually, all those features are available for the source code and not for the bytecode, since they support the developer not a reverse-engineer. Well, but all those features would be be also very helpful for reverse-engineering Android or Java applications. This is the reason why we came up with a new reverse-engineering framework that works on the intermediate representation Jimple and supports all the features above and a lot more. In the following we give a detailed description about CodeInspect and its features.
CodeInspect supports as input format a complete Android Application Package (apk), just the Android bytecode (dex-file) or a jar-file. In the following we will describe the different features based on a malicious Android apk.
The figure above is a screenshot of CodeInspect. As one can see, CodeInspect is based on the Eclipse RCP framework and it is based on projects (apks), also known as workspaces. One can add as many projects as she/he wants. Furthermore, CodeInspect contains different perspectives, different views and a new editor for the intermediate representation. The main perspectives are the “CodeInspect” perspective as shown in the screenshot and the “Debug” perspective which is known from the general Eclipse IDE including views for “Expressions”, “Breakpoints” and “Variables”. Other basic views in the CodeInspect perspective are:
What a nice early Christmas gift! Today we were notified that both our submissions to ICSE’15 got accepted. Both papers are based on our Android infrastructure. In the paper IccTA: Detecting Inter-Component Privacy Leaks in Android Apps, which came out of our long-standing collaboration with the University of Luxembourg and Penn State, we present a precise approach for Android inter-component analysis. In the paper Mining Apps for Abnormal Usage of Sensitive Data, in joint work with the group of Andreas Zeller (Saarbrücken), we present the first large scale study of using information-flow analysis to identify Android malware. Thanks a lot to all our collaborators for their hard work! It’s been a pleasure working with all of you!
BTW, in addition I will also be speaking at the New Faculty Symposium at ICSE.
Cross-posted from SEEBlog
We have finally completed the move of Soot’s homepage to Github. Soot’s new home makes it easier than ever for everyone to contribute changes not just to the code base but also the website and documentation. Enjoy!
Cross-posted from SEEBlog
