Results and analysis of tasks online tour NeoQUEST-2014

It is time to sum up the online tour NeoQUEST-2014, including:
- parse all 7 tasks of the quest (for each day of the week!);
- tell about the winners and their awards;
- to tell what awaits the participants and guests of the event in the on-site tour NeoQUEST-2014, which will be held on July 3 in St. Petersburg at the Polytechnic University.

About the winners

"Gold", "silver" and "bronze" online tour received AV1ct0r, n0n3m4 and Dor1s, respectively. The fight for the first place was very hot, for three days the leader was constantly changing - AV1ct0r and n0n3m4 pulled the first place from each other, and the difference between them was only a couple of points. But then AV1ct0r passed the task about the “fake citrus” and strengthened its leadership, breaking the lead by 113 points! We cannot fail to note the will of n0n3m4 to victory and his undoubted talent (he completed the second most difficult task of the quest). The “bronze” prize-winner of Dor1s did not lag far behind the second place, but it realized a big lead over the following participants.

Congratulations to the winners, they are waiting for the main prizes and a full-time tour, a victory in which will bring the winner a trip to one of the international hacker conferences! AV1ct0r and n0n3m4 are awarded with smart watches from Samsung and Sony (and here is another interesting review on Habré), respectively, and Dor1s gets almost a three-kilogram robot , which is also not stupid! By the way, all those who have completed at least one NeoQUEST-2014 task are also waiting for a small prize. Since the standard ideas of memorable souvenirs (cups, notepads, flash drives, pens, chocolates, etc.) have already been exhausted, our souvenir will surprise the participants, but most likely, sooner or later they will use them! We contact all winners. Dear participants, check your mail for the presence of letters from info@neoquest.ru!
')

Analysis of tasks

NeoQUEST-2014 consisted of 7 tasks from various cybersecurity areas:
1) “I don’t 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) “Freezed Computer” - getting the virtual memory of a virtual machine from a RAM dump;
5) “Unknown smoking device detected” - analysis of a USB sync dump of an Android phone with a computer;
6) “Igodrom” - use port knocking to play Pac-Man;
7) “Would citrus live in the thicket of the south? Yes, but a fake instance! ”- 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 “Unknown smoking device detected”, “Igodrom”, “Citrus would live in the thickets of the south” will be discussed in detail in the May issue of the Hacker magazine. In addition, our participants wrote a sufficient number of writeup'ov, in which you can read, as they went through this or that task. Here is a writeup from AV1ct0r, here from n0n3m4 and from Dor1s.

1 - I don’t understand yours

The task was based on a technology that allows embedding C # applications into Internet sites. Perhaps this is only if the site is written in asp.NET. True, there are certain limitations. Only Internet Explorer will be able to display the graphical shell of the applet, other browsers can only use the functions it exports.
From the entire source data, the quest participant received only the IP address of the site, upon transition to which the following 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 enters 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 push the quest member to think 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 results in the desired result. The participant is shown another version of the site with the task:



The user is presented with a form for data entry, but what should be entered there? That is the question. To do this, you need to delve into the source code of the page, then such an interesting piece is revealed:



The source of the page explicitly indicates the path to the C # applet. But, as mentioned above, it is not displayed in any browsers except Internet Explorer. This is what a site in IE looks like when using a proxy server:



However, the task execution does not affect the display of the graphic part of the applet. The buttons in its interface do not carry any payload.
The further task of the participant is to study the source code of the applet. Applications written in C # are fairly easy to decompile. For example, you can use the .NET Reflector application. Get the applet source code:



In a decompiled application, it is easy to find a class with the speaker name KeyStore. It contains the key that must be entered into the form on the site.
By the way, the key verification function is implemented in the applet as well. Using asp.NET, it is invoked and checks the input information for correctness. This functionality works in any browser. Task completed!

2 - Hasta la vista

In the task, the participants received a certain file MyGreenManController.zip, when opened, it became clear that this is nothing more than an Android application (yes, in fact, the file name suggested):



Participants needed to reverse this file. This required to know what is an application 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 defines the application rights, its name, etc., and the classes.dex file. The latter is a byte-code compiled for the Dalvik virtual machine used in Android. Getting the java source code out of it just won'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, because there is another, simpler and more convenient, which consists in converting a dex-file into a jar, which can be decompiled and get quite readable java code.

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 study 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, the path to the application is recorded in the aA variable (and yes, the same type of method and class names were made solely to confuse the quest participants):

 Code.aA = Code.this.getApplicationContext().getFilesDir().getAbsolutePath(); 

Then the variable str is written to the result of executing method a from class AA.
Method a is simple to the 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 in 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 string like:

 «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 the 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 be in the files folder of our application. Due to the fact that you can get this file on your phone only 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? This question will be answered by the Code class. After downloading the file, the class A method 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, it takes the phone ID and checks it for the line "352276054393855", and the carrier ID checks for the line "25001" and adds these strings 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 generated string. This method considers hash using the MD5 algorithm:

 String str = aaaa(localStringBuffer.toString()); 

