From b0280c058cb7f4c506f63fbfa7cb4bc3a42adb82 Mon Sep 17 00:00:00 2001 From: Rohan Kumar Date: Sun, 6 Feb 2022 22:23:59 -0800 Subject: [PATCH] Link to SRE frameworks, minor rephrasings --- content/posts/floss-security.gmi | 13 ++++++++++--- content/posts/floss-security.md | 8 +++++--- 2 files changed, 15 insertions(+), 6 deletions(-) diff --git a/content/posts/floss-security.gmi b/content/posts/floss-security.gmi index c246626..2ff3438 100644 --- a/content/posts/floss-security.gmi +++ b/content/posts/floss-security.gmi @@ -71,7 +71,7 @@ strace name-of-program program-args 2>&1 \ | sort | uniq ``` -This also extends to determining how programs utilize the network: packet analyzers like Wireshark can determine when a program connects to the network, and where it connects. +This also extends to determining how programs utilize the network: packet sniffers like Wireshark can determine when a program connects to the network, and where it connects. => https://www.wireshark.org/ Wireshark @@ -99,6 +99,13 @@ Static binary analysis is a powerful way to inspect a program's underlying desig The goal doesn't have to be a complete understanding of a program's design (incredibly difficult without source code); it's typically to answer a specific question, fill in a gap left by tracing/fuzzing, or find a well-known property. When developers publish documentation on the security architecture of their closed-source software, reverse engineering tools like decompilers are exactly what you need to verify their honesty (or lack thereof). +Decompilers are seldom used alone in this context. Instead, they're typically a component of reverse engineering frameworks that also sport memory analysis, debugging tools, scripting, and sometimes even IDEs. Here are two popular frameworks: + +=> https://www.radare.org/n/ The radare project (I use this) +=> https://ghidra-sre.org/ The Ghidra software reverse engineering suite + +Their documentation should help you get started if you're interested. + ### Example: malware analysis These reverse-engineering techniques--a combination of tracing, packet sniffing, binary analysis, and memory dumps--make up the workings of most modern malware analysis. See this example of a fully-automated analysis of the Zoom Windows installer: @@ -158,7 +165,7 @@ Other fuzzing setups can work with just about any binaries. => https://aflplus.plus/docs/binaryonly_fuzzing/ -In fact, some types of fuzz tests (e.g. fuzzing an API for a web service) hardly need to know any implementation details. +In fact, some types of fuzz tests (e.g. fuzzing an API for a web service) hardly need any implementation details. => https://github.com/KissPeter/APIFuzzer/ APIFuzzer @@ -179,7 +186,7 @@ The process was documented on Will's Root: => https://www.willsroot.io/2022/01/cve-2022-0185.html CVE-2022-0185 - Winning a $31337 Bounty after Pwning Ubuntu and Escaping Google's KCTF Containers -I *highly* encourage giving it a read; it's the perfect example of using fuzzing and with an address sanitizer to find a vulnerability, reproducing the vulnerability (by writing a tiny C program), *then* diving into the source code to find and fix the cause, and finally reporting the issue (with a patch!). When source isn't available, the vendor would assume responsibility for the "find and fix" steps. +I *highly* encourage giving it a read; it's the perfect example of fuzzing with sanitizers to find a vulnerability, reproducing the vulnerability (by writing a tiny C program), *then* diving into the source code to find and fix the cause, and finally reporting the issue (with a patch!). When source isn't available, the vendor would assume responsibility for the "find and fix" steps. The fact that some of the most-used pieces of FLOSS in existence have been the biggest beneficiaries of source-agnostic approaches to vulnerability analysis should be quite revealing. The source code to these projects has received attention from millions of eyes, yet they *still* invest in fuzzing infrastructure and vulnerability-hunters prefer analyzing artifacts over inspecting the source. diff --git a/content/posts/floss-security.md b/content/posts/floss-security.md index 7f4d26d..aa03879 100644 --- a/content/posts/floss-security.md +++ b/content/posts/floss-security.md @@ -74,7 +74,7 @@ strace name-of-program program-args 2>&1 \ | sort | uniq ``` -This also extends to determining how programs utilize the network: packet analyzers like [Wireshark](https://www.wireshark.org/) can determine when a program connects to the network, and where it connects. +This also extends to determining how programs utilize the network: packet sniffers like [Wireshark](https://www.wireshark.org/) can determine when a program connects to the network, and where it connects. These methods are not flawless. Syscall tracers are only designed to shed light on how a program interacts with the kernel. Kernel interactions tell us plenty (it's sometimes all we need), but they don't give the whole story. Furthermore, packet inspection can be made a bit painful by transit encryption[^8]; tracing a program's execution alongside packet inspection can offer clarity, but this is not easy. @@ -96,6 +96,8 @@ Static binary analysis is a powerful way to inspect a program's underlying desig The goal doesn't have to be a complete understanding of a program's design (incredibly difficult without source code); it's typically to answer a specific question, fill in a gap left by tracing/fuzzing, or find a well-known property. When developers publish documentation on the security architecture of their closed-source software, reverse engineering tools like decompilers are exactly what you need to verify their honesty (or lack thereof). +Decompilers are seldom used alone in this context. Instead, they're typically a component of reverse engineering frameworks that also sport memory analysis, debugging tools, scripting, and sometimes even IDEs. I use [the radare project](https://www.radare.org/n/), but [Ghidra](https://ghidra-sre.org/) is also popular. Their documentation should help you get started if you're interested. + ### Example: malware analysis These reverse-engineering techniques--a combination of tracing, packet sniffing, binary analysis, and memory dumps--make up the workings of most modern malware analysis. See [this example](https://www.hybrid-analysis.com/sample/1ef3b7e9ba5f486afe53fcbd71f69c3f9a01813f35732222f64c0981a0906429/5e428f69c88e9e64c33afe64) of a fully-automated analysis of the Zoom Windows installer. It enumerates plenty of information about Zoom without access to its source code: reading unique machine information, anti-VM and anti-reverse-engineering tricks, reading config files, various types of network access, reading info on mounted volumes, and more. @@ -131,7 +133,7 @@ Fuzzing Manual invocation of a program paired with a tracer like `strace` won't always exercise all code paths or find edge-cases. [Fuzzing](https://en.wikipedia.org/wiki/Fuzzing) helps to bridge this gap: it automates the process of causing a program to fail by generating random or malformed data to feed it. Researchers then study failures and failure-conditions to isolate a bug. -Fuzzing doesn't necessarily depend on access to source code, as it is a black-box technique. Fuzzers like [American Fuzzy Loop (AFL)](https://lcamtuf.coredump.cx/afl/) normally use [special builds](#special-builds), but [other fuzzing setups](https://aflplus.plus/docs/binaryonly_fuzzing/) can work with just about any binaries. In fact, some types of fuzz tests (e.g. [fuzzing an API](https://github.com/KissPeter/APIFuzzer/) for a web service) hardly need to know any implementation details. +Fuzzing doesn't necessarily depend on access to source code, as it is a black-box technique. Fuzzers like [American Fuzzy Loop (AFL)](https://lcamtuf.coredump.cx/afl/) normally use [special builds](#special-builds), but [other fuzzing setups](https://aflplus.plus/docs/binaryonly_fuzzing/) can work with just about any binaries. In fact, some types of fuzz tests (e.g. [fuzzing an API](https://github.com/KissPeter/APIFuzzer/) for a web service) hardly need any implementation details. Fuzzing frequently catches bugs that are only apparent by running a program, not by reading source code. Even so, the biggest beneficiaries of fuzzing are open source projects. [cURL](https://github.com/curl/curl-fuzzer), [OpenSSL](https://github.com/openssl/openssl/tree/master/fuzz), web browsers, text rendering libraries (HarfBuzz, FreeType) and toolchains (GCC, Clang, the official Go toolchain, etc.) are some notable examples. Daniel Stenberg wrote about fuzzing curl: @@ -149,7 +151,7 @@ A recent example of how fuzzing helps spot a vulnerability in an open-source pro [CVE-2022-0185 - Winning a $31337 Bounty after Pwning Ubuntu and Escaping Google's KCTF Containers](https://www.willsroot.io/2022/01/cve-2022-0185.html) -I _highly_ encourage giving it a read; it's the perfect example of using fuzzing and with an address sanitizer to find a vulnerability, reproducing the vulnerability (by writing a tiny C program), _then_ diving into the source code to find and fix the cause, and finally reporting the issue (with a patch!). When source isn't available, the vendor would assume responsibility for the "find and fix" steps. +I _highly_ encourage giving it a read; it's the perfect example of fuzzing with sanitizers to find a vulnerability, reproducing the vulnerability (by writing a tiny C program), _then_ diving into the source code to find and fix the cause, and finally reporting the issue (with a patch!). When source isn't available, the vendor would assume responsibility for the "find and fix" steps. The fact that some of the most-used pieces of FLOSS in existence have been the biggest beneficiaries of source-agnostic approaches to vulnerability analysis should be quite revealing. The source code to these projects has received attention from millions of eyes, yet they _still_ invest in fuzzing infrastructure and vulnerability-hunters prefer analyzing artifacts over inspecting the source.