Software supply chain monitoring in containerised open-source digital forensics and incident response tools

Abstract. Legal context makes software development challenging for the tool-oriented Digital Forensics and Incident Response (DFIR) field. Digital evidence must be complete, accurate, reliable, and acquirable in reproducible methods in order to be used in court. However, the lack of sufficient software quality is a well-known problem in this context. The popularity of Open-source Software (OSS) based development has increased the tool availability on different channels, highlighting their varying quality. The lengthened software supply chain has introduced additional factors affecting the tool quality and control over the use of the exact software version. Prior research on the quality level has primarily targeted the fundamental codebase of the tool, not the underlying dependencies. There is no research about the role of the software supply chain for quality factors in the DFIR context. The research in this work focuses on the container-based package ecosystem, where the case study includes 51 maintained open-source DFIR tools published as Open Container Initiative (OCI) containers. The package ecosystem was improved, and an experimental system was implemented to monitor upstream release version information and provide it for both package maintainers and end-users. The system guarantees that the described tool version matches the actual version of the tool package, and all information about tool versions is available. The primary purpose is to bring more control over the packages and support the reproducibility and documentation requirement of the investigations while also helping with the maintenance work. The tools were also monitored and maintained for six months to observe software dependency-related factors affecting the tool functionality between different versions. After that period, the maintenance was halted for additional six months, and the tool’s current package version was rebuilt to limit gathered information for the changed dependencies. A significant amount of different built time and runtime failures were discovered, which have either prevented or hindered the tool installation or significantly affected the tool used in the investigation process. Undocumented, changed or too new environment-related dependencies were the significant factors leading to tool failures. These findings support known software dependency-related problems. The nature of the failures suggests that tool package maintainers are required to possess a prominent level of various kinds of skills for making operational tool packages, and maintenance is an effort-intensive job. If the investigator does not have similar skills and there is a dependency-related failure present in the software, the software may not be usable.Ohjelmistotoimitusketjun seuranta kontitetuissa avoimen lähdekoodin digitaaliforensiikan ja tietoturvapoikkeamien reagoinnin työkaluissa. Tiivistelmä. Oikeudellinen asiayhteys tekee ohjelmistokehityksestä haasteellista työkalupainotteiselle digitaaliforensiikalle ja tietoturvapoikkeamiin reagoinnille (DFIR). Digitaalisen todistusaineiston on oltava kokonaista, täsmällistä, luotettavaa ja hankittavissa toistettavilla menetelmillä, jotta sitä voidaan käyttää tuomioistuimessa. Laadun puute on kuitenkin tässä yhteydessä tunnettu ongelma. Avoimeen lähdekoodin perustuva ohjelmistokehitys on kasvattanut suosiotaan, mikä on luonnollisesti lisännyt työkalujen saatavuutta eri kanavilla, korostaen niiden vaihtelevaa laatua. Ohjelmistotoimitusketjun pidentyminen on tuonut mukanaan työkalujen laatuun ja täsmällisen ohjelmistoversion hallintaan vaikuttavia lisätekijöitä. Laatutasoa koskevassa aikaisemmassa tutkimuksessa on keskitytty pääasiassa työkalun olennaiseen koodipohjaan; ei sen taustalla oleviin riippuvuuksiin. Ohjelmistotoimitusketjun merkityksestä laadullisiin tekijöihin ei ole olemassa tutkimusta DFIR-asiayhteydessä. Tämän työn tutkimuksessa keskitytään konttipohjaiseen pakettiekosysteemiin, missä tapaustutkimuksen kohteena on 51 ylläpidettyä avoimen lähdekoodin DFIR-työkalua, jotka julkaistaan ns. OCI-kontteina. Työssä parannettiin pakettiekosysteemiä ja toteutettiin kokeellinen järjestelmä, jolla seurattiin julkaisuversiotietoja ja tarjottiin niitä sekä pakettien ylläpitäjille että loppukäyttäjille. Järjestelmä takaa, että kuvattu työkaluversio vastaa työkalupaketin todellista versiota, ja kaikki tieto työkaluversioista on saatavilla. Ensisijaisena tarkoituksena oli lisätä ohjelmistopakettien hallintaa ja tukea tutkintojen toistettavuus- ja dokumentointivaatimusta, kuten myös auttaa pakettien ylläpitotyössä. Työssä myös seurattiin ja ylläpidettiin työkaluja kuuden kuukauden ajan sellaisten ohjelmistoriippuvuuksien aiheuttamien tekijöiden tunnistamiseksi, jotka vaikuttavat työkalun toimivuuteen eri versioiden välillä. Lisäksi odotettiin vielä kuusi kuukautta ilman ylläpitoa, ja työkalun nykyinen pakettiversio rakennettiin uudelleen, jotta kerätty tieto voitiin rajoittaa vain muuttuneisiin riippuvuuksiin. Työn aikana löydettiin huomattava määrä erilaisia rakennusaika- ja suoritusaikavirheitä, mitkä ovat joko estäneet tai haitanneet työkalun asennusta, tai muuten vaikuttaneet merkittävästi tutkinnassa käytettyyn työkaluun. Dokumentoimattomat, muuttuneet tai liian uudet ympäristöriippuvuudet olivat merkittäviä työkaluvirheisiin johtaneita tekijöitä. Nämä löydökset tukevat ennestään tunnettuja ohjelmistoriippuvuusongelmia. Virheiden luonteesta voidaan päätellä, että työkalujen ylläpitäjiltä vaaditaan paljon erilaista osaamista toiminnallisten työkalupakettien ylläpitämisessä, ja ylläpitäminen vaatii paljon vaivaa. Jos tutkijalla ei ole vastaavia taitoja ja ohjelmistossa on riippuvuuksiin liittyvä virhe, ohjelmisto saattaa olla käyttökelvoton

