My name is Michael, but I also go by f0rki on the internet. I am a security researcher (both in the academic and in the hacker sense).
I am a security engineer and researcher currently wrapping up my PhD under the supervision of Prof. Lucas Davi at the University of Duisburg-Essen (My university site). My primary research interests include:
- Vulnerability Research and Hardening Mechanisms
- Program/Binary Analysis
- Secure Software Development
My research is always centered around applying program analysis techniques to identify security issues or detect attacks. To give a couple of examples, I worked on a project where we used taint tracking inside of the Ethereum Virtual Machine to identify attacks on Ethereum smart contracts. In my master thesis we leveraged a points-to analysis at compile time to introduce runtime security checks that verify that a memory write always targets an object that complies to the points-to analysis. While, a lot of my early research has focused on attack detection (i.e., defense) I am also interested in vulnerability identification and security testing and try to stay up-to-date with the current techniques in this space (i.e., fuzzing, symbolic execution, static analyzers). For example, we identified several bugs in SGX software using symbolic execution. Most recently, I have worked on a high-performance fuzzer for smart contracts that uses ahead-of-time compilation and fast mutations. In general I enjoy diving deep into systems and I have no problem getting my hands dirty. Although I do like to focus on software, so I tend to focus on things above the CPU architecture in terms of computing stack abstractions.
- Practical Mitigation of Smart Contract BugsJens-Rene Giesen, Sebastien Andreina, Michael Rodler, Ghassan O. Karame, Lucas Davi(under submission)
- xTag: Mitigating Use-After-Free Vulnerabilities via Software-Based Pointer Tagging on Intel x86-64Lukas Bernhard, Michael Rodler, Thorsten Holz, Lucas Davi7th IEEE European Symposium on Security and PrivacyDistinguished Paper Award Finalist at IEEE European Symposium on Security and Privacy (Euro S&P) 2022
- TeeRex: Discovery and Exploitation of Memory Corruption Vulnerabilities in SGX EnclavesTobias Cloosters, Michael Rodler, Lucas Davi29th USENIX Security Symposium (USENIX Security '20)- 3. Platz beim 8. Deutschen IT-Sicherheitspreis 2020- Finalist Cyber Security Awareness Week (CSAW) Europe 2020
- Poster: Automated Evaluation of Fuzzers - Distinguished Technical Poster AwardSebastian Surminski, michael Rodler, Lucas DaviProceedings of the Network and Distributed System Security Symposium (NDSS'19)
- Enforcing Pointer Integrity Through Static AnalysisMichael RodlerMaster Thesis at TU Graz
While I try to keep things updated here, you might want to check out my profiles on dblp or scholar:
- "Sereum: Protecting Existing Smart Contracts Against Re-Entrancy Attacks"ACM Advances in Financial Technologies (AFT) 2019 (2019-10-21)
- "ROP CFI RAP XNR CPI WTF? – Navigating the Exploit Mitigation Jungle"at BsidesLjubljana 2017 (2017-03-10)
- "A CTF Hackers Toolbox - Competitive hacking for fun and (non-)profit"with Stefan Moreat Grazer Linuxtage 2016 (2016-04-30)
- "Weird Machines on Little Robots - Intro to binary exploitation on Android smartphones"at Hacking Night SS 2013 (2013-06-06)
- "evil maid on droids"at Hacking Night WS 2012 (2012-12-06)
- "Oh Noes, Another Android Malware Talk"with Thomas Ederat Insights Track at Security Forum 2012 (2012-04-18)
- "Downgrade Attacks by Example"at BSidesVienna 2012 (2012-01-21)
- "Downgrade Attacks: Compatibility Breaks Security"at Hacking Night WS 2011 (2011-12-14)
- "Tatort Internet: Wer geht mit mir phishen?"with Sebastian Neunerat Hacking Night WS 2010 (2010-11-25)
- "git for noobs"at Hackinggroup Workshop (2010-10-27)
Summary of Research Projects
EVMPatch Here we implemented a bytecode rewriter for Ethereum Virtual Machine bytecode. This is quite a low-level bytecode format, which is actually quite simple. However, this simplicity results in various gotchas that make full analysis (correctly identifying pointers into the bytecode) and subsequent rewriting of Ethereum bytecode quite tricky. In this work we utilized a little trick that is well-known from x86 binary rewriting: using trampolines. This allows us to keep all addresses the same in the rewritten contract (except for the code we add). We then integrated this rewriter with some support code: a patch testing component based on differential testing with respect to the original (unpatched) contract, and some patch templates for standard vulnerabilities (such as integer overflows). In the end we had a prototype than can automatically patch and deploy a given smart contract using the delegatecall-proxy pattern to work around the immutability of smart contracts.
TeeRex I supervised a Master thesis on symbolic execution of SGX enclaves. This master thesis turned out to have marvelous results. We identified a couple of vulnerabilities in production SGX enclaves and identified problematic code patterns that typically lead to vulnerabilities. Essentially the SGX privilege boundary has a very similar threat model to the OS kernel, i.e., a shared address space. However, in contrast to the OS kernel the SGX enclave effectively has no control over the address space, and while isolated, is effectively under-privileged. This makes some trivial bugs, like null pointer dereferences, almost trivial to exploit. Turns out, legacy code is full of such bugs and putting them into enclaves makes things not necessarily more secure. Two of the more critical bugs were in Fingerprint drivers that are used by Dell and Lenovo.
Sereum In a collaboration with NEC labs we built a dynamic analysis tool for Ethereum smart contracts. I implemented a taint tracking engine inside of the go-ethereum EVM bytecode interpreter. Based on this taint tracking engine we were able to build a dynamic detector for the infamous reentrancy attacks (this the DAO hack thing). The both fun and unfun part of this project was to evaluate on the vast dataset that is the full Ethereum blockchain. You have all kinds of scalability issues when evaluating by re-executing basically the whole blockchain (the raw data can be found here). Interestingly we were also able to identify potential new attack patterns based on our analysis of the detected potential attacks, for which we introduced example attacks
Scadman was a big collaboration of people around the globe. This was actually my first introduction into the area of cyber-physical systems (CPS) security. You face the issue that due to software or hardware attacks the CPS can behave differently than expected. This could lead to serious safety issues. In this project we created a kind-of intrusion detection system for CPS. The idea was to combine a simulation of the physical processes with an emulation of the cyber processes, i.e., the software running the PLCs and controlling the actuators. We now have a fully simulated copy of the whole CPS and we can now detect deviations between the real and simulated CPS to detect attacks. Now the tricky part is that the simulation of the CPS is not perfect, especially the simulation of the physical processes. We utilize the matiec compiler to convert the IEC code to C code. I set up a compilation pipeline that also allowed us to instrument the code. For example, I introduced a special error-margin multi execution mode using LLVM's analysis and instrumentation infrastructure. This mode is somewhat inspired by symbolic execution and interval-arithmetic, as every physical sensor has an epsilon value attached, i.e., an upper and lower bound. This propagated through the executed code like in interval-arithmetic. However, if the program makes a decision, i.e., a conditional branch, we potentially take both sides (like in symex).
LLWIT I did my master thesis at the IAIK Secure Systems groups, where I built upon the results of the Write Integrity Testing (WIT) paper, which I implemented within LLVM for Linux. This is am exploit mitigation primarily intended to thwart data-oriented attacks, but also covers many control data attacks. I then evaluated WIT on the CGC dataset (only somewhat successfully). However, this evaluation on the CGC dataset showed that there are many issues when implementing a security mitigation like WIT in practice: Arrays are hard, C++ is hard. Contrary to what the COOP paper says, WIT does not necessarily protect against COOP attacks within a class hierarchy.
Compile-Time Instrumentation with LLVM I also started a small project that does compile time function call instrumentation in LLVM (you could call it aspect oriented programming). It's focused on analysis and fault injection though and does come with a significant overhead. The project is now dead/unmaintained. I guess nowadays you would use something more production ready. The project was fun nevertheless and I implemented several examples including letting malloc fail to identify null pointer derefs, injecting faults into RSA computation to test whether the implementation is vulnerable to fault attacks, and I also implemented instrumentation to identify deadlocks using the locktree algorithm.
Taintdroid for KDF detection I patched Taintdroid to contain taint sinks/sources/tags for cryptography APIs, which can result in insights how an android application uses cryptography to protect user data. For example, we used it to analyze apps and how they are using hash functions and other KDFs. For example, it is quite easy to see when the password taint tag ends up in the input of the md5 function for 5000 consecutive times. So you know this app uses a crappy KDF/password-hash. Similarly, you can see that the app passes some user PII (e.g. phone number) to an AES encryption function. So you know that probably the App does the right thing.
ANANAS Previously I worked on dynamic analysis of Android applications. In the malware-lab of the FH Hagenberg Secure Informations Systems we started a project that provides a dynamic analysis platform for Android applications. This resulted in my first publication. Here we built a dynamic analysis platform for analyzing android malware with all the nice features you would expect from a malware sandbox: system call logging, network traffic monitoring, preparing the environment with fake user data, simulating random user interaction and so on. We also attempted to use TaintDroid, but this was too much of a trouble and mostly not worth the effort. Since I left, this project has been extended a lot.