Data Loss Prevention: git
Welcome back to the 12th iteration of this blog series. In this series, we’re growing our cybersecurity knowledge starting from the very basics using the overthewire.org challenges as a guide. First, I’d like to thank everyone for their feedback based on the last post! I’ll do my best to implement it and as always, more feedback is always welcome. Now let’s start!
Today is an introduction to git. To put it simply, git and Github are code sharing and collaboration systems. It’s almost like a google doc but for code where people can contribute to a project together. Github is an online platform while git itself can be hosted locally on an internal server (as is in this case).
The first thing we have to learn about git is the ability for individuals with access to clone a project. git clone works by reaching out to the project at the specified address and protocol then proceeds to clone the whole project on to the local storage (typically in the directory where you initiated the clone).
So let’s do that:
Now check the current directory:
Let’s check the “repo” directory:
Before we take a look at the README, git projects typically include a Readme file to explain the project and generally as a way of communication between collaborators. Let’s see what this one says:
Simple enough, on to the next but a quick question for you do we need to actually log in to bandit28 to continue?
Once again we have another project, let’s clone it:
Let’s check the Readme file:
So it seems like the password could have previously been printed in the Readme file like the previous level. Fortunately, git projects track changes between commits. Let’s check the log:
The log is listed from newest to oldest and it generally carries a description for new commits and changes. We can see that in the most recent commit, Morla fixed the information leak, which was likely the password. Unfortunately for Moral, git also keeps the changes:
There it is. git is an amazing tool for collaborating on projects and in the case of private projects like this one, collaborators might exchange sensitive information to make it easier to access the data. As is evident by this challenge, this is not best practice for sharing sensitive data and it should be done through a more secure communication that reaches only those working on the project.
Beyond just having access to sensitive information or intellectual property that’s within the project itself, it’s important to realize that a malicious actor can inject their own code. This bad actor can solidify their future presence by adding code to the project that would open a backdoor for easier access in the future.
While an attacker might be able to access a sensitive system, all is not lost unless they can exfiltrate the sensitive data. This is the realm of Data Loss Prevention. DLP can be implemented in many ways but essentially they all function to prevent data loss: these systems should prevent data deletion, data exfiltration, and even data encryption.
AI development has helped make great improvements in the field of cybersecurity. Some of the common methods of DLP implementation is through using heuristic or behavioral models of employee activity. In a large organization where restricting access to certain sensitive data could stop production, heuristic models remember “normal” user behavior by establishing a baseline. These systems then compare new activity against the baseline to trigger alerts and restrict or deny access altogether to users who violate the model.
