Bugtraq mailing list archives

Re: Microsoft BackOffice component: adredir.asp

From: Russ.Cooper () RC ON CA (Russ)
Date: Sun, 4 Jun 2000 13:05:36 -0400


My testing on W2K Server with IIS 5.0 & SS3CE.

Bkgrnd: adredir.asp is commonly used component of IIS-based commercial
sites, used to handle ad banners.


Adredir.asp comes from the Microsoft Site Server 3.0 - Commerce Edition, and
is a component of the Microsoft Ad Server. Its purpose is to handle
click-throughs and redirect the browser to the URL specified for a given
"Campaign Item ID", or ciid. It records the click-through "event", or evt,
in the ad dB, together with the page that generated the ad. It does not
generate ad banners, or have anything to do with the placement of ad banner
code in pages. Ad banners include adredir.asp in their URIs.

This BO component (the first and only I'm going to check - responsible
web admins shouldn't use IIS+ASP at all, choosing more secure solutions,
like Apache+SSI or even Apache+IIS, IMHO) has buffer overflow. It can be
exploited by sending request like:

GET /place_it_lives_in/adredir.asp?url=(more than +/- 500 bytes)

By choosing something around 500-510 bytes (depending on directory name
length), you'll notice first change - server will drop connection after
returning '302 Moved' http header. Normally, it prints these headers, and
then some html code as well: <body><h1>Object Moved</h1>This object may be
found <a HREF="AAAA.... Probably this HTML is rendered into small text
buffer, and script crashes while trying to assemble it.


I'm not sure what the basis is for saying this is a BO?? Yes, it returns a
302, and it includes the entire scrap URL that was supplied to it (which
would seem to indicate it hasn't overflowed a buffer, wouldn't it?).

It makes no difference (in my testing) whether the number of scrap
characters are 10, 100, 505, or 1005. Each time I got the full set of
characters back and the returned HTML error page included text before and
after the supplied characters as well as a closing body tag, looked
completely assembled to me.

With approx 1000 bytes of junk, script will die without even displaying
headers. Funny. And exploitable, I guess. I have no idea about symptoms on
NT machine, probably not much, at least it not crashes (wow, uncommon!).


This comment is even stranger. Nothing happened on the IIS box other than
dropping the connection. This is because it was redirecting the browser to
some other site. In the cases stated (and my tests), there was no site being
specified (the random characters didn't represent a valid site. Retest,
including a valid site name before the random characters and your browser
establishes a connect there and then dies (assuming the random characters
don't represent anything valid the remote site recognizes). If you were to
conduct this test while connected to an IIS site (invoking adredir.asp the
way its designed to be invoked), your other connections to the site would
remain alive as they should.

Again, as you'll see from the code of the scrip below, you're performing a
redirect, so why should the IIS site maintain a connection with you?

Have a good day. Someone might want to check if I'm right, but I can't
imagine it might be something else than overflow.


This sounds like a solid basis for claiming a BO...;-]

Adredir.asp contains the following code;

set ad = application("ad")
ciid = request.querystring("ciid")
url = request.querystring("url")
evt = request.querystring("evt")
if evt = "" then evt="CLIK"
call ad.recordevent(response, ciid, evt)
response.redirect(url)

Where "ciid" is the "Campaign Item ID" representing which ad is to be
retrieved. "url" is the page the advertiser wants clients to be redirected
to, and evt indicates whether or not it was a click-through.

The 302 response, while unexpected by some, makes sense if you consider the
purpose of the page. The 302 is being generated because the ad dB doesn't
recognize the ciid. However, since the URI included a value in the
placeholder for a URL, it returns the error page with that URL listed as the
location of the redirect. You could argue that the component could do a
better job parsing the supplied value to determine if its actually a URL.

With no apparent ill effects in any of the IIS components, and nothing
recorded in any event log, I'd say this certainly does not appear to be any
sort of BO.

Btw. OAS (Oracle Application Server) / OWL (Oracle Web Listener) users
shouldn't feel safe. More details soon.


If this adredir.asp BO is any indication, there might be a sigh of
relief...;-]

Cheers,
Russ - NTBugtraq Editor

Current thread:

Re: Microsoft BackOffice component: adredir.asp Microsoft Security Response Center (Jun 04)
- Re: Microsoft BackOffice component: adredir.asp Michal Zalewski (Jun 03)
- Linux-Mandrake bind update. Chmouel Boudjnah (Jun 04)
- Why You Should Upgrade To NT4 SP4 or NT5 Luke Kenneth Casson Leighton (Jun 04)
- <Possible follow-ups>
- Re: Microsoft BackOffice component: adredir.asp Russ (Jun 04)