No abstract

Control flow hijacking has been a major challenge in software security. Several means of protections have been developed but insecurities persist. This is because existing protections have sometimes been circumvented while some resilient protections do not cover all applications. Studies have revealed that a holistic way of tackling software insecurity could involve watchdog monitoring and detection via Control Flow Integrity (CFI). The CFI concept has shown a good measure of reliability to mitigate control flow hijacking. However, sophisticated attack techniques in the form of Return Oriented Programming (ROP) have persisted. A flexible protection is desirable, which not only covers as many architecture structures as possible but also mitigates known resilient attacks like ROP. The solution proffered here is a hybrid of CFI and watchdog timing via inter-process signaling (IP-CFI). It is a software-based protection that involves recompilation of the target program. The implementation here is on vulnerable RISC-V-based process but is flexible and could be adapted on other architectures. We present a proof of concept in IP-CFI which when applied to a vulnerable program, ROP is mitigated. The target program incurs a run-time overhead of 1.5%. The code is available.

The presence of instructions within executable programs is what makes the binaries executable.  However, attackers leverage on the same to achieve some form of Control Flow Hijacking (CFH).  Such code re-use attacks have also been found to lead to Denial of Service (DoS).  An example of code re-use attack is Return Oriented Programming (ROP) which is caused by passing input crafted as chained sequences of instructions that are already existing as subroutines in the target program.  The instructions are called gadgets and they would normally end with ret.  The ret instructions enable the flow of hijacked execution from one set of instruction to another within the attacker’s control.  There could however be exceptions depending on the structure of the chained gadgets  where the chained gadget fails to run its course due to inability of specific gadgets to replace the value in the return address (ra) register. The dangers of chained gadgets are not a new idea but the possibility for an attacker’s gadget chain to fall into a trap during a ROP attack is not commonly addressed.  In addition to this, recent studies have revealed that understanding the behaviours of gadgets would be useful for building information base in training machine learning (ML) models to combat ROP.  This study explains the behaviour of certain ROP gadgets showing the possibility of occurrence of a loop in execution during exploitation.  A sample program which accesses gadgets from the GNU C library (glibc) is used to demonstrate the findings.  Gadgets identified with this possibility are poor for chaining as they do not contain instructions to load or move new values to the ra register and would produce unreliable exploits.  This would result in a trap for the chained gadgets instead of arbitrary code execution, and DoS on the path of the user.  This implies that the impact that a ROP chain could have on a targeted process does not only rely on the underlying system architecture but also on relies on the structure of the chained gadget.  In this paper, the RISC-V architecture is the focus, new gadget finders (scripts are available) are presented, and sample of chained gadgets are analysed on a RISC-V -based binary.

No abstract

The hard disk drive stores data the user is creating, modifying, and deleting while a firmware facilitates communication between the drive and the operating system. The firmware tells the device and machine how to communicate with each other and will share useful information such as, disk size and information on any bad sectors. Current research shows that exploits exist that can manipulate these outputs. As an attacker, you can change the size of the disk displayed to the operating system to hide data in, likewise by marking an area of the disk as bad. Users may not be aware of these changes as the operating system will accept the readings from the firmware. However, although the data is not reachable via the operating system this paper looks at the traceability of manipulated data using data recovery software FTK Imager, Recuva, EaseUS and FEX Imager. This report examines the use of malicious techniques to thwart digital forensic procedures by manipulating the firmware. It is shown how this is possible and current forensic techniques or software does not easily detect a change within the firmware. However, with the use of various forensic tools, obfuscated trails are detectable. This report follows a black box testing methodology to show the validation of forensic tools or software against anti-forensic techniques. The analysis of the results showed that most tools can find the firmware changes, however, it requires an analyst to spot the subtle differences between standard and manipulated devices. The use of multiple software tools can help an analyst spot the inconsistencies.