Blog

Welcome to the Information Security Leadership blog.

Latest post

SANS Holiday Hack Challenge 2018, Question 5

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 and question four is here.

Question 5

Challenge: Using the data set contained in this SANS Slingshot Linux image, find a reliable path from a Kerberoastable user to the Domain Admins group. What’s the user’s logon name? Remember to avoid RDP as a control path as it depends on separate local privilege escalation flaws. For hints on achieving this objective, please visit Holly Evergreen and help her with the CURLing Master Cranberry Pi terminal challenge.

Solution: This question confused me the most. It took a while before I caught on to what was expected. Much of this confusion came from my lack of familiarity with the Bloodhound tool on which this challange was based. That’s on to me, because the most recent pentest that I commissioned also used the tool heavily. To great success too, might I add.

Anyway, Bloodhound is a tool that can be used to navigate the complex structures formed by many Active Directory domains. The tool does this through visualization, much like our now long dead (and lost to history) ConceptBrowser tool. In addition, Bloodhound supports querying through a number of useful predefined queries, or by running custom work.

Bloodhound Screenshot

It took a little practice to get somewhat proficient with the tool, but once I managed to figure out how to run it, the query “Shortest path to domain admins from Kerberostable Users” and removing all RDP links, leaves two users (LDUBEJ00320 and JGUMBEL00486).

Note: the submission required the username to be fully qualified and in all caps: JDUBEJ00320@AD.KRINGLECASTLE.COM.

Bigger Picture: CISOs can learn the following lessons:

  1. Opening up your AD domain so that any user can query (and browse) it is probably not a great idea. I found this out the hard way during our latest pentest as well. Lesson learned: restrict visibility. Security through obscurity does not work, but it sure helps.

  2. Stay up-to-date with tools. Bloodhound has been around for years, but I had never heard of it. There is more than Metasploit out there, and while knowledge of tools is second to knowledge of methods and techniques, one can lead to the other.

Other recent posts

SANS Holiday Hack Challenge 2018, Question 4

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.

SANS Holiday Hack Challenge 2018, Question 3

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 3

Challenge: The KringleCon Speaker Unpreparedness room is a place for frantic speakers to furiously complete their presentations. The room is protected by a door passcode. Upon entering the correct passcode, what message is presented to the speaker? For hints on achieving this objective, please visit Tangle Coalbox and help him with the Lethal ForensicELFication Cranberry Pi terminal challenge.

Solution 1: As always, when given a challenge website, it pays to just play around with it a bit. In this case, the page is fairly simple— it is a single web page that includes some JavaScript that validates the code that is provided against checkpass.php using two parameters: i and resourceId. The PHP page at https://doorpasscoden.kringlecastle.com/checkpass.php indeed loads and returns some JSON.

It appears that the actual logic to validate the passcode is contained in that PHP-file. Bruteforce is an option– four positions with four possibilities per position is 256 options, which is pretty easy.

However, we were given a hint. Tangle Coalbox, an elf in the game, provided a reference about De Bruijn Sequences. I had not heard about those, but Google had ;)

After plugging in the correct parameters into http://www.hakank.org/comb/debruijn.cgi, the keyspace was listed. After eliminating all code that were not exactly four chars long, I was left with 60 codes to test. That was almost enough to write a script that iterates over all four of them against “https://doorpasscoden.kringlecastle.com/checkpass.php?i=”, however:

  1. I needed to find a resourceId and that seemed like work, and

  2. No guarantee that there wasn’t some browser check of sorts.

60 possible keys tested manually is probably less than 5 minutes, which is less than a quick python script. Access obtained.

Solution 2: In this case, bypassing the authentication subsystem was actually unnecessary. Opening https://doorpasscoden.kringlecastle.com in Google Chrome and activating the Developer Console listed an image containing the text “Welcome unprepared speaker!” when choosing Sources > Page > doorpasscoden.kringlecastle.com > (index).

Bigger Picture: CISOs can learn a few bigger picture lessons from this challenge:

  1. Online authentication systems must use a keyspace that is large enough infeasible to test all possible combinations in a reasonable amount of time. Cryptographers call this a “cryptographically secure” system.

    In this case, there were only 256 possible combinations. Even without automation, that is easy to guess.

  2. In order to prevent somebody to quickly execute an enumeration of all keys, the system should have some form of detection mechanism. At bare minimum, the system should recognize multiple login attempts from a single IP address, login attempts for a specific user to prevent dictionary attacks, and repeated use of the same password against multiple accounts to detect password spraying.

    The latter is a bit trickier, since it will require storing passwords that are submitted to the system. If not done very carefully, that might lead to more problems than it solves.

    If repeated attempts are detected, a temporary block can be imposed.

  3. Authentication systems must log all attempts (successful and failed). At bare minimum, the log should contain a timestamp (preferably in UTC), source IP address, target username, success status, requested resource, and, possibly, some form of client identifier like a browser user agent.

SANS Holiday Hack Challenge 2018, Question 2

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 three can be found here.

Question 2

Challenge: Who submitted (First Last) the rejected talk titled Data Loss for Rainbow Teams: A Path in the Darkness? Please analyze the CFP site to find out. For hints on achieving this objective, please visit Minty Candycane and help her with the The Name Game Cranberry Pi terminal challenge.

Solution: After looking around the website a bit, and, of course, viewing the page source, the solution started to emerge. While browsing, it always pays to keep an eye on the URLs that are being loaded. Often, the URLs reveal interesting information.

For this challenge, the main page is at https://cfp.kringlecastle.com/index.html while the CFP page is at https://cfp.kringlecastle.com/cfp/cfp.html.

What we have here is an information disclosure vulnerability. While often classified as “low severity” vulnerabilities, they have the potential to be quite damaging.

In this case, the vulnerability can be “exploited” by removing cfp.html from the address.

Opening https://cfp.kringlecastle.com/cfp/ in a browser reveals a directory listing, which includes a file rejected-talks.csv.

Talk qmt3 is the one we were asked to find. Columns 7 and 8 give us the name of the person who submitted it: John McClane.

Bigger Picture: There are a few bigger lessons here.

  1. Developers must take care to not save any data into files located in areas of the filesystems that are accessible by web browsers. Someday, somebody will find them, and that may end up being a resume-generating event for the CISO.

  2. Production systems should pretty much never reveal more about a system than what is absolutely necessary. Directory listings are one of those things. While they can be useful during development, they do not serve a purpose in production. You only need a directory listing if you don’t know what’s in the filesystem. If you don’t know what’s in the filesystem, you probably have no business being there anyway.

While on the topic of not unnecessarily disclosing any information, I can point out a small pet peeve of mine. A quick banner grab (ncat -vC --ssl cfp.kringlecastle.com 443), followed by a valid HTTP request (GET / HTTP/1.0) returned

HTTP/1.1 200 OK
Server: nginx/1.10.3

There really isn’t a good reason for a web server to announce its exact version (or even its make and model). Just disable that.