One of the highlights of the end of the calendar year is the SANS Holiday Hack Challenge. This year, I took the time to work through the challenges. It was fun!

In the next couple of posts, I’ll write up some solutions to the 2018 challenges.

My answer to question two can be found here. Question three is answered here.

Question 4

Challenge: Retrieve the encrypted ZIP file from the North Pole Git repository. What is the password to open this file? For hints on achieving this objective, please visit Wunorse Openslae and help him with Stall Mucking Report Cranberry Pi terminal challenge.

Solution: It helps to know that Git is a revision control system that keeps track of changes to files. Since we are looking to decrypt a zip file, the first step is to find that file. Browsing through the repository revealed that there is a file called ventilation_diagram.zip, which resides in https://git.kringlecastle.com/Upatree/santas_castle_automation/tree/master/schematics.

For whatever reason, most of my students are under the impression that, no matter what, passwords are easily (==quickly) found through bruteforce testing. That’s a common misconception, and for most people with limited computational resources, not worth pursuing.

Instead, we have to be smart(er).

A revision control system is very good at tracking revisions. To keep track of what changes with each revision, developers are encouraged to leave a brief, but meaningful, comment with each “commit”.

Inspecting the revisions (“commits”, in Git terms) is easy. Just click the History button.

The revision history shows that on December 11, Shinny Upatree committed a change labeled ‘removing accidental commit’. One developers accident is another hacker’s gold, and looking at the commit changes quickly reveals that a file containing the password ‘Yippee-ki-yay’ was removed.

Bigger Picture: CISO’s can learn a few lessons.

  1. Unless developers take care, removing a file from the current working copy of the source tree does not also remove it from the history of the repository. Most revision control systems allow an administrative override that can be used to change history.

  2. Keeping credentials (and other sensitive configuration elements) in a repository is a bad plan. Too often, revision control repositories contain private keys, passwords, URIs to internal network resources, internal IP addresses, etc.

    Programs do have a legitimate need to have these configuration items, but they should be kept in a separate configuration file that is never committed to the repo.

  3. Although there is inherent risk in using revision control systems, they are an incredibly useful tools. Havings developers who are (very) proficient at using a revision control system is a great asset. However, it is also important to keep on eye on what tools they are use. Often, “not invented here”-syndrome kicks in, and people prefer to use their own tools over corporate ones.

    This risk is even greater when using consultants. Make sure all code is maintained in whatever revision control system your organization decided on, and make sure that nobody has a shadow copy elsewhere. Source code in revision control is too valuable.

    Most intrusion detection systems and/or next generation firewalls are able to detect revision control system traffic. Running a report every now and then cannot hurt.