Windows XP local search function vulnerability OVERVIEW : When invoking the local search funcion in windows XP via the taskbar START button, XP downloads a series of XML pages from sa.windows.com and displays them. This function is vulnerable to a redirection attack, to pull down rogue XML pages from antoher server if the server is configured correctly. Normal Operation : User clicks on START then SEARCH. The local search program starts, and makes a connection to sa.windows.com and attemps to http get the files balloon.xsl & lclsrch.xml from the directory /sasearh if they have been modified since the last modification date of the local versions of these files, located at c:\windows\srchasst\mui\0409. ================================================= Frame 8 (185 bytes on wire, 185 bytes captured) Internet Protocol, Src Addr: 192.168.xx.yy (192.168.xx.yy), Dst Addr: 207.46.248.249 (207.46.248.249) Transmission Control Protocol, Src Port: 1032 (1032), Dst Port: http (80), Seq: 1, Ack: 1, Len: 131 Hypertext Transfer Protocol GET /sasearch/balloon.xsl HTTP/1.1\r\n If-Modified-Since: Fri, 19 Mar 2004 22:34:02 GMT\r\n User-Agent: SCAgent\r\n Host: sa.windows.com\r\n \r\n Frame 10 (185 bytes on wire, 185 bytes captured) Internet Protocol, Src Addr: 192.168.xx.yy (192.168.xx.yy), Dst Addr: 207.46.248.249 (207.46.248.249) Transmission Control Protocol, Src Port: 1033 (1033), Dst Port: http (80), Seq: 1, Ack: 1, Len: 131 Hypertext Transfer Protocol GET /sasearch/lclsrch.xml HTTP/1.1\r\n If-Modified-Since: Fri, 19 Mar 2004 22:38:34 GMT\r\n User-Agent: SCAgent\r\n Host: sa.windows.com\r\n \r\n ================================================= Example exploit : User clicks on START then SEARCH. The local search program starts, and makes a connection to sa.windows.com, which is redirected to another server via a entry in c:\windows\system32\drivers\etc\hosts. The other server has a directory structure in place that mimics the one at sa.windows.com and pulls the correctly named files, but with rogue xml content. In the POC sa.windows.com was redirected to a web server at 205.xx.yy.zz ================================================= Frame 7 (185 bytes on wire, 185 bytes captured) Internet Protocol, Src Addr: 192.168.xx.yy (192.168.xx.yy), Dst Addr: 205.xx.yy.zz (205.xx.yy.zz) Transmission Control Protocol, Src Port: 1037 (1037), Dst Port: http (80), Seq: 1, Ack: 1, Len: 131 Hypertext Transfer Protocol GET /sasearch/lclsrch.xml HTTP/1.1\r\n If-Modified-Since: Tue, 29 Mar 2005 22:01:15 GMT\r\n User-Agent: SCAgent\r\n Host: sa.windows.com\r\n \r\n No. Time Source Destination Protocol Info 11 0.223024 205.xx.yy.zz 192.168.xx.yy HTTP HTTP/1.1 200 OK (text/xml) ... Line-based text data: text/xml \357\273\277 \t \t\t<Text><![CDATA[What do you want to Red Team for?]]></Text> \t ================================================= See attached file proof.jpg for the rest. Currently this exploit works only if the local versions of the xml files are deleted. While the packet capture indicates that the files are downloaded, they do not replace the existing local versions. It is possible that some form of server identification check is failing. I'm working on this part. In theory XML code could be created that incorporates any number of payloads. Further, if a firewall / router was compromised to redirect sa.windows.com an entire network could be compromised with little effort, and less visibility. The rest I leave up to your imagination.