Next, the aa method with the parameter is called — the first 16 bytes of the resulting hash:

 aa(localStringBuffer.toString().substring(0, 16).getBytes()); 

The aa method decrypts the downloaded neoquest_2014 file with the key consisting of the first 16 bytes of the same hash, and writes the result 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, participants had to download the file to a computer (or from a phone, for lovers of perversions), and then restore the key and decrypt the downloaded file.

3 - TimeShift 2. Revenge

The task from the in-person tour NeoQUEST-2013, then no one could pass it. We finalized it for an online tour, and this time many have coped with it.
From the legend, we have two IP addresses with a port (213.170.102.196:4001, 213.170.102.197:4002) and a key B4365F2.
Having established a connection with the first server and sending arbitrary data (for example, the netcat program), 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 format of the expected message and debug information. The server expects to receive a client hello message: {0x16, 0x01, 0x00, 0x01, 0x01}. Of the 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 performs the role of the server, the second - the client. By sending their messages to each other and analyzing the 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 the NEOSSL_KEY_EXCHANGE message, containing the AES-128 session key encrypted by the server's public key.
4. The server responds with NEOSSL_FINISHED.
5. The client sends 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 to send 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 step 5. 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 one. Practically nothing is known about AES encryption (the key is different each time, the message probably also varies, and its content is unknown). So, you need to hack RSA.

You must obtain the server private key. There is a server certificate (containing the public key) and access to the encoder (in step 3, the client sends the data, which the server decrypts and interprets as a session key).

Among the attacks on RSA there is an interesting class of attacks associated with the implementation of encryption. We are most interested in the attack on the execution time, because the debug information contains the time that the server spent on decrypting the message (and also the name of the task hints!). Another thing about encryption is that it uses Montgomery multiplication to increase encryption speed.
To unlock the secret key, you can use the attack described in the Harshman Singh article " Timing Attacks on software implementation of RSA ". The attack allows you to calculate one of the factors of the module n. Opening the multiplier is performed bit by bit, starting with the higher bits. For opening, requests generated from the current known value of the module are sent to the encoder and the time difference is calculated in case 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 with this need to guess. 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 debug information says that the AES zero initialization vector is used. Here is the message 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 task - B4365F2. You need to encrypt the string "B4365F2: Connect" using the session key and send it to the client. Deciphering his next answer, we get a hash - f9e8ceee19e980bd68e3193d6d0de2d3, this is our key. Task completed!

4 - Freezed computer

This task was devoted to the analysis of data dump memory, which was issued to participants in the form of a file size of 1GB. 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 started running under the Oracle Virtual Box. The scheme of the task looked like this:



Both virtual machines were running the same versions of Windows 7, so the memory dump had two operating systems at the same time, the memory pages of which were heavily scattered across the dump. NeoQUEST participants were required to find the key in the dump. The presence of two virtual machines and the determination of their types was found quite easily by analyzing all the text strings in memory. It is interesting to note that when using CMAT on the dump given to the participants, the program refused to work normally, while the Volatility Framework successfully coped with its work and found two operating systems at once.
The winner of AV1ct0r used the Volatility Framework to solve this assignment, about which he wrote in detail in his blog. Another feature of the NeoQUEST task was that the key that participants needed 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 problem, because the RAM and the video memory of the Virtual Box are jammed simultaneously 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 in it using the virtual address found in the logs and making a picture of it. Getting the dump process was carried out by him with the help of the Volatility Framework. Here is an algorithm for solving a task with getting the video memory of the Virtual Box virtual machine and generating a picture from it using the video memory mapping into the physical memory of the VMware virtual machine.



Step 1. Get all the readable strings 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 learn that the Virtual Box virtual machine is running and we get a piece of the log from its launch with more detailed and necessary information:

 :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 <string> = "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 configures EPT (Extended Page Tables) tables, which are then used by the processor to convert the physical addresses of the virtual machine to the physical addresses of the host machine. In our case, the physical addresses of the Virtual Box virtual machine are offset in the dump file. To learn more about the EPT format (and about the fact that it corresponds to PML4), you need to read the processor manual.
The root table address is visible in the log and it is equal to 3dd8b000. Like any translation tables, they use only physical addresses that correspond to the absolute offsets in the dump file, so it remains to read the video memory, which is also located in the physical address space of the Virtual Box virtual machine and mapped using EPT.
Emulators of the VGA device (video adapter) use the host RAM to simulate the video memory for the virtual machine, and to directly draw the picture onto the screen, they simply copy the RAM into the host video memory periodically - just like the classic double buffering algorithm used in many graphics engines.
Step 3. Find out the physical address of the video memory for the Virtual Box virtual machine.
It is not in the dump, so in order to recognize it, it is enough to run the Virtual Box on your computer and see the value in the video adapter's tab (by the way, there is RAM in the dump):

 00:00:02.305353 VRamSize <integer> = 0x0000000001000000 (16 777 216, 16 MB) 

