Hijacked oadest in ad links

[IvorD]

I asked a similar question back in 2019 on the Off Topic forum, but got no response and the problem has now cropped up again:

We got alerted through the Google Search Console about a "bad" link on our website. The link cited was a Revive ad link in which a different URL from the target URL of the bannerid banner had been substituted for the oadest component of oaparams   The substituted URLs are to porn sites, of course. Curiously, going through the last couple of months of Apache logs, I can only find requests for lots of similarly hijacked URLs (for the same banner and zone IDs) from web crawlers, primarily Google. I find no requests from any website where the crawlers may have found the links, so I have no idea where the search engines found them to try to crawl them through our site. I've compared the live Revive installation with a separate development server and have concluded that none of the source files has been corrupted and none of the banners in the database has been corrupted.

Specific questions:

1. Has anyone else experienced and/or investigated this problem and, if so, how did you avoid it?
2. I've seen references to "features" that require the presence the oadest URL parameter when one would think that the bannerid and zoneid should be sufficient. Where can I find an explanation of those "features" and why this security hole is "unavoidable".

Perhaps I can join the club of those who have banged their heads on the wall looking for a solution to the oadest problem, given a pointer to the context.

[IvorD]

It looks like I can prevent this open redirection in MAX_querystringGetDestinationUrl by forcing it to use the ad's url when an ad is specified:

if (/*empty($dest) &&*/ !empty($adId)) {
    $aAd = MAX_cacheGetAd($adId);
    if (!empty($aAd)) {
        $dest = $aAd['url'];
    }
}

Under what legitimate circumstances would the URL specified in the dest parameter for an ad click be different from the URL specified for the ad also identified in the click URL? (Our deployment is not as a general purpose/revenue-generating ad server, but a convenient way to track referrals to affiliates who offer commissions; we have a couple of zones which serve ads through Google AdSense, but the rest are our own.)

[AlexM]

Hi Ivor,

I have this problem too! My VPS provider emailed a link, it forwards to a page that is virus laden and I have to sort it out.

Did you find where you can stop it have open forwarding?

Alex

 

[IvorD]

Caveat: My solution below may or may not break something else of which I am not aware. I have not had ANY response to inquiries about under what circumstances the oadest URL would legitimately differ from the URL associated with the banner identified by the "bannerid" (aka "$adId") in the same query. I even asked someone directly who said they had spent hours unsuccessfully looking for a workaround to the open redirection requirement, but have had no response so far. It's evidently a deliberate design choice.

I solved my problem (see previous post in this thread) in function MAX_querystringGetDestinationUrl with the following change to force it to use the URL associated with the banner instead of the URL supplied in the oadest parameter when the banner is identified in the request:

< if (empty($dest) && !empty($adId)) {
---
> if (/* id: Force use of ad's url: empty($dest) &&*/ !empty($adId)) {

In the source code the function is in www/delivery_dev/ck.php but that is assembled into both www/delivery/ck.php and www/delivery/lg.php for distribution.

I wrote a bash script so I can re-apply the patch to future releases for our deployment. It saves the original file with a .save suffix:

#!/bin/bash
#
# Apply this script to the following adserver files:
#       www/delivery/ck.php
#       www/delivery/lg/php
#
# to avoid open redirection in ad click URLs
#

file=$1
tmpFile=${file}.tmp

if [ "$file" = "" ]; then
  echo "usage: $0 filename"
  exit 1
fi

if [ ! -w $file ]; then
  echo "Cannot write file $file"
  exit 1
fi

if [ $file:h = $file:t ]; then
    file=$cwd/$file
fi

egrep "function MAX_querystringGetDestinationUrl" $file > /dev/null

status=$?

if [ $status -eq 0 ]; then
    if [ ! -e $file.save ]; then
      echo Copying $file to $file.save
      cp -p $file $file.save
    fi
    
    script=/tmp/sed.$$

    cat > $script <<EOF
s|(empty(\$dest) && !empty(\$adId))|(/* empty(\$dest) \&\& */ !empty(\$adId))|

EOF
    sed -f $script $file > $tmpFile

    status=$?

    if [ $status -eq 0 ]; then
        diff -c $file $tmpFile
        /bin/mv $tmpFile $file
    else
        rm -f $tmpFile
    fi

    rm -f $script

    echo "Fixed $file"
fi

[AlexM]

IvorD,

Many thanks, I'll give it a go tomorrow.

I am confused too. I can't think what they're doing that would mean it would use an alternative URL for an Ad?! All I need it for is one URL/Ad.

Alex

[AlexM]

IvorD,

Unless I am doing something wrong, when there is: empty($aAd) it still forwards the page.

i.e. <server>/www/delivery/ck.php?oadest=https://www.google.com brings up Google.

It's messy PHP, I know - sorry ?, but I think if you also stick the red text in MAX_querystringGetDestinationUrl then you just get a white page (the same as if $dest is null) for above.

if (empty($aAd)) {
return;
}
if (empty($dest)) {
return;
}

Is there anything I missed doing this? ?

Alex

Edited September 2, 2020 by AlexM

[IvorD]

If $adId is empty then you have no banner whose URL should be used in place of the oadest URL. The problem I was solving was a request that contained both a banner ID and a bogus oadest. My change forces the use of the banner's URL when the banner ID is supplied, ignoring the oadest URL. It does not affect the behaviour if there is no banner ID provided. Sorry. The alternative would be to modify the procedure return an empty string if no $adId is specified, but I have no idea how often and/or where requests without a banner ID may be generated otherwise, so that modification might break some other functionality that I don't know about.

[tkat]

Hello IvorD,

We are having the same problem, with our ad tags getting blocked by Google Ad Manager. 

We use our Revive adserver to distribute the 3rd-party ad tags (usually from DCM, sometimes from Sizmek) provided by our advertisers to our various affiliate publishers.  The pubs generally use Google Ad Manager to serve our tags to their various zones.

GAM is now blocking many of our tags when publishers try to enter them into GAM.

Now when the ad does manage to get served via overlay tags which some pubs paste directly into their pages, bypassing GAM, and a user clicks the ad, instead of going to the landing page, the user gets an error message:

Access to adclick.g.doubleclick.net was denied

You don't have authorization to view this page.

Is your solution working for these kinds of situations?  Your tags aren't blocked by GAM and ads served via DCM tags click through to their correct landing page?

If so, perhaps you can fix this issue on our Revive install.  We would be happy to pay for your help.

[IvorD]

I'm not sure our problems are the same. The problem I was addressing was someone taking one of our legitimate Revive ad URLs and replacing the "oadest" parameter with a different target than that specified for the banner so that Revive did the redirection to the bogus target. My solution was to ignore the oadest parameter when the banner ID is specified in the ad URL and use the URL associated with the banner instead. As I noted before, the open redirection problem has been described as an unavoidable feature of Revive, but so far nobody has pointed me to an explanation of why that is and I haven't delved into the code beyond looking for the narrow fix to our problem. Sorry I can't be much more help. Have you looked at the URL being used to access adclick.g.doubleclick.net to confirm it is as you expect and has not been modified by malware along the way?

[tkat]

I really appreciate your taking time to respond. 

You're right that the problems aren't the same as it persists after I implemented your solution for your issue.

Yes, the redirect for doubleclick was working fine until this issue popped up last last night.

Please let me know if you find yourself encountering the same issues with Google.