Leadership Blog

Squalo Antenna for 6m Amateur Radio Band

As somebody who has been a licensed amateur radio operator since some time in the mid-1990’s, the 6m band has always been interesting to me. Since I never had the equipment to venture out on it, it has mostly been one of those mystery bands that I heard people talk about, but never was able to participate in.

Some time ago, I pickup up an Icom IC-7100. While it has built-in support for 6m, I didn’t have the antenna equipment to do anything meaningful. The dipole strong in my attic never cleanly tuned, so I ignored the band.

A few weeks ago, the Youtube Algorithms thought that I might be interested in K2CJB’s video on building a 6 Meter Square Halo Antenna. The fact that the build was based on a plan by PA3HCM didn’t hurt either.

So, after obtaining some copper pipe to augment what I already had in my junk pile, I figured out how to solder copper and started the build. All in all, the project is very straightforward.

I did make a few alterations:

1. I added a spacer between two pipes to which the feedpoints connect. I 3D-designed it and printed it using PLA filament. It is available here as squalo spacer v1.stl.

2. I designed and printed the insulator. Note that to tune the antenna to be resonant at 50.3 MHz, I had to extend to spacing to 4 3/8 of an inch. The insulator is available here as squalo coupler v2.stl.

3. I attached the antenna to 1.25” PVC pipe. To make sure that it didn’t go anywhere, I created two mounting brackets. The design for them is available as squalo mounting bracket v3.stl.

The end results works. With the antenna only up some 4.5m above the ground, I can work the US East Coast north to south. The antenna’s lowest SWR is 1:1.08 at 50.3 MHz with a 51 ohm impedance.

Next step is to shorten the feedline and get it up higher.

This was a fun project!

de W2CJL

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.

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.

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.