Detection Engine @ Ostorlab

Ostorlab vulnerability detection technology relies on 3 key components, a static analysis engine, a dynamic and behavioral analysis engine and a backend analysis engine.

The static analysis engine performs the following functions:

  • Configuration checks: for instance checking that the application disables debug mode, has proper production framework settings, like secure Apache Cordova whitelist or has secure network security policy.

  • Dependency checks: focuses on identifying dependencies and their versions, either through version files that some framework will kindly provide, or by introspecting the binary for specific identifiers handcrafted by the Ostorlab team. These dependencies are scanned for known vulnerabilities.

  • Taint Analysis: one of the advanced and unique features that Ostorlab provides is a highly performant and production grade taint analysis engine. The engine covers a set of technologies, like Android bytecode and is able to compute analysis across the whole application scouring for vulnerabilities that are hidden through dozens of method calls. These vulnerabilities include the use of insecure cryptography, like using ECB Block mode or DES algorithm, SQL injection exposed through URL scheme or a content provider, command execution exposed through a service or a content provider.

The dynamic analysis engine performs several actions:

  • Application Preparation: repackages the application for analysis, this includes enabling debug mode, resign the application and disable problematic checks that can hinder the analysis.

  • Device Preparation: Installs the application on a real device and sets the application to wait for a debugger, this applies to both Android and iOS. Ostorlab relies on real devices for performance and reproducibility.

  • Debug-Protocol Analysis: instruments the application using debug protocols like JDWP or LLDB. Ostorlab maintains its own stack to be able to interact at a low level with the application. Instrumentation consists of placing traces on strategic API, known as sources (of untrusted input) and sinks (may lead to vulnerabilities). Ostorlab relies on debug protocols for analysis compared to in-memory analysis for both stability and extensibility. Debug protocols are less risky compared to manipulating memory to hook APIs, it is also stable across new OS versions. Debug protocols have a performance penalty as they slow the application, a penalty that remains acceptable in the context of vulnerability detection. Extensibility comes from the features that debuggers provide, like understanding memory layout of swift or objective C, which allows for writing clear and concise instrumentation code.

  • Tracing and Analysis: traces are collected and analyzed on the fly for known vulnerable patterns, for instance call a cryptographic API with an insecure method, or a hard coded key. This step also collects traffic by hooking directly into the TLS/SSL API and Socket API. This approach bypasses SSL Pinning. The collected traffic is then sent to the backend analysis engine, see report example here.

  • Monkey Testing: A test monkey starts interacting with the application, either using a set of heuristics to detect authentication pages or by randomly clicking around the application. In the case of complex UI interaction, UI automation rules are written using BDD to script the interaction.

The backend analysis engine relies on the dynamic analysis to collect traffic, the engine then performs the following actions:

  • Passive detection: this relies on analyzing the requests and responses attributes, like body and headers for vulnerabilities, like missing cookie attributes, insecure CORS, vulnerable components from inferred versions, etc.

  • Active detection: Ostorlab as a mobile-first security scanner, focuses on understanding several serialization protocols commonly used in Mobile applications, like GraphQL or Protobuf. These serialization protocols are fuzzed for vulnerabilities like SQL injection, XXE, template injection, etc.

These stages are not executed sequentially as behind each are multiple micro-agents specialised in a specific task. These agents communicate using a shared bus and rely on an event based architecture.

During each of these analyses, artifacts are collected, like application screenshots, device logs and decompiled source code.

The three analysis engines provide comprehensive coverage of the application attack surface and complements the inherent shortcomings of each analysis separately. For instance static analysis provides excellent coverage of the application attack surface, but at the same may result in false positives due to complex execution paths or dead code. Dynamic analysis provides false positive free results but can’t guarantee full coverage of the application surface and the backend analysis detects vulnerabilities inherent to the backend, which in most cases is dedicated to the mobile application.