Thoughts on Offensive and Defensive Cybersecurity

Investigating Linux Systems

Compared to Windows, Linux operating systems conform to a different structure, creating different implications for investigators who wish to examine systems like RedHat, Ubuntu, Android, or Kali. Most Linux systems abide by a file system hierarchy (or FSH), which denotes how files are classified and how objects are stored. For example, according to FSH, “/” describes the root of the file directory, which contains all files and objects. Other examples include /bin, which refers to command binaries, /dev, which refers to device files, and an array of others. Each directory plays a role in the utility of the operating system by harboring useful objects. Linux systems also create organization and access control through ownership and permissions. For instance, files are associated with their respective owners through User IDs and Group IDs. Furthermore, Linux gives permissions to objects, such as read, write, and execute. In aggregate, the operating system creates a kind of access control matrix that manages the user’s ability to interact with objects. Linux inodes also cite file attributes that act like permissions in that they signify what an object can be used for. For example, the “I” attribute makes an object immutable, negating attempts to change it. Additionally, the “A” attribute stymies the altime record from changing when the object is accessed.

Linux’s FSH and overall composition must be observed to effectively investigate its contents. Classifications allow an FE to extract evidence and other clues by navigating the system’s hierarchy. Furthermore, ownership labels and permissions often have evidentiary value by allowing an FE to infer information about suspect processes and malicious activity. Even file attributes reveal what objects could be used for in a crime.

To dig deeper: ownership and permissions yield evidentiary value by clarifying the nature of a crime and the likely causes. Ownership denotes who has privileges over their respective data. So, for example, if the FE is working a case in which the access control scheme gives access to certain data only to specific User IDs or Group IDs, the FE can draw conclusions about which user account most likely accessed the data. Conversely, if ownership designations are trusted and restrictive, unauthorized access may indicate that a breach occurred outside local processes. Perhaps a man-in-the-middle attack occurred or an application vulnerability allowed an outside attacker to exfiltrate data without owning the system. Additionally, ownership principles may tell if a user has transgressed the law or company policy when a user has gained access to data not assigned to them. For instance, if permissions on an object were changed without oversight from the owner or administrator, the changes would indicate that a user gained unauthorized privileges within the system. An alternative scenario: permissions were altered for an object and system logs indicated that the changes were made on a user’s account during their shift. Such an event would provide telling evidence about who most likely interacted with the object.

If, in a “physical” example, an investigator was called in to inspect a case in which a manager’s office was broken into, one of the first questions s/he would ask would be: “Who has the keys to the door?” Like keys, permissions give you an idea of who has access to certain files. By identifying who has keys or which accounts have permissions, an investigator can make deductions about how an incident most likely occurred. For instance, if only specific User IDs have permissions to a specific file, and the data of the file was stolen, the FE can make an educated guess and dig into the logs to verify if that happened.