Re: Microsoft ISA Server Vulnerability

[Microsoft Security Response Center]

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                 push    edi
.text:0101D729                 mov     edi, eax
.text:0101D72B                 mov     eax, [eax+4]
.text:0101D72E                 push    esi
.text:0101D72F                 mov     [eax], ecx
.text:0101D731                 mov     [ecx+4], eax
.text:0101D734                 call    ds: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!