RE: Winhelp32 Remote Buffer Overrun
Correction, closing out of the app brings up an error where the memory read is controlled at 4141414d (EIP is elsewhere), so it appears to be a different type of crash by behavior entirely... but exploitable. Would need to stick a debugger on it and mess around to narrow it down. > -Original Message- > From: Drew [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, August 06, 2002 7:31 PM > To: 'Mark Litchfield'; 'Jelmer'; '[EMAIL PROTECTED]' > Subject: RE: Winhelp32 Remote Buffer Overrun > > > Running this on my local file fuzzer, Litchfield's begins to > hit exceptions at > 200 increments. (At a blank value it gives a memory error). > > At 216 increments (and at least for awhile, above) it > overwrites EIP with > 41414141. (Windows 2000 Service Pack 2). > > Testing Jelmer's as it was written below I ran to 10,000 > increments and did not find an issue. Testing to 10,000 with > .TIF as the extension did not find an issue. Testing these > same case tests with using the method > HHClick() as in Litchfield's does not give an issue. > > It may have been with another method, or perhaps some > interaction with the webpage. It may be the characters used > to bruteforce it. Perhaps, they were unicode (which I could > test, as well as anything else). > > > > > -Original Message- > > From: Mark Litchfield [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, August 06, 2002 12:24 PM > > To: Jelmer; [EMAIL PROTECTED] > > Subject: Re: Winhelp32 Remote Buffer Overrun > > > > > > If I am not mistaken, I believe that Microsoft are aware of > > this issue and have an IE patch comming out very shortly. My > > brother reported this to them, please see > > http://www.nextgenss.com/vna/ms-whelp.txt > > > > Regards > > > > Cheers, > > > > > > Mark Litchfield > > > > - Original Message - > > From: "Jelmer" <[EMAIL PROTECTED]> > > To: "Next Generation Insight Security Research Team" > > <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; > > <[EMAIL PROTECTED]> > > Sent: Thursday, August 01, 2002 5:19 PM > > Subject: Re: Winhelp32 Remote Buffer Overrun > > > > > > > I just installed servicepack 3 and the following code still > > crashed my > > > my IE6 with a memory could not be refferenced error. > > > > > > > > CLASSID="clsid:adb880a6-d8ff-11cf-9377-00aa003b7a11"> > > > > > > > > > > > > > > > > > > > > > > > > > I have been told this means it is most likely > exploitable. I am not > > > into buffer overflows myself though, maybe someone can > > confirm this. > > > Anyways I notified microsoft of this several months ago. > > The day after > > > I notified > > them > > > someone pointed me to the ngssoftware advisory *sob*, and I > > notified > > > microsoft that this was probably the same issue, last I heard from > > > them > > they > > > where looking in to if this was indeed the case. It's been several > > > months and as far as I know they are still looking. > > > > > > -- > > > jelmer > > > > > > - Original Message - > > > From: "Next Generation Insight Security Research Team" > > > <[EMAIL PROTECTED]> > > > To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > > > Sent: Friday, August 02, 2002 3:59 AM > > > Subject: Winhelp32 Remote Buffer Overrun > > > > > > > > > > -BEGIN PGP SIGNED MESSAGE- > > > > Hash: SHA1 > > > > > > > > NGSSoftware Insight Security Research Advisory > > > > > > > > Name:Winhlp32.exe Remote BufferOverrun > > > > Systems Affected: Win2K Platform > > > > Severity: Critical > > > > Category: Remote Buffer Overrun > > > > Vendor URL: http://www.mircosoft.com > > > > Author: Mark Litchfield ([EMAIL PROTECTED]) > > > > Date: 1st August 2002 > > > > Advisory number: #NISR01082002 > > > > > > > > > > > > Description > > > > *** > > > > > > > > Many of the features available in HTML Help are > > implemented through > > > > the HTML Help ActiveX control (HHCtrl.ocx). The HTML > Help ActiveX > > > > control is used to p
RE: Winhelp32 Remote Buffer Overrun
Running this on my local file fuzzer, Litchfield's begins to hit exceptions at 200 increments. (At a blank value it gives a memory error). At 216 increments (and at least for awhile, above) it overwrites EIP with 41414141. (Windows 2000 Service Pack 2). Testing Jelmer's as it was written below I ran to 10,000 increments and did not find an issue. Testing to 10,000 with .TIF as the extension did not find an issue. Testing these same case tests with using the method HHClick() as in Litchfield's does not give an issue. It may have been with another method, or perhaps some interaction with the webpage. It may be the characters used to bruteforce it. Perhaps, they were unicode (which I could test, as well as anything else). > -Original Message- > From: Mark Litchfield [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, August 06, 2002 12:24 PM > To: Jelmer; [EMAIL PROTECTED] > Subject: Re: Winhelp32 Remote Buffer Overrun > > > If I am not mistaken, I believe that Microsoft are aware of > this issue and have an IE patch comming out very shortly. My > brother reported this to them, please see > http://www.nextgenss.com/vna/ms-whelp.txt > > Regards > > Cheers, > > > Mark Litchfield > > - Original Message - > From: "Jelmer" <[EMAIL PROTECTED]> > To: "Next Generation Insight Security Research Team" > <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; > <[EMAIL PROTECTED]> > Sent: Thursday, August 01, 2002 5:19 PM > Subject: Re: Winhelp32 Remote Buffer Overrun > > > > I just installed servicepack 3 and the following code still > crashed my > > my IE6 with a memory could not be refferenced error. > > > > > CLASSID="clsid:adb880a6-d8ff-11cf-9377-00aa003b7a11"> > > > > > > > > > > > > > > > > I have been told this means it is most likely exploitable. I am not > > into buffer overflows myself though, maybe someone can > confirm this. > > Anyways I notified microsoft of this several months ago. > The day after > > I notified > them > > someone pointed me to the ngssoftware advisory *sob*, and I > notified > > microsoft that this was probably the same issue, last I heard from > > them > they > > where looking in to if this was indeed the case. It's been several > > months and as far as I know they are still looking. > > > > -- > > jelmer > > > > - Original Message - > > From: "Next Generation Insight Security Research Team" > > <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > > Sent: Friday, August 02, 2002 3:59 AM > > Subject: Winhelp32 Remote Buffer Overrun > > > > > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA1 > > > > > > NGSSoftware Insight Security Research Advisory > > > > > > Name:Winhlp32.exe Remote BufferOverrun > > > Systems Affected: Win2K Platform > > > Severity: Critical > > > Category: Remote Buffer Overrun > > > Vendor URL: http://www.mircosoft.com > > > Author: Mark Litchfield ([EMAIL PROTECTED]) > > > Date: 1st August 2002 > > > Advisory number: #NISR01082002 > > > > > > > > > Description > > > *** > > > > > > Many of the features available in HTML Help are > implemented through > > > the HTML Help ActiveX control (HHCtrl.ocx). The HTML Help ActiveX > > > control is used to provide navigation features (such as a > table of > > > contents), to display secondary windows and pop-up > definitions, and > > > to provide other features. The HTML Help ActiveX control > can be used > > > from topics in a compiled Help system as well as from HTML pages > > > displayed in a Web browser. The functionality provided by > the HTML > > > Help ActiveX control will run in the HTML Help Viewer or in any > > > browser that supports ActiveX technology, such as > Internet Explorer > > > (version 3.01 or later). Some features, as with the > WinHlp Command, > > > provided by the HTML Help ActiveX control are meant to be > available > > > only when it is used from a compiled HTML Help file > (.chm) that is > > > displayed by using the HTML Help Viewer. > > > > > > Details > > > *** > > > > > > Winhlp32.exe is vulnerable to a bufferoverrun attack > using the Item > > > parameter within WinHlp Command, the item parameter is used to > > > specify the file path of the WinHelp (.hlp) file in which the > > > WinHelp topic is stored, and the window name of the > target window. > > > Using this overrun, an attacker can successfully exectute > arbitary > > > code on a remote system by either encouraging the victim > to visit a > > > particular web page, whereby code would execute > automatically, or by > > > including the exploit within the source of an email. In > regards to > > > email, execution would automatically occur when the mail > appears in > > > the preview pane and ActiveX objects are allowed (This is > allowed by > > > default, the Internet Security Settings would have to be > set as HIGH > > > to prevent execution of this vulnerability
RE: EEYE: Macromedia Shockwave Flash Malformed Header Overflow
This is very similiar to one of the other crashes we have found. (Breaking into it reveals the same instruction as one of them). The current revision does not fix any of these other potentially exploitable crashes mentioned in the advisory. The difficulty is really in making these crashes exploitable. The one which we posted about was absolutely exploitable and which we wrote exploit code for. This involved running bit combinations of the header and built in stack tracing where key EIP changes were alerted and logged to a file. Since it is nearly impossible to crack 27 bytes with combinations between 00 and FF, we made some educated jumps at key junctures... over a period of several weeks. This said, running tests against other filetypes have revealed similiar issues which we are trying to find the time to fully work out. (The actual primary testing method does not involve so much of bit shifting as it does going through the file systematically, looking for memory write issues, so that every error condition might at least be caught). And, some filetypes are far more difficult to test in this automated manner than Flash. For instance, pdf files involve a lengthy loading of the slow running pdf module, and numerous office applications open outside windows which must be automatically closed... still not giving a solid oppourtunity to use the automated exception handler and debugger. Hopefully, in the not too distant future Macromedia will have all of these potentially exploitable conditions removed from their file type, as their software is exceedingly popular and would make for a very bad method of attack against users. > -Original Message- > From: Carlos Laviola [mailto:[EMAIL PROTECTED]] > Sent: Sunday, August 11, 2002 3:14 AM > To: 'BUGTRAQ' > Subject: Re: EEYE: Macromedia Shockwave Flash Malformed > Header Overflow > > > On Fri, Aug 09, 2002 at 05:44:27PM -0400, Mike Chambers wrote: > > The linux and solaris updates will be avaliable later today. > > > > You will be able to download it at: > > www.macromedia.com/go/getflashplayer/ > > I've downloaded this fixed version, but it seems to be > vulnerable to something I've discovered last week: if you > take a .swf and rot13 encode it (not all of it, so the > headers are not messed up), you can crash the user's browser. > I've tested it on Netscape 4.77 with Flash 4.0 r12 and > Galeon 1.2.5, which is based on Mozilla 1.0, with Flash 5.0 > r50 (both running on Debian unstable) and IE 6.0 (on Windows > 2000) and all of them crash instantly when I try to open the > rot13-garbled file. > > Check it out: > http://alternex.com.br/~claviola/sample1.swf (original) http://alternex.com.br/~claviola/sample2.swf (modified) -- Carlos Laviola <[EMAIL PROTECTED]>
RE: White paper: Exploiting the Win32 API.
> -Original Message- > From: Rothe, Greg (G.A.) [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, August 27, 2002 10:00 AM > To: 'Paul Starzetz'; Andrey Kolishak; [EMAIL PROTECTED] > Subject: RE: White paper: Exploiting the Win32 API. > > > All of this brings up a couple of questions for me: > > 1. > As I understand it, all this can be avoided by applying the > simple, longtime standard maxim of "trust no input," correct? (If > correct, this leads me to murmur rhetorically "Have today's > developers no discipline?") > > 2. > If the above is incorrect, The above is NOT correct as several posters have already shown. Anytime a developer has an application running as system which is a rare need, they must realize the security ramifications of what they are doing. (That, if a flaw is found in their software, they will elevate the privileges of the user). http://www.atstake.com/research/advisories/2000/a090700-1.txt This is a well known need, even if this type of attack - and therefore prevention - is not well known. > and system messages such as event > notifications (onClick, etc.) can be compromised, then developers > using tools such as Visual Basic are essentially helpless to > harden their applications. Other than going back to writing in > assembly, what is the modern developer to do? > You generally will have very few types of applications on your system which require to run *as* system and can receive messages (Most that I can think of are actually security apps that are designed to restrict unprivileged users -- but maybe I am biased). While you can exploit other applications not running in a higher privilege space in this manner, this gains you nothing which you can not do with just running an binary as that user. > > We have here an exclusive or: Which is it - 1 or 2 or neither? > > Thanks, > > -Greg
ICQ Buffer Overflow Exploit
Buffer Overflow in ICQ OS tested on: Windows 2000 ICQ version: 99b 1.1.1.1 ICQ is a very popular chat client that is affected by a exploitable buffer overflow when it parses an URL sent by another user. What this means: * one, arbitary assembly code can be run on the remote machine. (Therefore, a shell could be spawned, a trojan executed, or perhaps easiest of all the hard drive could be wiped.) * two, this did not take very long to find, and generally, if there is not bounds checking in one place, then there is not going to be bounds checking in other places as well. While ICQ is not likely to be run on a "hub of commerce" server... it is run on millions of systems, and someone could use a script to spam these millions of systems with such an URL... from there a timed distributed network attack could be launched. (Timed because of the dynamic IP's). When sending a URL link through a message in ICQ, it is possible to overflow the buffer and control the instruction execution. http://www.yahoo.com/sites.asp?·P ! The exclamation marks are where EBP is overwritten. The four characters after that are where EIP is overwritten. This link puts a jump esp into the EIP, bringing the flow of execution back into the buffer to the place right at the end of the URL, after the last NOP's after the EIP. Tested on w2k final beta. So, basically, you just tack the exploit code onto the end of the URL above, and the machine will run it. It should be pretty easy to jump the stack as well. Some characters are not allowed, making this slightly more difficult. ",", opcode 2C is not allowed, "]"'s are not allowed, and opcode "01" is not allowed. Pretty much anything else is. Explicit example: You click on someone in your ICQ to send them a message, you cut and past the above code into the message. When they receive and click on the link to jump to the location the exploit code tacked onto the end would be executed. To tack the exploit assembly code on there, write it up, asssemble it... get the opcodes, then use something like UltraEdit32 to paste the binary characters onto the end of the URL. Such code may be pieced together from freeware assembly scripts and etc. Fix: Don't accept communication with people you don't know. Test your software yourself for bugs, especially under Windows where incidents are not likely to quickly end up in CERT or similiar places. Drew alternative email: [EMAIL PROTECTED] __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
Re: Security information for dollars?
It would be interesting to see how many of the bugs in BIND have been found by Whitehats and how many have been found by Blackhats. Any bug that has been found by a Blackhat should be made public instantly, because by the time Whitehats find out about the bug, it is already being used. IMHO, all bugs should be released disclosed ASAP, and waiting for some vendor to fix their version is just plain wrong. 1. My Company runs Company A's BIND implementation. 2. A bug is found that affects all versions of BIND. 3. BMF notify their members, and give them 2 weeks to fix before the annoucement. 4. Company A fix their implementation immediately, but can't make an announcement because of BMF rules. 5. I know nothing about the bug so do nothing. 6. My Company gets hacked using an exploit for the bug. 7. We spend lots of time recovering from the hack. 8. BMF finally give the ok for the announcements. 9. My Company installs the fixed version that was "available" before we got hacked. 10. In the tradition of the good old USA we start a class action law suit and sue the pants off of the BMF, Members, and the ISC. Drew. >One - just ONE - of the features suggested - only suggested - for the >BIND Members Forum (BMF) is that members get advance warning of >security problems. This is not unreasonable given that members are >likely to be folks running root, gTLD and ccTLD name servers or >vendors who have to prepare and ship security patches to their >customers. Or do you think that critical Internet infrastructure >should just take their chances that the script kiddies don't get to >them first? Another membership constituency are the companies who >build products on top of BIND. They need time to incorporate any >security fix too. Many of them were taken by surprise by Monday's >announcement.
Redhat 7 insecure umask
Problem: Users of Redhat 7 may have their umask set insecurely while acting as root. Severity: Medium/Low Description: The Redhat useradd script creates a group for the new user with the same name as the username by default. When the user logs in, any shell that uses /etc/profile will set the umask to 002 if the user's username and groupname match and their uid is greater than 14. If the user then issues su to become root without specifying the -l option the root account inherits the umask of 002. As root the user may then create files with somewhat insecure permissions. Redhat seemed to understand that system users should have a umask of 022, because /etc/profile will set the umask that way for users loging in with a uid less than 14, but they forgot about su. The offending lines in /etc/profile: ... if [ `id -gn` = `id -un` -a `id -u` -gt 14 ]; then umask 002 else umask 022 fi ... The fix: Get rid of the if-statement in /etc/profile and replace it with 'umask 022' (no quotes). Andrew Jones - Computer Science and Physics student at the University of Northern Iowa
RE: Bypassing Personal Firewalls
> -Original Message- > From: xenophi1e [mailto:[EMAIL PROTECTED] > Sent: Friday, February 21, 2003 1:34 PM > To: [EMAIL PROTECTED] > Subject: Bypassing Personal Firewalls > > > Here's a code snippet that injects code directly into a > running process > > without the need for a DLL etc. I believe that it demonstrates that > > process boundaries under NT mean very little within the context of a > > given UID. > I think it > illustrates > > that OpenProcess, ptrace, and the like should really enforce > filesystem > > priviledges on the processes they can modify. I think that this is > > something that needs to be done proactively. > > > > The implication of allowing processes to modify each other > this way is > > that PFWs can not be easily made secure, but also that > malicious code has > > nice support from windows for doing some very bad things. For > instance it > > would be a simple addition to intercept syscalls made by any > process into > > which code can be injected, and in so doing hide the presence of > > malicious activity from all local processes a user runs. (Sidenote: a number of previous apps used to test PFWs or Application Firewalls -- http://www.pcflank.com/art21.htm ) There are a number of ways to do this, you use the more popular method of openprocess and writeprocess memory. However, there is a limit to the number of api calls which implement this. Ultimately, this kind of code needs to be blocked, first, at the NT API level... Such blocking should use the same method as blocking the network calls, ie, "Do you want to allow this application to ..." Most commonly, this would be used with writeprocess memory. Createremotethread would need to be blocked in this manner. Postremotethreadmessage. PostThreadMessage. Are some of the more dangerous calls, in this context. After that, you are probably talking about having to do somesort of signature analysis at the binary level. It is always an arms race. OpenProcess does require seDebugPrivileges, I believe. [An interesting "arms race" to follow in this regards is between GearBox software and HL cheaters, btw.] Drew Research Engineer eEye Digital Security
RE: Bypassing Personal Firewalls
> -Original Message- > From: Oliver Lavery [mailto:[EMAIL PROTECTED] > Sent: Friday, February 21, 2003 3:23 PM > To: 'Drew Copley'; [EMAIL PROTECTED] > Subject: RE: Bypassing Personal Firewalls > > > >(Sidenote: a number of previous apps used to test PFWs or Application > Firewalls -- > >http://www.pcflank.com/art21.htm ) > > Yes, these are great tests. Most PFWs block them all now. I believe TooLeaky and Firehole remain unfixed on some firewalls. Too leaky apparently just runs IE with a url cmd argument. Firewall uses the messy way of hooking: SetWindowsHookEx > > >There are a number of ways to do this, you use the more > popular method > >of > openprocess and > >writeprocess memory. However, there is a limit to the number of api > >calls > which implement this. > >Ultimately, this kind of code needs to be blocked, first, at > the NT API > level... Such blocking > >should use the same method as blocking the network calls, > ie, "Do you > >want > to allow this > >application to ..." > > Yes. Before we go prompting users ever time someone > calls CreateFile, though, there are much simpler measures. > One of them would make OpenProcess require a priviledge of > some sort (see below). > > >Most commonly, this would be used with writeprocess memory. > >Createremotethread would need to be blocked in this manner. > Postremotethreadmessage. > >PostThreadMessage. Are some of the more dangerous calls, in this > >context. > > You'll notice that all of these calls require a handle > returned by OpenProcess (hProcess in my code). > > >After that, you are probably talking about having to do somesort of > signature analysis at the > >binary level. > > MD5 of the binary memory image! This is probably > feasible, but good god it would resource intensive. Any such method remains limited. You are in the openrange here. Here is a relevant and interesting paper: http://www.cs.washington.edu/homes/saurabh/papers/oh.pdf "Abstract. We describe a novel software verification primitive called Oblivious Hashing. Unlike previous techniques that mainly verify the static shape of code, this primitive allows implicit computation of a hash value based on the actual execution (i.e., space-time history of computation) of the code. We also describe its applications in local software tamper resistance and remote code authentication." > > >OpenProcess does require seDebugPrivileges, I believe. > > No, and this is very much the point. According to MS docs: > SeDebugPrivilege: > Determines which users can attach a debugger to any process. > This privilege provides powerful access to sensitive and > critical operating system components. > > This only prevents users from using OpenProcess on > system processes (winlogon.exe etc.). There need to be > tighter restrictions on the use of OpenProcess. Ah, that's right, remember now. > > Cheers, > ~ol > > >
RE: IE chromeless window vulnerabilities
This has been possible for sometime now. Guninski originally showed that this could be possible here: http://www.guninski.com/popspoof.html Date: 21 October 2001 Image moving over download/open dialog: http://www.guninski.com/opf2.html BSOD emulation: http://www.guninski.com/bsod1.html All of these [above and below] works on IE 6, full patches, w2k3. > -Original Message- > From: Andrew Clover [mailto:[EMAIL PROTECTED] > Sent: Sunday, July 13, 2003 12:20 PM > To: [EMAIL PROTECTED] > Subject: IE chromeless window vulnerabilities > > > Title: IE chromeless window vulnerabilities > Affects: Internet Explorer 5.5 and later > Risk: Medium > > > Introduction > > > A window without a frame, title bar, toolbars or scroll bars > is known as a 'chromeless' window. If a chromeless window can > be opened on top of other windows, it is possible to > impersonate Windows user interface elements. > > Why is this a security problem? Because Windows and browser > UI elements are themselves part of security mechanisms. If > the UI for security features can be faked, users can be > tricked into making inappropriate decisions. > > The 'traditional' way of doing chromeless windows was to use > the DHTML method window.open to open a full-screen browser > window (which is > chromeless) and then resize this to smaller dimensions. This > capability was removed in IE6 Service Pack 1, presumably due > to exactly these security concerns. > > > The problem > --- > > It is still possible to get chromeless windows by using the > window.createPopup method. A window opened with createPopup > has some unusual properties: > > - It is closed when one clicks on the outside the popup. > This is easy > to circumvent by simply re-spawning it on close. > > - It cannot be focused. (It is impossible to put controls like text > input fields in it; this, at least, prevents us from overlaying > fake login forms onto other websites.) Focus stays with the opener > window. > > - It floats above other normal windows, allowing it to obscure them > even whilst they are focused. > > One popup may be created per window, allowing one to overlay > an arbitrary rectangle of screen display area with fake UI. > More complicated overlays can be achieved by having multiple > windows opening popups at once; a popup is itself a window so > can be used to open further popups. > > > Exploitation > > > There are three simple exploit demonstrations at: > http://www.doxdesk.com/personal/posts/bugtraq/20030713-ie/ One fakes the address bar to seem to be another site; another tries to trick the user into adding a bookmark to the favorites menu by hiding the dialog box that has focus; another hides an ActiveX download prompt in order to fool the user into allowing arbitrary code to be run. These exploits are unpolished and could no doubt be made more convincing and robust, but this demonstrates the risk. Solution window.createPopup() should have the same chromeless window restrictions as createModalDialog() and createModelessDialog(). Workaround -- Disable Active Scripting. Vendor response --- Microsoft were informed of the problem on 23rd January. After initially encouraging e-mails, no action has been taken since. I am posting this issue now as I have seen it being exploited in the wild. If you use IE, be extremely wary of trusting what appear to be its built-in security controls. -- Andrew Clover mailto:[EMAIL PROTECTED] http://www.doxdesk.com/
RE: Windows Update - Unsafe ActiveX control
You should not enable "unsafe activex", in order to get Windows Update to work, however. http://*.windowsupdate.com , http://download.microsoft.com, http://windowsupdate.microsoft.com , https://download.microsoft.com, and http://*.windowsupdate.com should all be enabled in trusted sites zone. This is by default on Windows 2003. Some references which are a good rule of thumb: http://msdn.microsoft.com/library/default.asp?url=/workshop/security/szo ne/overview/esc_changes.asp Windows 2003 does have a good system in this way for the paranoid. It disables activex and activescripting, but it allows for Windows Update to properly work. Its' settings are documented in the above url. > -Original Message- > From: Jackson, Chris [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 17, 2003 10:35 AM > To: 'Siddhartha Jain(IT)'; [EMAIL PROTECTED] COM > Subject: RE: Windows Update - Unsafe ActiveX control > > > > "An ActiveX control on this page is not safe. Your current security > settings > > prohibit running unsafe controls on this page. As a result, > this page > > may not display as intended." So Microsoft expects me download > > critical patches using an unsafe ActiveX control?? > > Safe for Scripting indicates that a control does not access > files, memory, or registers directly. The only purpose of the > Windows Update control is to access (and update) files > directly, so it should not be marked as safe for scripting. > > -- > Chris Jackson > Software Engineer > Microsoft MVP > -- > >
RE: Microsoft MCWNDX.OCX ActiveX buffer overflow
I find no "MCWNDX.ocx" on my system nor on google. It may be a Windows locality issue. Microsoft Multimedia Control fits the description, though, as you noted. It does have a "FileName" method and uses the .mci filetype, but on Windows 2000 it is not a safe activex control for scripting on webpages in the Internet Zone. > -Original Message- > From: xenophi1e [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 13, 2003 10:51 AM > To: [EMAIL PROTECTED] > Subject: Re: Microsoft MCWNDX.OCX ActiveX buffer overflow > > > In-Reply-To: <[EMAIL PROTECTED]> > > > > Does anyone know what the guid for this control is? I don't > have it on XP > > with Visual Studio 6 installed. > > > > Could this be the same as the Microsoft Multimedia Control, aka > > MCI32.OCX? > > > > Cheers, > > ~ol > > > > > Microsoft MCWNDX.OCX ActiveX buffer overflow > > > = > > > > > > PROGRAM: MICROSOFT MCIWNDX.OCX ACTIVEX BUFFER OVERFLOW > > >HOMEPAGE: www.microsoft.com > > >VULNERABLE VERSIONS: MCWNDX is an ActiveX shipped with > Visual Studio 6 > >to > > >support multimedia programming. > > > > > > DESCRIPTION > > > = > > > > > > MCWNDX is an activeX shipped with Visual Studio 6 to > > >support multimedia programming. Although not many people use it > >anymore, > > >however it still can be called through CLSID in a website > and passing a > > >large amount of data to the activex will cause an buffer overflow. > > > > > >Since this Activex is only shipped with VIsual Studio 6.0, so only > > >people who are having Visual Studio 6.0 will be affected or people > > >who are still using old multimedia programs coded in Visual > Studio 6.0 > > >(In my PC, the last date the ActiveX is patched is in 1996 ! > I am using > > >VS Sp 4) > > > > > > > > > DETAILS > > > = > > > The ActiveX has a property called "Filename" which is used > to specify > > >the .mci file to load. However if it is passed with a very large > > >string(640KB > > >is good enough :-) ), it will cause a bufferoverflow. (I can't > >overwrite > > the > > >EIP using this overflow in my XP, however it doesn't mean the problem > > can't > > >be exploited) > > > > > >Microsoft has been noticed but since the hole is maybe minor > to them so > > >they don't response to me even a short sentence like "Thank you !" > > > > > > > > > > > > WORKAROUND > > > = > > > > > > Delete the file MCWNDX.ocx in your SYSTEM32 directory if you are > > >using 2000 or XP or in your SYSTEM directory if you are > using WIN ME or > > >below > > > > > > > > >CREDITS > > > = > > > > > > Discovered by Tri Huynh from Sentry Union > > > > > > > > > DISLAIMER > > > = > > > > > > 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: > [EMAIL PROTECTED] > > > > > > > > > > >
Security-Assessment.com Advisory: Destination Search Admin Console Access Control Bypass
(, ) (,
. `.' ) ('.',
). , ('. ( ) (
(_,) .`), ) _ _,
/ _/ / _ \ _
\ \==/ /_\ \ _/ ___\/ _ \ / \
/ \/ |\\ \__( <_> ) Y Y \
/__ /\___|__ / \___ >/|__|_| /
\/\/.-. \/\/:wq
(x.0)
'=.|w|.='
_='`"``=.
presents..
Destination Search Admin Console Access Control Bypass
Vendor link: http://www.localmatters.com/
PDF:
http://www.security-assessment.com/files/documents/advisory/Destination_Search_-_Admin_Console_Access_Control_Bypass.pdf
+---+
|Description|
+---+
>From the vendor website:
*** Destination Search is an industry-leading search platform that
enables publishers to promote local business listings on web and mobile
devices. Developed with smart search technology, Destination Search
ensures relevant results that match consumer intent, by enabling
searches by business name, keyword or category. ***
The Destination Search software platform includes an administration
console for use by site owners and partners. The console allows for
modification of site content, management of user accounts and the
tracking of click-through rates for advertisers.
It was discovered that access controls in place on the console are
insufficient and permit unauthenticated users to perform actions that
should be restricted.
++
|Exploitation|
++
Exploitation of this vulnerability involves directly accessing
application pages that do not implement validation of access control
restrictions.
For example, if an unauthenticated user attempts to access a site
template configuration page residing at
http://ds.example.com/selfserve/settings/page-templates they will
correctly be redirected to the console login page. However, by directly
requesting the following page at
http://ds.example.com/selfserve/ss/settings/page-templates, no session
validation is performed and the page is visible.
The following proof-of-concept HTTP POST request will create a new user
called “malicious” with the password “malicious123” and full
administration privileges to the application (the default “Admin” group
has a roleID of 0). Note that this request does not require any cookie
header to be supplied.
+--+
|Proof of Concept HTTP POST Request|
+--+
POST /selfserve/ss/user/edit HTTP/1.0
Host: ds.example.com
Content-Type: application/x-www-form-urlencoded
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Content-Length: 91
userId=&name=malicious&_status=on&password=malicious123&roleId=0&editListing=all&con
dition=all
The application will then return confirmation of successful account
creation in the HTTP response. A malicious user is then free to log in
to the administration console with full privileges.
++
|Solution|
++
Security-Assessment.com has tried on numerous occasions to contact Local
Matters, Inc. via email and Twitter to alert them to the existence of
this vulnerability. At the time of writing this advisory, no response
has been received from the vendor at all. As such, we are currently
unaware of any security patches being developed by Local Matters, Inc.
to mitigate this critical exploit.
Until the vendor develops and releases an update to their software
package, Security-Assessment.com strongly advises any company that has
Destination Search deployed in a production environment to restrict
access to the administration console to authorised IP addresses only.
+-+
|Advisory Timeline|
+-+
01/09/2011 – Vulnerability discovered
05/09/2011 – Email sent to vendor with details of vulnerability
21/09/2011 – Second attempt at email notification to vendor
28/09/2011 – Communication with vendor attempted via @matterslocal
Twitter account
13/10/2011 – Public release of advisory
+-+
|About Security-Assessment.com|
+-+
Security-Assessment.com is Australasia's leading team of Information
Security consultants specialising in providing high quality Information
Security services to clients throughout the Asia Pacific region. Our
clients include some of the largest globally recognised companies in
areas such as finance, telecommunications, broadcasting, legal and
government. Our aim is to provide the very best independent advice and a
high level of technical expertise while creating long and lasting
professional relationships with our clients.
Security-Assessment.com is committed to security research and
development, and its team continues to identify and responsibly publish
vulnerabilities in public and private software vendor's products.
Members of the Security-Assessment.com R&D team are globally recognised
through their release of whitepapers and presentations related to new
security research.
SafeWeb Vulnerability - Fingerprinting Websites Using Traffic Analysis
SafeWeb Vulnerability Fingerprinting Websites Using Traffic Analysis === Overview === SafeWeb's web anonymizing service is supposed to prevent outside observers, such as a government, from observing the web surfing of its users. It does this by encrypting the traffic between SafeWeb and the user. I have discovered that by analyzing the amount of data transferred to a user, it is possible to determine if a user is viewing a certain website using SafeWeb. This attack can be used by a government, such as the Chinese government, to monitor which of its citizens are using SafeWeb to view seditious websites. SafeWeb is partially funded by the CIA. SafeWeb's web anonymizing technology has been recently licensed to PrivaSec. === Details === For details on the attack, please read my paper that's at: http://guh.nu/projects/ta/safeweb/ === Code === In my mind, you can't really have a good vulnerability announcement without a matching exploit. (just to um, show that it works... >:) Get my code from http://guh.nu/projects/ta/safeweb/fingerprint.pl === Greetz === Shout out to ghost. word to your mom. Oh yes, and the m4dn3ss lives on. How do you feel about that? -- ^Drew http://guh.nu --Begin PGP Fingerprint-- 3C6C F712 0A52 BD33 C518 5798 9014 CA99 2DA0 5E78 --End PGP Fingerprint--
