Recent research conducted on Android security apps by Stephan Huber and Siegfried Rasthofer found that, rather than improving mobile security, mobile antivirus products from leading vendors contain major security vulnerabilities.
The introduced vulnerabilities, carried in mobile antivirus products from Kaspersky Lab, McAfee, Androhelm, ESET, Malwarebytes, and Avira, do not fall into the category of zero-day exploits or complex attacks. In fact, most of them are very well-known security issues that appear on the OWASP Top Ten for Mobile Applications, including communication (M3: Insufficient Transport Layer), SQL injections (M7 Client Side Injections) and "self-developed" crypto implementations (M6: Broken Cryptography).
”The most alarming findings, were security applications that we were able to actually turn into remote access trojans (RATs) or into ransomware,” Huber wrote on his website, TeamSIK. During the presentation of their findings at DEF CON 24, Huber was able to show a Java method from one of the antivirus products that contained a major vulnerability and total lack of validation controls.
A closer look at the mobile antivirus gaffe
After the talk, I had the opportunity to ask Huber how he was able to obtain some of the source code of the application, and he answered that the binaries were "not secured by any form of obfuscation. Reverse engineering was simple."
Reverse engineering is one the Top Ten Mobile vulnerabilities.
"This category includes analysis of the final core binary to determine its source code, libraries, algorithms, and other assets. Software such as IDA Pro, Hopper, otool, and other binary inspection tools give the attacker insight into the inner workings of the application," Huber said. "This may be used to exploit other nascent vulnerabilities in the application, as well as revealing information about back-end servers, cryptographic constants and ciphers, and intellectual property."
That's exactly what Huber and his team did.
New approach needed: DevOps and the development lifecycle
How could it be that the applications that are supposed to make our devices secure and protect us from ransomware and all kinds of attacks contain vulnerabilities of this kind? What can we learn from this mess, and how can we apply secure DevOps practices to software development? The answer lies in the design and development lifecycle.
Whatever type of app we are building, mobile or otherwise, the best practice is to implement security measures during the development phase. A classic mistake is to wait until the application is ready to start assessing its security, such as when the application is in production or at its final release. It is clear that the development of these applications lacked a proper secure software lifecycle.
AppSec Pipelines, for example, takes the principles of DevOps and applies that to an application security program. To know more about this principle, check the OWASP AppSec Pipeline Project. The following are some of the major phases involved in creating secure DevOps, according to the Appsec Pipeline guidelines.
Code phase pipeline
Why wait until the coding phase is done in order to verify that developers are including insecure code lacking controls? Instead, implement secure coding principles from day one. Developers should be aware of bad coding practices that lead to insecure applications. The OWASP proactive controls is an excellent document that can help developers understand what kind of controls must be implemented within the code. Documentation such as Android Testing Cheat Sheet and IOS Developer Cheat Sheet can help to create a checklist of insecurities.
One way to support developers is to implement the use of static analysis tools. They are very important in the arsenal of a developer. He or she might not understand immediately the vulnerabilities, but the tool will be able to highlight any major issues found during this phase. Accuracy and price of these tools vary enormously, so it’s very important not to blindly rely on them, but instead have a developer with experience in secure development verify the false positives.
While static analysis tools can help us catch some low-hanging fruit quite fast, code review should also be part of the strategy. By identifying insecure code practices, such as lack of obfuscation or insecure methods without proper verification controls, we will be able to fix them early on, as we code.
Store, manage, build pipelines
During these phases, the use of proper management tools that help us keep track of the security issues found during the code phase will provide us a major support to confirm the bugs and do the proper follow-up. This cycle will normally repeat itself continuously, and it should be repeated every time a build is ready to be deployed for testing.
Management tools such as JIRA or any person who can log the issues will help establish an overview of the situation and keep track of security bugs found in the code. Many management tools contain integration with DevOps practices and agile development. Also, static analysis tools contain plugins able to log issues automatically. This is very practical for making sure that no issues are left behind without being properly logged and documented.
Deploy, test, and automate—repeat pipeline
This is the phase that can help catch the low-hanging fruit of any major issues. Testing applications is an intensive task, and automating cases that have been found out during previous cycles will help us be more efficient. After deploying the application and establishing a series of security test cases, a pen tester can automate some of these and allow them to run while including some new ones.
As the pen tester goes over the deployment of each build, tests can be continuously created and adapted until there is a robust set of automated tests able to verify the application once it is mature and stable enough. This is what really helps create an effective lifecycle and minimize the testing efforts, focusing on new issues. The good news is that many tools such as attack proxies such as OWASP ZAP support integration with management tools and the ability to automatically log issues into them.
Are we there yet?
In security applications, we are never done. By following secure DevOps, for every build there will always be a continuous pipeline, and for every final release, the same process will repeast as described before. In fact, you might consider a very different approach at this level, such as running a bug bounty program for your application.
Hacking is a creative task, and bugs that are not found during the AppSec Pipeline process can actually be catched during this one. Running a bounty program can allow us to strengthen the security of an application by exposing it to real attack scenarios. Secure DevOps is a great way to dramatically improve the security of applications. Let's hope that this process is being considered in future releases of the antivirus apps that didn't stand up to security tests.
Image source: Flickr
Keep learning
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed fast on the state of app sec testing with TechBeacon's Guide. Plus: Get Gartner's 2021 Magic Quadrant for AST.
Get a handle on the app sec tools landscape with TechBeacon's Guide to Application Security Tools 2021.
Download the free The Forrester Wave for Static Application Security Testing. Plus: Learn how a SAST-DAST combo can boost your security in this Webinar.
Understand the five reasons why API security needs access management.
Learn how to build an app sec strategy for the next decade, and spend a day in the life of an application security developer.
Build a modern app sec foundation with TechBeacon's Guide.
