This is all about malware analysis, reverse engineering and some cool stuff

Monday 1 October 2018

Flare-On Challenge 2018 Writeup

October 01, 2018 Posted by SDKHERE No comments
Flare-on is an annual CTF challenge organized by Fire-eye with a focus on reverse engineering.
Overall, there were 12 challenges to complete similar to the last year 2017. Instead of the detailed write-up, I am just covering the important parts.
Following are the instructions to solve these challenges:
1. Analyse the sample and find the key
2. Each key looks like an email address and ends with @flare-on.com
3. Enter the key for each challenge in Flare-on CTF app to unlock next challenge
4. Complete all the puzzles and win a prize

Flare-On 2018 challenges - download
Password - flare


Challenge 1 : MinesweeperChampionshipRegistration.jar

The first challenge is very simple. There is a jar file which is asking for an invitation code to proceed.
I have used Jd-gui tool to check the code of jar file. It is just comparing input directly to the hard-coded key.



key : GoldenTicket2018@flare-on.com


Challenge 2 : UltimateMinesweeper.exe



Challenge 3 : FLEGGO.zip

I have solved this challenge statically.
The zip contains 48 PE files and each and every file asks for the password. If you enter anything wrong it will display "Go step on a brick!". so I have loaded one file in CFF and found a resource of name "BRICK".

This BRICK is different in each and every file so I have entered the ascii of first 20bytes in the same file in place of a password. Yes I guessed it right :)


When we enter correct password it drops a png file and displays a character associated with it. Here we have "w" and the associated png file looks like below.
So this means 23rd character of our key will be "w".
I have created a below python script to automate this for every file and extracted all the png and their associated characters.


marker = "\x42\x00\x52\x00\x49\x00\x43\x00\x4B\x00\x00\x00\x00\x00"
for file in files:
 filepath = os.path.join(directory, file)
 data = open(filepath, 'rb').read()
 password = data.split(marker)[1][:0x20]
 password = password.replace('\x00','')
 p1 = subprocess.Popen(filepath, stdin=subprocess.PIPE, stdout=subprocess.PIPE)
 res = p1.communicate(input=password)
 res = res[0].split('\r\n')
 png_name = res[2].split('=>')[0].strip()
 charname = res[2].split('=>')[1].strip()
 png_path = os.path.join(directory, png_name)
 new_png_path = os.path.join(directory, charname+'_'+png_name)
 os.rename(png_path, new_png_path)

Key : mor3_awes0m3_th4n_an_awes0me_p0ssum@flare-on.com


Challenge 4 : binstall.exe
This is confuser packed DotNet binary. After execution, It drops a DLL in %APPDATA%\Microsoft\Internet Explorer\ with name browserassist.dll and adds its path to AppInit_DLLs registry (HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs). This is one of the DLL injection technique. AppInit DLLs are loaded by user32.dll after it has been loaded.
When you debug standalone DLL with ollydbg, you will find below code.
The first function calculates crc32 of parent process name and compares it with some hard-coded value. so this dll must be injected into some specific process, the hint is already given in the instruction like "especially if they are a Firefox user". so If you replace loaddll.exe with firefox.exe then checksum will definitely match.
The second function calls GetVersionInfoA API to fetch the version of the parent process (firefox.exe) and compares it with >55. It requires firefox of version less than 55 to proceed further otherwise it will exit.
If both these function succeed, it will create a thread to proceed further.

This thread downloads base4 encoded and encrypted data from URL hxxp://pastebin.com/raw/hvaru8NU and decode and decrypt it using RC4 algorithm with the key md5("FL@R3ON.EXE"). After decrypted code is json file which looks like below.

This is web injection technique similar to TinyNuke malware. At the last DLL injects this json into firefox. If the webpage contains "code" section shown in json then it will replace by "content" section. In the end of this json file, host and file path is already given.
"path": "/js/view.js",
"host": "*flare-on.com"
So the web-injection is going to happen in flare-on.com only.
If you open flare-on.com in infected firefox you will see the changes in the code.
You have to compare the code of original site and infected site and understand what that extra code is doing. It has added an extra command "su" to get the password. It takes the password and compares it with 10 different characters. After RE of that code, you will get the password of size 10 chars.
password : k9btBW7k2y
The story is not over yet. You need to understand the extra piece of code like what happens when the user is superuser (su). there is a hidden directory of name "Key". If you get in there then you will get the key.
cd Key
ls

Key : c0Mm4nD_inJ3c7ioN@flare-on.com


Challenge 5 : web2point0 (wasm)

This is very interesting and new challenge.
It contains 3 files. index.html, main.js and test.wasm
The index.html loads main.js and main.js executes test.wasm file.
The main.js takes the parameter from URI variable "q" and calls webassembly(wasm file) with this parameter, If the return value is 1, it will show party popper otherwise Pile of Poo.
I have used firefox for webassembly debugging.
I have appended the parameter in URL like ?q="abcdefgh" and checked where these parameter is being used by step by step debugging. I know this is painful but there was no other way :(
It was comparing each byte of the parameter with some value, I set a breakpoint at the comparison and recorded each value.

0xBF2 is where it is comparing parameters with constant values.

 Key : wasm_rulez_js_droolz@flare-on.com


Challenge 6 : magic



This loop runs 666 times and it changes the magic file in every iteration.
It asks for the key and when you enter the key it will be processed by sub_402DCF function only.

0 comments:

Post a Comment