Daehee Jang

SQL Injection is a well-known vulnerability that has persisted in web applications for decades. A widely held assumption among developers is that even when SQL Injection is present, hashing or encrypting sensitive data using SQL-provided cryptographic functions, such as sha256() or md5(), renders stolen data unrecoverable. This paper challenges that assumption directly. We demonstrate that invoking cryptographic functions within SQL statements does not protect plaintext credentials against an attacker who already has SQL Injection access, not because the hash functions are weak but because their plaintext arguments are transiently exposed in DBMS in-memory monitoring views before the hash function executes. We exploit this window using a technique that we call SQLSnoop, which repurposes built-in SQL looping constructs to poll the monitoring view at high frequency within a single injected statement. We demonstrate SQLSnoop against four major RDBMS platforms: MySQL, MSSQL, Oracle, and PostgreSQL. Systematic quantitative evaluation is conducted on MySQL, while feasibility on MSSQL, Oracle, and PostgreSQL is confirmed through working Proof-of-Concept implementations against each platform’s respective in-memory monitoring view. Our evaluation on MySQL shows attack success rates consistently above 90%, reaching 100% at 1.2 or more virtual CPU cores, and holding across all four Data Manipulation Language operations. The key practical implication is that SQL-layer hashing is fundamentally insufficient as a defense against SQL Injection, and sensitive data must be hashed at the application layer before the SQL statement is constructed.

Coverage feedback is one of the key mechanisms for improving the effectiveness of fuzzers by measuring and comparing the executed code regions while processing input data. In general, such guidance should always improve the performance of fuzzers to better find unexplored code regions. However, proprietary systems with uncommon I/O interfaces (e.g., UAV system, IoT devices, satellite firmware) require extensive engineering/porting efforts to apply coverage feedback support in developing their fuzzing platform. In this paper, we evaluate the detailed efficacy of coverage feedback in fuzzing based on 44 real-world bugs we found using OSS-Fuzz. Our analysis uncovered when and how code coverage information can be helpful, and our experiment demonstrates that although coverage guidance is always helpful to some extent, its effectiveness depends on various external factors. Therefore, such factors should be carefully considered for optimizing the cost and efficiency in designing the fuzzing architecture of proprietary systems.

Fuzzing is a practical approach for finding bugs in various software. So far, a number of fuzzers have been introduced based on new ideas towards enhancing the efficiency in terms of increasing code coverage or execution speed. The majority of such work predicates under the assumption that they have sound executable binary or source code to transform the target program as a whole. However, in legacy systems, source codes are often unavailable and even worse, some binaries do not provide a sound executable environment (e.g., partially recovered firmware). In this paper, we provide FT-Framework: fuzzability testing framework based on forced execution for binaries such as firmware chunks recovered in abnormal way so that they are hard to execute/analyze from intended booting phase. The essence of our work is to automatically classify functions inside a binary which we can apply coverage-guided fuzzing via forced execution. We evaluate FT-Framework using PX4 and ArduPilot firmwares which is based on 32-bit ARM architecture and demonstrate the efficacy of this approach and limitations.