Fuzz testing containerized digital forensics and incident response tools

Abstract. Open source digital forensics and incident response tools are increasingly important in detecting, responding to, and documenting hostile actions against organisations and systems. Programming errors in these tools can at minimum slow down incident response and at maximum be a major security issue potentially leading to arbitrary code execution. Many of these tools are developed by a single individual or a small team of developers and have not been comprehensively tested. The goal of this thesis was to find a way to fuzz test a large amount of containerized open source digital forensics and incident response tools. A framework was designed and implemented that allows fuzz testing any containerized command line based application. The framework was tested against 43 popular containerized open source digital forensics and incident response tools. As a result, out of 43 of the tested tools 24 had potential issues. Most critical issues were disclosed to the respective tools authors via their preferred communication method. The results show that currently many open source digital forensics and incident response tools have robustness issues and reaffirm that fuzzing is an efficient software testing method.Kontitettujen digitaaliforensiikka ja tietoturvahäiriön hallintatyökalujen fuzz-testaus. Tiivistelmä. Avoimen lähdekoodin digitaaliforensiikka ja tietoturvahäiriön hallintaan käytetyt työkalut ovat entistä tärkeämpiä tunnistamiseen, hallintaan ja dokumentoimiseen haitallisia toimintoja vastaan organisaatioissa ja järjestelmissä. Ohjelmointivirheet näissä työkaluissa voivat pienimmillään hidastaa tieturvahäiriön hallintaa ja enimmillään olla suuri tietoturvauhka, joka potentiaalisesti voi johtaa mielivaltaisen koodin suoritukseen. Monet näistä työkaluista ovat kehittäneet joko yksittäiset henkilöt tai pienet ohjelmistokehittäjätiimit eikä niitä välttämättä ole kattavasti testattu. Tämän diplomi-insinöörityön tavoitteena oli löytää tapa fuzz-testata suuri määrä kontitettuja avoimen lähdekoodin digitaaliforensiikka ja tietoturvahäiriön hallintaan käytettyjä työkaluja. Tähän tarkoitettu ohjelmisto suunniteltiin ja toteutettiin, joka mahdollistaa minkä tahansa kontitetun komentolinjaan perustuvan ohjelmiston fuzz-testaamisen. Ohjelmistoa testattiin 43 suosittua kontitettua avoimen lähdekoodin digitaaliforensiikka ja tietoturvahäiriön hallintaan käytettävää työkalua vastaan. Lopputuloksena testatuista työkalusta 24 löytyi ongelmia. Kriittisimmät löydetyistä ongelmista ilmoitettiin työkalujen vastaaville kehittäjille heidän suosimallaan kommunikaatiometodilla. Lopputulokset osoittavat, että tällä hetkellä monet avoimen lähdekoodin digitaaliforensiikka ja tietoturvahäiriöiden hallintaan käytettävät työkalut kärsivät ohjelmointivirheistä ja vahvistaa fuzz-testauksen olevan edelleen tehokas ohjelmistotestaus metodi

