Microsoft Jet Engine MDB File Overflow Vulnerability

Text/GraphWhen I first saw an announcement on this vulnerability on the internet, I heard a constant debate in my ears because it was a vulnerability that has been prevalent for nearly a year, who discovered the vulnerability, and whether the publisher and the vulnerability discoverer are one person has become a topic of debate. Right or wrong. I believe everyone can still see this in the security field. I hope I can share my words with you-we will only talk about technology! Aside from this, let us go back to the topic. Since this vulnerability has been published, I believe those who are brave enough to get the mdb file that can bring up a calculator, but how can a simple calculator no longer meet our increasing "material and spiritual" needs? I often see some posts in some security forums asking how to modify the mdb file so that it can execute other programs or change its own ShellCode to this mdb file? No matter what the purpose is behind these issues, it requires a certain technical level to understand how to modify ShellCode. If you have noticed previous gyzy articles, you will know how this technology uses published POC to build our own exploit. The first thing we need to do is to analyze the cause of Microsoft Jet Engine MDB File Parsing Stack Overflow, find the method to trigger the vulnerability, and then add our ShellCode. Now that we have a clear idea, let's start this analysis journey. The published POC is actually an exploit, but the details of the vulnerability are not very clear, so it is difficult to trace the cause of the vulnerability triggering. When I use UltraEdit32 to open this mdb file, the first idea I have created is to see if I can find the ShellCode that can execute the calculator. Why? My idea is that, since the details about this vulnerability are vague, the results obtained by using Baidu are simply one that uses the mdb file. I have no specific reason for this, however, based on the general principle of using Stack Overflow, you can either fill the stack space with a long string to the return address of the function, and then use a jmp (Register) the command address overwrites the return address of the function, followed by SshellCode. This method mainly uses the Register to point to the subsequent shellcode, and its form in memory is similar to figure 1. Figure 1 now, as long as we find ShellCode, change the value of the jmp (reg) command address to an address that generally does not exist, such as 66666666, opening the POC file will cause a program error. Then, you can use the debugger to view the program error and find the address when the program overflows. In another case, the exploitation of stack overflow can be obtained through SEH chain overwrite, which is mainly used when some stack data is overwritten to cause damage to the program, the principle is similar to the trigger method above, but the address to be overwritten is not the return address of the function, but the exception handling function address of the SEH chain. Once a program overflow error occurs, the system will execute the exception processing function, and the function address has been controlled by us to execute the ShellCode we want. In any case, as long as we find ShellCode, it is not far from finding the cause of overflow. In UltraEdit32, click the shortcut key Ctrl + F. In the "Search" dialog box, enter "calc" in the search content. The reason is that the calculator program name is: calc.exe. The published mdb file can be used as a calculator. The ShellCode must contain the name of the calculator, unless it is ShellCode encryption, sentence breaking, dubyte, or the database itself is encrypted, in this way, you have to spend some time searching. After clicking search, we found this character, as shown in 2.: Figure 2 The ShellCode section is very familiar, because I have written ShellCode, so I still know some of it. Now we have found ShellCode, so we should find the key value that overwrites the returned address or SEH. As I have analyzed earlier, no matter whether it is overwriting the return address or SEH, as long as the ShellCode is found, it is not far from these addresses. Only by modifying the data used to overwrite the address can we re-trigger a program error to analyze the cause of the overflow vulnerability. By stripping the ShellCode of the calculator, I found that there was a piece of number that was very suspicious. Its value was 1B0D4C42, which really had nothing to do with ShellCode. I tried to change it to FFFFFFFF, save the modified mdb file. When ACCESS2003 is used to open the file, the ACCESS2003 program disappears instantly, but the calculator does not appear. Will this tell us that the modification just now has accurately found the place where overflow occurred? Open the Ollydbg program, use it to open the ACCESS Program, run F9, and select a file in the opened ACCESS to open the mdb file we just modified and saved. Then the Ollydbg stops, as shown in 3. Figure 3 have you noticed the error code in the figure? It looks like an unusable write error. Never look at the vulnerability you want to analyze in such a simple way. In fact, this is a very typical function implementation code similar to strcpy, ecx controls the number of string copies. We can see that the content in ecx is assigned by edx, that is, 0x5200. See the register window on the right. Convert the number to decimal and the result is 20992. If the destination address space is not allocated enough, a write error will inevitably occur for so many times that the string is moved cyclically. Now that we finally find the stack space overflow error, a new problem arises. Do we need to overwrite the return address of the function? Or overwrite the SEH chain to get the ShellCode Execution permission? Taking a closer look at the stack overflow error, we can assert that the POC publisher uses the SEH method to obtain the ShellCode Execution permission. As we can see in the debugging of Ollydbg, when the modified mdb is used for testing, the Ollydbg program captures a memory write error, which will actually cause an exception, if it is an overwrite function that uses the returned address, the Olympus g captures an error in reading a specific address, because the value of the EIP register will be modified. Since an exception occurs, the exception can only be handled by the exception processing function on the SEH chain. Therefore, to control the program after the overflow, the exception processing function must be intercepted. To prove my assertion, I used Ollydbg again to debug the result of this overflow and chose to view the SEH chain, as shown in 4. Figure 4 have you seen the content of the SEH chain? It is the data we suspected just now. Through the above step-by-step analysis, we now know that the overflow of this mdb File uses the method covering SEH to obtain the permission to execute ShellCode, so why does the POC author use the 1B0D4C42 address to overwrite the SEH chain of this overflow? Let's further analyze it. First, the address 0x1B0D4C42 exists in the msjet40.dll file. We can see this in the above figure. At the same time, the file with overflow problems is actually the file, because mdb databases are parsed by Microsoft Database Engine files. Let's use Ollydbg to see what the code at this address is, as shown in Figure 5. Figure 5 shows that the original code at address 0x1B0D4C42 is a "call [ebp + c]" command. That is to say, after the overflow occurs, use the SEH chain, the program will be executed with the call command at 0x1B0D4C42. In this way, once the content of "ebp + c" is an address pointing to the ShellCode that we can control, we can successfully obtain the right to execute arbitrary code. Is this the case? In Ollydbg, let's check the content of "ebp + c", as shown in 6. Figure 6 do not have to say anything after reading this picture? The content of "ebp + c" is 0013e25c. After you type 0013e25c in the memory window, we can see that the code containing ShellCode after calc is found in UltraEdit32. At this point, we finally understand the idea of POC authors using this vulnerability. By covering the SEH chain, the [ebp + c] content is a location in the mdb file where we can modify the content, to obtain the permission to execute ShellCode. In general, this vulnerability about Microsoft Jet Engine MDB File overflow is relatively simple, but the POC author is very skillful in using ideas. We should take a look at this idea. At the same time, I found that this overflow vulnerability still requires the version of the msjet40 file. The msjet40 file I tested is 4.00.8618.0. Next let's talk about the ShellCode modification method. Use any hexadecimal editing software to open the mdb file provided with the article and find the location of the Offset file 0x3336 and start to replace it. After that, there is another question that everyone is most concerned about. What benefits does this vulnerability bring to us? In addition to remotely deceiving users to directly access this mdb file and trigger the exploitation of the vulnerability, the same Microsoft Jet Engine Overflow vulnerability has appeared before, we can use WebShell to first upload the modified mdb using the file, and then write a simple section through ADODB. connection opens the script file of the mdb file. Calling this script file triggers a local overflow, so as to gain the opportunity to escalate permissions on the remote server. So far, someone has released a vulnerability exploitation tool with the bounce function on the Internet. In this way, once we call this mdb File in WebShell, you can get a remote Shell. It can be said that this vulnerability has found a new way for those who suffer from WebShell privilege escalation.