Somethings kept me busy lately which was why there weren't much of a update in here. But I thought of just putting this across in spite of it being a very old topic. This blog will discuss about a buffer overflow vulnerability in the ActiveX control of AOL IWinampActiveX.
The vulnerable method within the control is the ConvertFile(). It takes 6 parameters out which the 1st parameter is prone to buffer overflow. When a overwhelming data is passed to the first parameters it results in overwriting the SEH handlers. It's a classic exploit which first creates an exception and when the exception returns to the SEH handler it will branch to the address that we have already overwritten. We craft the 1st element to contain 1400 bytes of 0xFF's and then a 1000 of 0xOC's. This is done because the first 0xFF will help us in making the exception and when the exception occurs the control would return to the already overwritten SEH handler address with 0x0C's. Without further delay I will walk you through debugging this vulnerability.
The above code when executed overwrites the buffer with 1400 0xFF's followed by 0x0C's. When this is done, at some point in the code the data from the buffer is loaded into [EAX] and is compared with 9 - which is where the exception occurs. As the data in the buffer is flooded with 0xFF's EAX was also loaded with 0xFFFFFFFF. When comparing [EAX] which is [FFFFFFFF] an exception occurs. We can witness this in the debugger.
Structured exception handling is best explained here. In my own words when there's an error in the program the control of the program would be passed to a flow where it tries to rectify the error or terminate the program gracefully. In our case when there's an exception that occurred in our program it tries to find the SEH and jump to that location for the exception to be handled.
The exception in this case is handled by the OS. So when windows found the exception it calls the exception routine that handles the exception. As you have guessed it right the SEH was earlier overwritten with 0x0C0C0C0C the control of the program is transferred to that address. From below we can see that the SEH is being pushed into the stack. We earlier saw that SEH is at address 0013E574. As we have even overwritten data base 0013E574, [EBX+4] also has the value 0x0C0C0C0C.
Later down the line the address that was pused into the stack is popped into ECX and it been called. This ultimately changes the flow of the program which leads into the heap. We have already sprayed the heap with our shellcode, so everything went right in our case which results in the execution of the shellcode.
Thus the "call ecx" statement will take us to the heap resulting in shellcode execution ;)
The vulnerable method within the control is the ConvertFile(). It takes 6 parameters out which the 1st parameter is prone to buffer overflow. When a overwhelming data is passed to the first parameters it results in overwriting the SEH handlers. It's a classic exploit which first creates an exception and when the exception returns to the SEH handler it will branch to the address that we have already overwritten. We craft the 1st element to contain 1400 bytes of 0xFF's and then a 1000 of 0xOC's. This is done because the first 0xFF will help us in making the exception and when the exception occurs the control would return to the already overwritten SEH handler address with 0x0C's. Without further delay I will walk you through debugging this vulnerability.
bof=string(1400,unescape("%ff")) + string(1000,unescape("%0c")) IWinAmpActiveX.ConvertFile bof,1,1,1,1,1 |
The above code when executed overwrites the buffer with 1400 0xFF's followed by 0x0C's. When this is done, at some point in the code the data from the buffer is loaded into [EAX] and is compared with 9 - which is where the exception occurs. As the data in the buffer is flooded with 0xFF's EAX was also loaded with 0xFFFFFFFF. When comparing [EAX] which is [FFFFFFFF] an exception occurs. We can witness this in the debugger.
We can also see that the address of the SEH has been overwritten.
Structured exception handling is best explained here. In my own words when there's an error in the program the control of the program would be passed to a flow where it tries to rectify the error or terminate the program gracefully. In our case when there's an exception that occurred in our program it tries to find the SEH and jump to that location for the exception to be handled.
The exception in this case is handled by the OS. So when windows found the exception it calls the exception routine that handles the exception. As you have guessed it right the SEH was earlier overwritten with 0x0C0C0C0C the control of the program is transferred to that address. From below we can see that the SEH is being pushed into the stack. We earlier saw that SEH is at address 0013E574. As we have even overwritten data base 0013E574, [EBX+4] also has the value 0x0C0C0C0C.
Later down the line the address that was pused into the stack is popped into ECX and it been called. This ultimately changes the flow of the program which leads into the heap. We have already sprayed the heap with our shellcode, so everything went right in our case which results in the execution of the shellcode.
Thus the "call ecx" statement will take us to the heap resulting in shellcode execution ;)
No comments:
Post a Comment