A Domain Specific Language for Digital Forensics and Incident Response Analysis

One of the longstanding conceptual problems in digital forensics is the dichotomy between the need for verifiable and reproducible forensic investigations, and the lack of practical mechanisms to accomplish them. With nearly four decades of professional digital forensic practice, investigator notes are still the primary source of reproducibility information, and much of it is tied to the functions of specific, often proprietary, tools. The lack of a formal means of specification for digital forensic operations results in three major problems. Specifically, there is a critical lack of: a) standardized and automated means to scientifically verify accuracy of digital forensic tools; b) methods to reliably reproduce forensic computations (their results); and c) framework for inter-operability among forensic tools. Additionally, there is no standardized means for communicating software requirements between users, researchers and developers, resulting in a mismatch in expectations. Combined with the exponential growth in data volume and complexity of applications and systems to be investigated, all of these concerns result in major case backlogs and inherently reduce the reliability of the digital forensic analyses. This work proposes a new approach to the specification of forensic computations, such that the above concerns can be addressed on a scientific basis with a new domain specific language (DSL) called nugget. DSLs are specialized languages that aim to address the concerns of particular domains by providing practical abstractions. Successful DSLs, such as SQL, can transform an application domain by providing a standardized way for users to communicate what they need without specifying how the computation should be performed. This is the first effort to build a DSL for (digital) forensic computations with the following research goals: 1) provide an intuitive formal specification language that covers core types of forensic computations and common data types; 2) provide a mechanism to extend the language that can incorporate arbitrary computations; 3) provide a prototype execution environment that allows the fully automatic execution of the computation; 4) provide a complete, formal, and auditable log of computations that can be used to reproduce an investigation; 5) demonstrate cloud-ready processing that can match the growth in data volumes and complexity

Insight from a Docker Container Introspection

Large-scale adoption of virtual containers has stimulated concerns by practitioners and academics about the viability of data acquisition and reliability due to the decreasing window to gather relevant data points. These concerns prompted the idea that introspection tools, which are able to acquire data from a system as it is running, can be utilized as both an early warning system to protect that system and as a data capture system that collects data that would be valuable from a digital forensic perspective. An exploratory case study was conducted utilizing a Docker engine and Prometheus as the introspection tool. The research contribution of this research is two-fold. First, it provides empirical support for the idea that introspection tools can be utilized to ascertain differences between pristine and infected containers. Second, it provides the ground work for future research conducting an analysis of large-scale containerized applications in a virtual cloud

Container and VM Visualization for Rapid Forensic Analysis

Cloud-hosted software such as virtual machines and containers are notoriously difficult to access, observe, and inspect during ongoing security events. This research describes a new, out-of-band forensic tool for rapidly analyzing cloud based software. The proposed tool renders two-dimensional visualizations of container contents and virtual machine disk images. The visualizations can be used to identify container / VM contents, pinpoint instances of embedded malware, and find modified code. The proposed new forensic tool is compared against other forensic tools in a double-blind experiment. The results confirm the utility of the proposed tool. Implications and future research directions are also described

A GIPSY Runtime System with a Kubernetes Underlay for the OpenTDIP Forensic Computing Backend

In this research work, we propose an underlay based on Kubernetes to enhance the scalable fault tolerance of the General Intensional Programming System's distributed run-time demand-driven backend to gather digital evidence from GitHub repositories and encode them in Forensic Lucid for further analysis in the integrated OpenTDIP environment. We developed a solution so that forensic investigators could use GitHub to gather a dataset to investigate program flaws and vulnerabilities related to security from GitHub projects written in different programming languages. For this purpose, we design and implement a JSON demand-driven encoder to perform a Forensic Lucid conversion pipeline (data extraction, format conversion, and file compilation). In order to distribute the execution, we utilized the GIPSY distributed computing system. We also integrated Kubernetes with GIPSY distributed computing system in order to improve the configuring, starting up and registering GIPSY nodes, so that GIPSY nodes could get registered automatically without any manual configuration. In addition, provide a mechanism to have a scalable fault-tolerant system so that when a GIPSY node dies, it will handle reallocation, configuration and registration of the GIPSY nodes automatically