Continuing from the last post of ActiveX vulnerability this post will walk through another ActiveX vulnerability within the JCom Obj Mgr2 control. This control is prone to a buffer overflow vulnerability which can be remotely exploited by a malicious user. The vulnerable method within the control is the "RemoveBandFile" method. This method takes one argument as the input and deletes the specified file that is provided from the system32 directory. That itself is a bit of worry because there is no checks that are implemented to verify what file the method is deleting.
Quickly we load Internet explorer into Ollydbg and pass the html exploit file as the argument. There are lot of POCs available on the internet for this particular vulnerable version of Jcom. Hence this post stays away from exploiting the vulnerability but will expose the actual code that is responsible for this vulnerability. Below is the sample html file which is crafted and fed as an argument to Ollydbg.
arg1=String(500, "A")
target.RemoveBandFile arg1
We pass excessive lengths string as argument to the vulnerable function to trigger the vulnerability. The length of arg1 argument is read by the control. As seen in the figure below the argument length can be seen returned in the EAX register. 500 dec = 1F4 hex
Quickly we load Internet explorer into Ollydbg and pass the html exploit file as the argument. There are lot of POCs available on the internet for this particular vulnerable version of Jcom. Hence this post stays away from exploiting the vulnerability but will expose the actual code that is responsible for this vulnerability. Below is the sample html file which is crafted and fed as an argument to Ollydbg.
arg1=String(500, "A")
target.RemoveBandFile arg1
We pass excessive lengths string as argument to the vulnerable function to trigger the vulnerability. The length of arg1 argument is read by the control. As seen in the figure below the argument length can be seen returned in the EAX register. 500 dec = 1F4 hex
The program flow then gets onto the vulnerable part where the strcat function is called. As an overwhelmingly large amount of input was provided the stack is overflown and parts of the stack is overwritten by the value that we have provided as argument. In this case 41414141.
As shown in the figure you can see that the argument that is passed to the method was initially concatenated with the System Directory path and then the resultant data is passed onto the DeleteFile function to delete the file. Malicious users can take advantage of this and can overwrite the stack with the address of their choice to redirect the control of the program to their liking.
When the program tries to return from that particular function it will pop the top of stack to EIP thereby redirecting the flow of the program.
binaryhax0r
No comments:
Post a Comment