{"id":6363,"date":"2024-04-02T14:46:35","date_gmt":"2024-04-02T21:46:35","guid":{"rendered":"https:\/\/objectsecurity.com\/?p=6363"},"modified":"2024-11-15T15:08:05","modified_gmt":"2024-11-15T23:08:05","slug":"automating-binary-exploit-detection","status":"publish","type":"post","link":"https:\/\/objectsecurity.com\/automating-binary-exploit-detection\/","title":{"rendered":"Automating Binary Exploit Detection using BinLens"},"content":{"rendered":"

Binary analysis is essential for protecting software, running on various devices, when you do not have access to resources such as source code, open communications with the manufacturer, and otherwise private information that has not been made public. In each of these cases, traditional cybersecurity measures such as static source code analysis and applying the latest patch are not an option.<\/strong><\/span><\/p>\n

Most firmware analysis and SBOM generation vendors only report known and\/or publicly published vulnerabilities (i.e., CVEs). These vendors do not deeply inspect the ground truth of a program\u2019s behavior; they do not analyze the machine code being executed as defined at the binary level. This leaves much to be desired, as novel exploits that are not yet published in the National Vulnerability Database still pose a daily threat to the client organizations.<\/p>\n

This poses the following question: to what extent can novel binary exploit detection be automated? In this blog post, we will explore this problem through the lens of a user of ObjectSecurity’s BinLens\u2122<\/a> (formerly ObjectSecurity OT.AI Platform)\u00a0and walk through the steps they would take to detect a novel exploit in a binary executable program.<\/p>\n<\/div><\/div><\/div><\/div><\/div>

Creating a Target Binary Executable<\/strong><\/h2><\/div><\/div><\/div>

Imagine you have a program that reads some form of user input. Although the source of this user input may vary (e.g., from the terminal, over the network, from a UI form, etc.), in most cases the program will define an internal function to parse the input and perform some operation. The previous statement is quite general, so let\u2019s provide a concrete example.<\/p>\n<\/div>

When compiled, the source code produces a binary that takes as input a single command line argument, and then performs one of two operations depending upon it.<\/p>\n

    \n
  1. If the argument is not equal to the value 123<\/em>, the program performs a safe operation that causes no issues (heap_safe())<\/em>.<\/li>\n
  2. If the argument is equal to the value 123<\/em>, the program performs an unsafe operation that causes a heap overflow, segmentation fault, and program crash (heap_overflow()<\/em>).<\/li>\n<\/ol>\n<\/div>

    This behavior is demonstrated in the screenshot below:<\/p>\n<\/div>

    <\/span><\/div><\/div><\/div>
    <\/span><\/div><\/div><\/div>

    Although this example is contrived, it does mimic a simplified version of how vulnerable programs typically behave. Vulnerable programs read input data from an external source (in our case, a command line argument), and perform different operations depending on this input. These operations may contain certain weaknesses, some of which can be exploited if the program\u2019s developer wasn\u2019t careful enough.<\/p>\n

    In a real-world example, these unsafe operations are hidden deep within a binary file, only occurring in certain obtuse cases. Many times, developers might lack the knowledge, time, or resources to account for every possible edge case. This makes automating the detection of unsafe operations critical.<\/p>\n

    Let\u2019s assume that we don\u2019t have the source code for this binary (called sample_1<\/em>), and that we don\u2019t know what inputs cause it to crash. How then could we determine if the binary is exploitable? More specifically, how can we reliably determine that input 123<\/em> causes the program to crash, if we were never told this information?<\/p>\n<\/div><\/div><\/div><\/div><\/div>

    A Primer on Fuzzing<\/strong><\/h2><\/div><\/div><\/div>

    Fuzzing is an automated testing method that feeds pseudo-random input into a target program to generate exploits. This input is typically malformed, invalid, and\/or unexpected. Fuzzing a vulnerable program sometimes results in the exploitation of one or more weaknesses, causing the program to crash or perform some other kind of unintended behavior. Some weaknesses include:<\/p>\n