OpenX CSRF Vulnerability Being Actively Exploited

Monday, April 30, 2012

Mark Baldwin

6648b1abd4a9b964566c3690613f20a6

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.

Background

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:

(click image to enlarge)

 

 

 

 

As can be seen, a record was inserted into the users table creating the admin account "openx-manager" with an email account of "admin@openx-team.org". The fact that it has "1" as the default_account_id is what gives this account admin privileges.

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:

(click image to enlarge)

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 vulnerability. 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.[box type="info"]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 "http://adserver.openx.org/plugins/videoReport/images/items/icons.html?oapPath=http%3A//admin.opx.mydomain.com/" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.162 Safari/535.19"[/box]

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:

http://adserver.openx.org/plugins/videoReport/images/items/icons.html?oapPath=http%3A//admin.opx.[my_client_domain].com/

This means that the CSRF attack was hosted on adserver.openx.org 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 http://adserver.openx.org/plugins/videoReport/images/items/icons.html 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.

(click image to enlarge)

Debug Baldwin

Summary

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 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 big question that I still have not been able to answer definitively is how did the attack occur. As I mentioned, I am confident I did not open any emails with a CSRF attack in them.  

Since the attack was hosted on OpenX's OnRamp system, perhaps the CSRF was a result of one of the plugins that integrates with OpenX Market, OpenX News or OpenX Support Forums. I am fairly certain that the attack occurred on the OpenX dashboard page as this is where all the widgets are loaded.

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).

References

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:

  1. http://blog.armorize.com/2011/07/openx-hacked-by-dyndns-malvertising.html
  2. http://www.stopthehacker.com/2011/04/20/openx-iframe-malware/
  3. http://www.exploit-db.com/exploits/17571/
  4. http://nakedsecurity.sophos.com/2012/03/28/openx-ads-leading-to-malware-co-blackadvertspro/

Cross-posted from InfosecStuff.com

Possibly Related Articles:
9318
Vulnerabilities
Information Security
CSRF Vulnerabilities Attacks Exploits hackers Infosec Analysis OpenX
Post Rating I Like this!
6648b1abd4a9b964566c3690613f20a6
Mark Baldwin After doing a little research on this issue, I believe I have come up with a plausible attack 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 d1.openx.org 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 d1.openx.org is 173.241.250.2 and the address of adserver.openx.org is 173.241.250.3. 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 adserver.openx.org going back to April 10 and continuing through April 24 (the date that the icons.html script was removed from adserver.openx.org). 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.
1335888092
Default-avatar
Brian Ng Thanks for all the information. I have been wondering how did the attacker access my openx because I'm using nginx and also password protected the admin folder. That's meant the attacker didn't have access to my openx right? I've checked the database and there was no malicious code
1336033652
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.