Step 4. Determine the format and size of the video image. In video memory, graphic data is stored in a specific format, which is similar to the usual BMP format: RGBXRGBX bytes in series ... 3 or 4 bytes per pixel. Screen resolution and bit depth we learn 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 the video memory from the dump. To do this, the program should parse the page tables in the specified range (starting from the physical address 0xE0000000 with the length of the picture size 800 * 600 * 4). 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 running the program, the following image is obtained:



Key found! As a result, the task can be solved without the use of CMAT and Volatility Framework, using knowledge about the video memory device and virtualization technology.

5 - Unknown smoking device detected

According to the legend, the participants had to figure out what kind of incomprehensible device they “synchronized with the laptop”, to get the key from a file of an unknown format.
AV1ct0r in his writeup determined that this file is nothing but a dump of the USB traffic of an Android device, and quite correctly noted that it is most convenient to work with it in a 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, look for a hint and find:



Information about the dates of birth was stored in a notebook, it began with VCARD, there were 4 pretenders for the role of wife. The question remained open: what should open this password? After a closer look at the dump, we find a file called look_at_this.7z. Google signature 7z files:

 37 7A BC AF 27 1C 

Then there is nothing but to get the archive out of the dump and sort through the 4 previously obtained birth dates. Inside the archive is a file win.txt with the key flag. Task completed!

6 - Igodrom

In this task, participants were required to play the good old Pac-Man , but in a special way, implementing a kind of port knocking .
Initially - it was necessary to guess that the server accepts requests only with a tag. By trial and error, using prompts from the server, coming from port 1898, the participant should finally receive this welcome message:

 <pacman gameid="7e09d6f13c5fd6086e3cc374e2bb8857"> <info message='Hello, Mr. Struve. Waiting for you at the next congress. Your move. Use action "newstep" and node <direction> [UP, DOWN, LEFT or RIGHT]</direction>; for step' /> </pacman> 

It turns out that they are waiting for us at some incomprehensible next congress. Now is the time to turn on the logic and put together piecemeal pieces of information:
- port 1898;
- Struve;
- congress.
Using the search engines, participants had to come to the conclusion that the port is the year of the CPSU Congress (or its earlier 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 receive 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-picture. 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:

 <pacman> <info message="You Win! Key is 584cc0bdfb44ac2dc00ec03ae6a5d937" /> </pacman> 

7 - Would citrus live in the thickets of the south? Yes, but a fake copy!

The most difficult task (it passed only AV1ct0r), which requires knowledge of reverse engineering, the basics of cryptography, DEP and ASLR bypass technologies, as well as 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 following files were provided to the participant:
1. atl110.dll;
2. NeoQuestDocument.docx;
3. NeoQuestActiveX.dll.

The NeoQuestDocument.docx document loads ActiveX and the result of the launch is Decryption Error.
The ActiveX module, implemented in the NeoQuestActiveX.dll binary file, contains a vulnerability in the EncryptedTextBlob property setter, which can be exploited and which allows to execute arbitrary code on the user's machine.
As a result of the reverse engineering of NeoQuestActiveX.dll, we obtain the following algorithm for the operation of the EncryptedTextBlob property setter of the NeoQuestActiveX.dll ActiveX component:



A little explain the algorithm of the words, in conjunction with the picture, this should clarify the plan of action.
When setting the EncryptedTextBlob property, the setter is called. It is passed a string, which, in turn, is decoded from Base64. Next, the resulting byte array is divided into segments and the first two bytes are taken, containing the length of the second segment. Then the second segment is copied to the stack 16-byte buffer. This is where an error occurs and Word crashes if the length is 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 is looking for a certificate with the specified serial number. And if the certificate is found, the third segment is decrypted with the help of the CryptDecryptMessage function and as a result we have to get the key for the task to pass.

, , . NeoQuestDocument.docx «!!!Decryption Error!!!», .
? . , .

:
1. , NeoQuestActiveX.dll ;
2. ( : « 213.170.102.198 », );
3. ;
4. ;
5. NeoQuestDocument.docx .

. WINWORD.exe permanent-DEP ASLR. ASLR — NeoQuestActiveX.dll. , , ROP- . ROP- () , .

ROP- Immunity Debugger' mona.py. mona.py, ROP-. ROP- payload. shell_reverse_tcp ( , 80- ), IP- . Metasploit'.

docx , «» Metasploit', , NeoQuestDocument.docx. . Victory!

— ...

NeoQUEST — , (). , , - , .

, , , — NeoQUEST-2014 3 ! ! , - ( !), , ! !