April 15, 2014 at 14:36Results and analysis of tasks of the online tour NeoQUEST-2014
It is time to take stock of the NeoQUEST-2014 online tour, including: - analyze all 7 quest tasks (for every day of the week!);
- tell about the winners and their awards;
- tell us what awaits the participants and guests of the event in the in-person tour of NeoQUEST-2014, which will be held July 3 in St. Petersburg at the Polytechnic University.
About the winners
“Gold”, “silver” and “bronze” of the online tour received AV1ct0r, n0n3m4 and Dor1s respectively. The struggle for first place was very hot, for three days the leader was constantly changing - AV1ct0r and n0n3m4 pulled out each other first place, and the difference between them was only a couple of points. But then AV1ct0r completed the “fake citrus” mission and strengthened his leadership by 113 points! We cannot but note the will of n0n3m4 to win and his undoubted talent (he was the first to complete the quest in the quest). The “bronze” medalist of Dor1s lagged a bit behind the second place, but realized a big gap from the following participants.
Congratulations to the winners, the main prizes and face-to-face tour await them, a victory in which will bring the winner a trip to one of the international hacking conferences! AV1ct0r and n0n3m4 are awarded smart watches from Samsung and Sony (and here's another interesting review on Habré), respectively, and Dor1s gets almost a three-kilogram robot, also not stupid! By the way, everyone who has completed at least one NeoQUEST-2014 mission will also receive a small prize. Since the standard ideas of memorable souvenirs (cups, notebooks, flash drives, pens, chocolates, etc.) have already exhausted themselves, our souvenir will amaze the participants, but most of them will most likely use it sooner or later! We contact all the winners. Dear participants, check your mail for letters from info@neoquest.ru!
Analysis of tasks
NeoQUEST-2014 consisted of 7 tasks from various areas of cybersecurity:
1) "My not to understand yours" - reverse engineering applications in C #;
2) "Hasta la vista" - reverse engineering Android-applications;
3) “TimeShift2. Revenge "- a temporary attack on the RSA;
4) “Frozen computer” - receiving video memory of a virtual machine from a RAM dump;
5) “An unknown smoking device was detected” - analysis of a sync dump via USB of an Android phone with a computer;
6) "Igrodrom" - the use of port knocking to play Pac-Man;
7) “Would the citrus live in the thickets of the south?” Yes, but a fake copy! ” - a task for reverse engineering, knowledge of DEP and ASLR bypass technologies, the basics of cryptography and the ability to exploit binary vulnerabilities.
The tasks “An unknown smoking device was discovered”, “Igrodrom”, “Would citrus live in the thickets of the south?” will be examined in detail in the May issue of Hacker magazine. In addition, our participants wrote a sufficient number of writeups in which you can read how they completed this or that task. Here writeup is from AV1ct0r, here is from n0n3m4 and there is from Dor1s.
1 - Mine is yours not to understand
The task was based on technology that allows you to embed applications written in C # into Internet sites. Perhaps this is only if the site is written in asp.NET. True, there are certain limitations. Only Internet Explorer can display the graphical shell of the applet, other browsers can only use the functions it exports.
The participant in the quest from all the source data received only the IP address of the site, when you clicked on it, such a page was loaded:
The page displayed the address of the user who visited the site, and still incomprehensible hieroglyphs. The address highlighted in white hints that the site is not indifferent to the location from which the user accesses it.
If you enter the hieroglyphs displayed by the site into the translate.google.com service , you get this:
The service automatically identified the language as Vietnamese, this should prompt the quest participant to the idea that it is worth trying to visit the site through a Vietnamese proxy server. Lists of proxy servers are freely available on many sites, for example, here .
Using a Vietnamese proxy leads to the desired result. The participant is shown a different version of the site with the task: The
user is presented with a form for entering data, but what needs to be entered there? That's the question. To do this, you need to delve into the source code of the page, then such a curious piece is discovered:
The source code of the page explicitly indicates the path to the C # applet. But, as mentioned above, it does not appear in any browsers other than Internet Explorer. This is what the site looks like in IE when using a proxy server:
However, the graphical part of the applet does not affect the progress of the task. The buttons in its interface do not carry any payload.
The participant’s next task is to study the source code of the applet. Applications written in C # are quite easy to decompile. For example, you can use the .NET Reflector application. We
get the source code of the applet: In a decompiled application, it is easy to find a class with the speaking name KeyStore. It stores the key, which must be entered into the form on the site.
By the way, the key verification function is also implemented in the applet. By means of asp.NET it is called and checks the input information for correctness. This functionality works in any browser. Assignment completed!
2 - Hasta la vista
In the task, the participants received a certain file MyGreenManController.zip, upon opening which it became clear that it was nothing more than an Android application (yes, in fact, the name of the file prompted): The
participants had to reverse this file. To do this, you needed to know what an application is for the Android operating system. This is nothing more than an archive packed with a zip and having the extension “.apk”. This archive contains application resources, the AndroidManifest.xml file, which determines the rights of the application, its name, etc., and the classes.dex file. The latter is the bytecode of the program compiled for the Dalvik virtual machineused by Android. Obtaining java source code from it just doesn’t work, but you can get a set of commands for the virtual machine - dalvik opcodes. This method is not particularly suitable for analyzing applications, since there is another, simpler and more convenient one, which consists in converting a dex file to a jar, which can be decompiled and get quite readable code in java.
Reversing is reduced to obtaining the classes.dex file, using the Apk Manager utility or a simple archiver. Then, using the dex2jar utility, we get the classes.dex.dex2jar.jar file, which is very convenient to learn using the jd-gui program.
The entry point is the Code class:
public class Code extends Activity
{
public static String aA = "";
public void onCreate(Bundle paramBundle)
{
super.onCreate(paramBundle);
setContentView(2130837504);
TextView localTextView = (TextView)findViewById(2130968577);
((Button)findViewById(2130968578)).setOnClickListener(new View.OnClickListener(localTextView)
{
public void onClick(View paramView)
{
Code.aA = Code.this.getApplicationContext().getFilesDir().getAbsolutePath();
String str = new AA().a(this.val$aaa.getText().toString(), Code.aA);
if (str == null)
Toast.makeText(Code.this.getApplicationContext(), "Error", 0).show();
do
return;
while (!str.equals("Correct command"));
Toast.makeText(Code.this.getApplicationContext(), "Correct command", 0).show();
A localA = new A();
try
{
localA.a((TelephonyManager)Code.this.getSystemService("phone"));
return;
}
catch (Exception localException)
{
localException.printStackTrace();
}
}
});
}
}
What does the Code class do? When you click on the button in the variable aA, the path to this application is written (and yes, the names of the methods and classes of the same type were made solely to confuse the quest participants a little):
Code.aA = Code.this.getApplicationContext().getFilesDir().getAbsolutePath();
Then, the result of the execution of method a from the class AA is written to the variable str.
Method a is simple to impossibility:
public String a(String paramString1, String paramString2)
{
if (!paramString1.equals("download_image"))
return null;
aa("http://10.0.31.111/index.php", "neoquest_2014", paramString2 + File.separator + "neoquest_2014");
return "Correct command";
}
If a command other than “download_image” is entered into the text field, null is returned, otherwise the aa method is called with the following parameters:
aa("http://hastalavistababy.ru/index.php", "neoquest_2014", paramString2 + File.separator + "neoquest_2014");
The aa method forms a line of the form:
«cmd=1&time=xxx&command_name=download_image&path=neoquest_2014»
And then it calls the getExampleInFile method, which saves the response from the server to a file:
getExampleInFile("http://hastalavistababy.ru/index.php", cmd=1&time=xxx&command_name=download_image&path=neoquest_2014, /data/data/com.example.NeoQUEST2014/files/neoquest_2014);
As a result, the file downloaded from the server will appear in the files folder of our application. Due to the fact that you can only get this file on the phone with root privileges, you should use the wget utility and download the file with the following command:
wget.exe http://hastalavistababy.ru/index.php?cmd=1&time=xxx&command_name=download_image&path=neoquest_2014
What is this strange file? The Code class will answer this question. After downloading the file, the a method of class A is called with the TelephonyManager parameter:
A localA = new A();
try{
localA.a((TelephonyManager)Code.this.getSystemService("phone"));
return;
}
Method a does the following:
public String a(TelephonyManager paramTelephonyManager)
throws Exception
{
StringBuffer localStringBuffer = new StringBuffer();
localStringBuffer.append(paramTelephonyManager.getDeviceId());
if (!paramTelephonyManager.getDeviceId().equals("352276054393855"));
do
{
return null;
localStringBuffer.append(paramTelephonyManager.getSimOperator());
}
while (!paramTelephonyManager.getSimOperator().equals("25001"));
localStringBuffer.append(aaaa("neoquest_2014"));
String str = aaaa(localStringBuffer.toString());
localStringBuffer.setLength(0);
localStringBuffer.append(str);
aa(localStringBuffer.toString().substring(0, 16).getBytes());
return "Success";
}
First, he takes the phone’s ID and checks that it matches the string “352276054393855”, and the carrier’s ID checks that it matches the string “25001” and adds these lines to the localStringBuffer variable:
if (!paramTelephonyManager.getDeviceId().equals("352276054393855"));
do
{
return null;
localStringBuffer.append(paramTelephonyManager.getSimOperator());
}
while (!paramTelephonyManager.getSimOperator().equals("25001"));
Then the string "neoquest_2014" is added to the localStringBuffer variable:
localStringBuffer.append(aaaa("neoquest_2014"));
Then the aaaa method is called with the parameter - the formed string. This method considers the hash according to the MD5 algorithm:
String str = aaaa(localStringBuffer.toString());
Next, the aa method is called with the parameter - the first 16 bytes of the received hash:
aa(localStringBuffer.toString().substring(0, 16).getBytes());
The aa method decrypts the downloaded neoquest_2014 file with a key consisting of the first 16 bytes of the same hash, and the result is written to the neoquest_2014_original file:
public static void aa(byte[] paramArrayOfByte)
throws Exception
{
SecretKeySpec localSecretKeySpec = new SecretKeySpec(paramArrayOfByte, "AES");
byte[] arrayOfByte1 = IOUtils.toByteArray(new FileInputStream(Code.aA + File.separator + "neoquest_2014"));
Cipher localCipher = Cipher.getInstance("AES/ECB/PKCS5Padding");
localCipher.init(1, localSecretKeySpec);
localCipher.init(2, localSecretKeySpec);
byte[] arrayOfByte2 = localCipher.doFinal(arrayOfByte1);
FileOutputStream localFileOutputStream = new FileOutputStream(Code.aA + File.separator + "neoquest_2014_original");
localFileOutputStream.write(arrayOfByte2);
localFileOutputStream.close();
}
Thus, the participants had to download the file to a computer (or from the phone, for lovers of perversions), and then restore the key and decrypt the downloaded file.
3 - TimeShift 2. Revenge
Assignment from the in-person tour of NeoQUEST-2013, then no one could pass it. We finalized it for an online tour, and this time many coped with it.
From the legend, we have two IP addresses with a port (213.170.102.196-00-00001, 213.170.102.197-00-00002) and the key B4365F2.
Having established a connection with the first server and sending arbitrary data (for example, netcat), we get the answer:
ilya@debian:~$ netcat 213.170.102.196 4001
hi
ЖїAlert! Expected client hello message.
Format:
1 byte type NEOSSL_HANDSHAKE 0x16
2 byte version NEOSSL1_VERSION 0x01
3-4 bytes length (excluding header)
5 byte data NEOSSL_CLIENT_HELLO 0x01
---DEBUG INFO---
Ubuntu Release 10.04 (lucid)
Kernel Linux 2.6.32-21-generic
Memory 1001.9 MiB
Processor Intel(R) Core(TM) i3 CPU
Processing time 1471 cycles
Processing threads - 1 thread
Public-key cryptography algorithm - RSA (with Montgomery multiplication)
Symmetric-key cryptography algorithm - AES-128 (zero IV)
------
The host responds with an error message that contains the expected message format and debug information. The server expects to receive a client hello message: {0x16, 0x01, 0x00, 0x01, 0x01}. Out of 5 bytes, 4 is included in the message header, one (NEOSSL_CLIENT_HELLO) in the data.
Check the second server.
ilya@debian:~$ netcat 213.170.102.197 4002
hi
뤲t! Expected server hello message.
Format:
1 byte type NEOSSL_HANDSHAKE 0x16
2 byte version NEOSSL1_VERSION 0x01
3-4 bytes length (excluding header)
5 byte data NEOSSL_SERVER_HELLO 0x02
6 byte data RSA_WITH_AES_128_CBC 0x01
7-n bytes data Certificate
---DEBUG INFO---
Ubuntu Release 10.04 (lucid)
Kernel Linux 2.6.32-21-generic
Memory 1001.9 MiB
Processor Intel(R) Core(TM) i3 CPU
Processing time 1531 cycles
Processing threads - 1 thread
Public-key cryptography algorithm - RSA (with Montgomery multiplication)
Symmetric-key cryptography algorithm - AES-128 (zero IV)
------
The second host responds with a client hello message and waits for a server hello message containing the server certificate. Thus, the first host acts as a server, the second as a client. Forwarding their messages to each other and analyzing error messages, you can understand the communication protocol.
1. The client sends a NEOSSL_CLIENT_HELLO message.
2. The server responds with a NEOSSL_SERVER_HELLO message containing the secure connection parameters (RSA_WITH_AES_128_CBC) and a certificate.
3. The client sends a NEOSSL_KEY_EXCHANGE message containing the AES-128 session key encrypted with the server’s public key.
4. The server responds with NEOSSL_FINISHED.
5. The client sends the encrypted data.
Encrypted data is also sent with a header and has the following format:
1 byte type NEOSSL_DATA 0x17
2 byte version NEOSSL1_VERSION 0x01
3-4 bytes length (excluding header)
5-n bytes data
Since there is no client authentication in the scheme, you can try sending messages to the server, however, without knowing the protocol for further communication, this will not bring any results.
You need to get the data that the client sends to the server in the 5th step. You can try to generate a certificate and use it to establish a connection with the client. However, the client checks the received certificate and does not accept the generated certificate. Almost nothing is known about AES encryption (the key is different each time, the message can probably also change and its content is unknown). So, you have to crack the RSA.
You need to get the server private key. There is a server certificate (containing the public key) and access to the encoder (in step 3, the client sends data that the server decrypts and interprets as a session key).
Among the attacks against RSA, there is an interesting class of attacks related to the implementation of encryption. The most interesting attack is the execution time, because the debug information contains the time that the server spent on decrypting the message (and also the job name hints!). What is also known about encryption is that it uses Montgomery multiplication to increase the encryption speed.
You can use the attack described in the Harshman Singh article “ Timing Attacks on software implementation of RSA to crack the secret key.”". The attack allows one of the factors of module n to be calculated. Opening the multiplier is performed bitwise, starting with the most significant bits. To open the encoder, requests are generated from the current known value of the module and the time difference is calculated if bit 0 or 1 is selected. If the difference is large, the zero bit is set, otherwise “one”. The first three bits of the multiplier must be guessed. After opening the multiplier, it is easy to calculate the server’s private key.
Next, having established a connection with the client, we will try to decrypt the session key and the message encrypted with the AES cipher. The debugging information says that the zero initializing vector AES is used. Here is the message received from the client:
To obtain the access to the missile control system send a message: "XXXXXXX:Connect".
XXXXXXX - ID
As the ID, you need to use the value from the job - B4365F2. You must encrypt the string “B4365F2: Connect” using the session key and send it to the client. Having deciphered his next answer, we get a hash - f9e8ceee19e980bd68e3193d6d0de2d3, this is our key. Assignment completed!
4 - Frozen computer
This task was devoted to the analysis of the dump memory data, which was issued to the participants as a 1GB file. The dump was obtained by simply copying the vmem file from a running and pre-configured virtual machine. The peculiarity of the task was that inside one VMware virtual machine, from which the dump was provided, another virtual machine was created and launched under the control of Oracle Virtual Box. The task diagram looked like this:
Both virtual machines were running the same versions of Windows 7, so there were two operating systems in the memory dump at the same time, whose memory pages were heavily scattered around the dump. NeoQUEST participants needed to find the key in the dump. The presence of two virtual machines and the determination of their types were found out quite easily, by analyzing all the text lines in memory. It is interesting to note that when using CMAT on a dump issued to participants, the program refused to work normally, while the Volatility Framework successfully did its job and found two operating systems at once.
The winner of AV1ct0r used the Volatility Framework to solve this problem., about which he wrote in detail on his blog. Another feature of the NeoQUEST task was that the key that the participants had to find was only in the form of a graphic image in the video memory of the Virtual Box virtual machine. Therefore, for the solution, it was necessary to restore the video memory of this virtual machine. There are two ways to solve this, since the RAM and video memory of the Virtual Box virtual machine are simultaneously mapped into the physical memory of the VMware virtual machine and into the virtual memory of the Virtual Box process with emulators (oddly enough, VirtualBox.exe).
AV1ct0r solved the task using the memory dump of the VirtualBox.exe process, allocating video memory and making a picture of it using the virtual address found in the logs. He also dumped the process using the Volatility Framework. Here is the algorithm for solving the task with obtaining video memory of the Virtual Box virtual machine and forming a picture from it, using mapping of the video memory into the physical memory of the VMware virtual machine.
Step 1. Get all readable lines from the memory dump of the VMware virtual machine using the strings.exe utility. The file with the lines is impressive: 196 MB.
Step 2. We find out that the Virtual Box virtual machine is running and get a piece of the log from its launch with more detailed and necessary information for us:
:2013122720131228: komsomol@file:///C:/Users/komsomol/VirtualBox%20VMs/KP-2/Logs/VBox.log
00:00:02.305000
00:00:02.305001 [/DBGF/] (level 1)
00:00:02.305002 Path = "C:\Users\komsomol\VirtualBox VMs\KP-2/debug/;C:\Users\komsomol\VirtualBox VMs\KP-2/;C:\Users\komsomol/" (cb=103)
00:00:02.897225 HWACCM: TPR shadow physaddr = 000000003dd5f000
00:00:02.897227 HWACCM: VCPU0: MSR bitmap physaddr = 000000003dd67000
00:00:02.897229 HWACCM: VCPU0: VMCS physaddr = 000000003dd65000
00:00:02.897653 CPUMSetGuestCpuIdFeature: Enabled sysenter/exit
00:00:02.897655 HWACCM: 32-bit guests supported.
00:00:02.897656 HWACCM: VMX enabled!
00:00:02.897656 HWACCM: Enabled nested paging
00:00:02.897658 HWACCM: EPT root page = 000000003dd8b000
From the log, we learn that hardware virtualization is enabled and that hardware support for nested paging page tables is enabled. The latter means that Virtual Box sets up EPT (Extended Page Tables) tables, which are then used by the processor to translate the physical addresses of the virtual machine into the physical addresses of the host machine. In our case, the physical addresses of the Virtual Box virtual machine are offsets in the memory dump file. To learn more about the EPT format (and that it conforms to PML4), you need to read the processor manual.
The address of the root table is visible in the log and it is 3dd8b000. Like any translation tables, they use exclusively physical addresses that correspond to absolute offsets in the dump file, so it remains to read out the video memory, which is also located in the physical address space of the Virtual Box virtual machine and is mapped using the EPT.
VGA device emulators (video adapters) use the host RAM to simulate video memory for a virtual machine, and to directly draw pictures on the screen, they simply copy the RAM to the host video memory periodically - exactly how the classic double buffering algorithm works, which is used in many graphic engines.
Step 3. Find out the physical address of the video memory for the Virtual Box virtual machine.
It is not in the dump, therefore, to find it out, just run Virtual Box on your computer and look at the value in the video adapter resources tab (by the way, there is RAM size in the dump):
00:00:02.305353 VRamSize = 0x0000000001000000 (16 777 216, 16 MB)
Step 4. We determine the format and size of the video image. In the video memory, the graphic data is stored in a specific format that is similar to the usual BMP format: sequentially bytes RGBXRGBX ... for each pixel 3 or 4 bytes. We recognize the screen resolution and bit rate from the log:
00:01:14.565973 Display::handleDisplayResize(): uScreenId = 0, pvVRAM=065c0000 w=800 h=600 bpp=32 cbLine=0xC80, flags=0x1
Step 5. Now you need to write a program that reads only video memory from the dump. To do this, the program must parse the page tables in the specified range (starting from the physical address 0xE0000000 with a picture size of 800 * 600 * 4 in length). The main part of the program code looks like this:
DWORD TranslateGPA2HPA( DWORD gpa )
{
vmxGuestPysicalAddress addr;
addr.Value = gpa;
vmxEPTP eptp;
eptp.Value = EPT_base;
DWORD64 pml4_base = (eptp.PML4ShiftedAddr << 12);
vmxEptPML4Entry pml4_ent;
pml4_ent.Value = DumpRead64(pml4_base + 8 * addr.eptPML4EntryOffset);
DWORD64 pdpt_base = (pml4_ent.eptPDPTShiftedAddr << 12);
vmxEptPDPTEntry pdpt_ent;
pdpt_ent.Value = DumpRead64(pdpt_base + 8 * addr.eptPDPTEntryOffset);
DWORD64 pd_base = (pdpt_ent.eptrfPDShiftedAddr << 12);
vmxEptPDEntry pd_ent;
pd_ent.Value = DumpRead64(pd_base + 8 * addr.eptPDEntryOffset);
DWORD64 pt_base = (pd_ent.eptrfPTShiftedAddr << 12);
vmxEptPTEntry pt_ent;
pt_ent.Value = DumpRead64(pt_base + 8 * addr.eptPTEntryOffset);
return (pt_ent.Shifted4KPageAddr << 12) | addr.eptByteOffset;
}
void ReadPage(void *data, DWORD gpa)
{
DWORD offset = TranslateGPA2HPA(gpa & (~0xFFF));
fseek(g_fdump, offset, SEEK_SET);
fread(data, 4096, 1, g_fdump);
}
HBITMAP ReadVideoMemory( DWORD width, DWORD height, DWORD bpp )
{
DWORD size = ((width * height * (bpp / 8) / 4096) + 1) * 4096;
char *bmp = (char *)malloc(size);
for (int i = 0; i < size; i+=4096)
{
ReadPage(bmp + i, 0xE0000000 + i);
}
return CreateBitmap(width, height, 1, 32, bmp);
}
Declaration of structures can be found in the documentation for the processor. The CreateBitmap function can be found on the Internet.
After compiling and starting the program, you get the following picture: The
key is found! As a result, the task can be solved without using CMAT and the Volatility Framework, using knowledge of the video memory device and virtualization technology.
5 - Unknown smoking device detected
According to legend, the participants had to figure out what kind of obscure device they “synchronized with the laptop” to get the key from a file of an unknown format.
AV1ct0r in its writeup'e determined that this file is nothing more than a dump of USB traffic of the Android device, and rightly noted that it is most convenient to work with it in the HEX editor, and not in Wireshark.
After analyzing the dump, we find the names of people, phone numbers and SMS messages. Remembering that important information can be stored in SMS, we look for a hint and find:
Information about birth dates was stored in a notebook, it started with VCARD, there were 4 applicants for the role of wife. The question remained open: what should open this password? A closer look at the dump reveals a file called look_at_this.7z. Google signature 7z files:
37 7A BC AF 27 1C
All that remains is to pull out the archive from the dump and sort through the 4 birth dates received earlier. Inside the archive lies the win.txt file with the key flag. Assignment completed!
6 - Igrodrom
In this assignment, participants were required to play the good old Pac-Man , but in a special way, realizing a kind of port knocking .
Initially, you had to guess that the server only accepts requests with a tag. By trial and error, using prompts from the server coming from port 1898, the participant should finally receive such a welcome message:
It turns out that they are waiting for us at some obscure next congress. Here is the time to turn on the logic and put together disparate pieces of information:
- port 1898;
- Struve;
- congress.
Using search engines, participants had to come to the conclusion that the port is the year of the Congress of the CPSU (or its early forms), and they are “waiting for us” at the 1903rd port. corresponding to the date of the next congress. It is also easy to find the dates of the CPSU congresses:
Now we are making a move to the correct port, and we get a response from the server encoded using Base64. After decryption, we get a dump starting with the string "% PNG", and we understand that this is a PNG image. We open the image - and here it is, Pac-Man!
It remains only to pass the game! After passing, we get a response from the server with the key:
7 — В чащах юга жил бы цитрус? Да, но фальшивый экземпляр!
The most difficult task (only AV1ct0r completed it), requiring reverse engineering knowledge, the basics of cryptography, DEP and ASLR bypass technologies, and the ability to exploit binary vulnerabilities. Who wants to delve deeper - in the May issue of "Hacker" a large and detailed article on its passage.
The participant was provided with the following files:
1. atl110.dll;
2. NeoQuestDocument.docx;
3. NeoQuestActiveX.dll.
ActiveX is loaded in the NeoQuestDocument.docx document and the startup result is Decryption Error.
The ActiveX module, implemented in the binary file NeoQuestActiveX.dll, contains a vulnerability in the setter of the EncryptedTextBlob property that can be exploited and which will allow arbitrary code to be executed on the user's machine.
As a result of reverse engineering of NeoQuestActiveX.dll, we obtain the following algorithm for the setter of the EncryptedTextBlob property of the ActiveX component of NeoQuestActiveX.dll: Let us
explain a little the algorithm for working with words, in conjunction with the picture, this should clarify the action plan.
When the EncryptedTextBlob property is set, the setter is called. A string is passed to it, which, in turn, is decoded from Base64. Next, the resulting byte array is divided into segments and the first two bytes containing the length of the second segment are taken. Then, the second segment is copied to the 16-byte stack buffer. This is where the Word error and crash occurs if the length is specified more than 16. Using the memmove function, the memory is copied without checking the number of bytes copied.
Then, in the case of the normal course of the program, the second segment of bytes is taken and parsed as the serial number of the certificate. The certificate store with the specified serial number is searched in the certificate store. And in case the certificate is found, the third segment is decrypted on it using the CryptDecryptMessage function and as a result of this we should get the key for passing the task.
From the foregoing, we conclude that we need to install a certificate on the system on which the key was encrypted. After that, when opening the NeoQuestDocument.docx document, we will see not the “!!! Decryption Error !!!”, but the key you are looking for.
Where to get the certificate? The task is given a server. Except from there, there’s nowhere else to take.
At this step, you can already fully understand the strategy for completing the task:
1. Create a document that exploits the vulnerability in NeoQuestActiveX.dll and performs a payload in the form of downloading the desired certificate;
2. Upload it to the server specified in the task (the task says: “resource 213.170.102.198 on which it is installed”, which means the exploit should work there);
3. Download the certificate;
4. Install it on your car;
5. Open the NeoQuestDocument.docx document and get the decrypted key for passing the task.
Let's move on to exploiting the vulnerability. The WINWORD.exe process includes permanent-DEP and ASLR. For only one ASLR module is disabled - NeoQuestActiveX.dll. To circumvent these restrictions, it is necessary to overfill the buffer by rewriting the return address, which in turn will be the first ROP gadget in the program. As a result of the execution of the ROP program, the memory with the shellcode (stack) should become executable, and we will proceed to the execution of the shellcode.
To simplify the construction of the ROP program, we will use the Immunity Debuggerand python script mona.py. Running mona.py gives an approximate ROP chain. Immediately after the ROP program, payload follows. As a payload, we use shell_reverse_tcp (only it is suitable, because all ports are filtered on the server and only port 80 is open), while you must have an external IP address or use hosting. We generate the payload using the same Metasploit.
We load the docx-generated document onto the server, get the payload “off” to the Metasploit’s console, download the certificate and password for it, install it in our certificate store and open the NeoQuestDocument.docx document. Before us is the key to passing the mission. Victory!
And then - this is the main thing ...
Soon, the winners will meet in a fight on the in-person NeoQUEST round under a single noble goal - to stop the missile, which they themselves launched (by chance). So, dear hackers, we crawl out of the ground and begin to look into the sky, looking for signs of an approaching rocket.
If you are interested in information security, and it doesn’t matter if it’s your hobby or job, we are waiting for you on the NeoQUEST-2014 full-time tour on July 3 in St. Petersburg! Free admission! At the event, it will be possible to observe the battle of our participants, take part in interesting hack contests (and leave with presents!), Listen to fascinating reports from the practice of cybersecurity, chat with colleagues and just have fun! Follow the news on our website !