Understand and test for mobile vulnerabilities - iOS Tutorial

- [Instructor] The rapid growth and variety of applications of mobile technology has brought with it many new threats. The functionality of the platforms and the new technologies being introduced all offer a broader attack surface while security is struggling to keep up with the demands not only of the technology, but of usability. The infrastructure supporting mobile technology is now quite complex. The challenge of achieving non-intrusive security is most pronounced on mobile platforms, and the many flaws found over the last few years have squashed any idea that the mobile operating systems are somehow less vulnerable than their IT counterparts, all of which goes to make the job of the security tester critical to the continuing growth and success of mobile device use. The Open Web Application Security Project, OWASP, started life by providing a framework and tools for testing web applications. However, its tremendous success spurred the creation of additional security testing projects in mobile, and more recently, Internet of Things. The OWASP Mobile Security Project, whose web page is shown here, is a good place to start in looking at the threats to mobile applications and the best practices in mobile device and application security. OWASP maintains a list of mobile threats that should be checked, and a key deliverable from the OWASP project is the top 10 threats list. This provides a useful start point for testing and is a baseline hygiene check for any mobile application. While the project is now closed, these are still relevant. Let's take a quick look at each of them. Improper platform usage. This category covers the misuse of a platform feature or failure to use platform security controls, including Android intents, platform permissions, misuse of touch ID, the Keychain and other security controls in the mobile operating system. Insecure data storage combines two of the threats from the 2014 top 10 insecure data storage and unintended data leakage. Unfortunately, there are far too many ways in which these issues can occur. In a recent study of mobile apps, it was found 5% transfer personal information to a third-party server, and about half transmitted device and location information. Insecure communications covers poor handshaking, incorrect SSL versions, weak negotiation, clear text communication of sensitive assets and other similar issues. Even supposedly secure communications can prove to have weaknesses through issues such as poor random number generators. Insecure authentication, when authenticating the end user, or through bad session management is the next big threat. This can include failing to identify the user and to correctly maintain the user's identity throughout the session. Insufficient cryptography. This issue is highlighted with a weakness found in MD4 and MD5 some years ago. But in general, cryptography is an area of significant concern because it's extremely difficult to design and code good cryptographic systems. Then the proprietary algorithms should be approached with suspicion. Insecure authorization includes all threats related to failures in authorization, specifically to user-restricted function or access-controlled data. Client code quality is a catch all for code-level implementation problems in the mobile client, such as buffer overflows, format string vulnerabilities, and various other coding mistakes. Code tampering covers binary patching, local resource modification, method hooking, method swizzling, and dynamic memory modifications subsequent to the application being loaded. This can be done through changing the contents of memory, changing the system APIs that the application uses, or modifying the application's data and resources. Reverse engineering. This is an interesting category of threats, as it's the means by which testers validate security and provide recommendations for improvement to the developer. However, if an adversary gets ahold of the application and reverse engineers it, they're much more likely to exploit vulnerabilities in the application rather than reporting them. Extraneous functionality. Often developers include hidden back door functionality or other internal development security controls. They're not intended to be released into production. Or maybe some form of amusement, such as what are known as Easter eggs. These are hidden functions which appear when special combinations of key strokes or mouse clicks are used. There are many more threats. The 2016 list of significant threats has 91 entries, so while the form factor may be small, the testing activity isn't. One of the key goals of the OWASP Mobile Security Project is to provide standardization of mobile application testing methodologies. to ensure users can have confidence in their testing programs. While specific techniques exist for individual platforms, OWASP provides a general mobile threat model, which applies to any platform and can be customized to meet the needs of both the owner and the tester. The guidance is not only intended for testers, but also for developers. Providing guidance in the development of applications which are built from the ground up with security in mind. There are different ways of testing. The ideal mobile assessment combines static analysis, dynamic analysis, and forensic analysis to ensure that the majority of the mobile application attack surface is covered. The underworld platform is able to be virtualized and so applications can be tested within a virtualized environment. When testing Apple applications, however, there is no virtualized environment and so the tester needs to jailbreak a device to use as the testing platform. A final note. This testing is designed to identify weaknesses in mobile applications. And in the case of the iPhone, it's involved running applications on a device. The techniques we use may not be suitable for forensics use, especially if evidential integrity is required.