- OpenX Community Forums
![]() ![]() |
Apr 13 2010, 12:10 PM
Post
#16
|
|
|
Member ![]() ![]() Group: Members Posts: 23 Joined: 31-October 08 From: Europe Member No.: 23,930 |
We have same issue as Embauche.com, deleted both new admin (adm) and second default manager. But still no statistic columns are being shown.
|
|
|
|
Apr 13 2010, 02:41 PM
Post
#17
|
|
|
Member ![]() ![]() Group: Members Posts: 14 Joined: 12-April 10 Member No.: 109,671 |
We are having the same issue and we have deleted the ADM user and deleted/reinstalled out plugins, cleared out caches, checked our logs, done practically everything and still no statistics. We even upgraded to 2.8.5 with no fixes.
Is this something OpenX needs to fix on their end? Obviously some sort of security issue...? If so, I'm happy to submit a bug report. Has anyone submitted a bug report yet? Jaime |
|
|
|
Apr 13 2010, 03:51 PM
Post
#18
|
|
|
Beginner ![]() Group: Members Posts: 1 Joined: 13-April 10 Member No.: 110,031 |
I discovered that the exploit alters the admin_account_id variable in ox_application_variables to point to its newly created manager (account_id 82). You may need to execute the statement below to regain your statistics:
CODE update ox_application_variable set value = 1 where name ='admin_account_id';
|
|
|
|
Apr 13 2010, 04:01 PM
Post
#19
|
|
|
Advanced Member ![]() ![]() ![]() Group: Members Posts: 45 Joined: 25-September 07 From: Cleveland, OH Member No.: 18,326 |
I discovered that the exploit alters the admin_account_id variable in ox_application_variables to point to its newly created manager (account_id 82). You may need to execute the statement below to regain your statistics: CODE update ox_application_variable set value = 1 where name ='admin_account_id'; Greg, brilliant! Thank you so, so, so much! |
|
|
|
Apr 13 2010, 04:28 PM
Post
#20
|
|
|
Member ![]() ![]() Group: Members Posts: 14 Joined: 12-April 10 Member No.: 109,671 |
I discovered that the exploit alters the admin_account_id variable in ox_application_variables to point to its newly created manager (account_id 82). You may need to execute the statement below to regain your statistics: CODE update ox_application_variable set value = 1 where name ='admin_account_id'; Greg, brilliant! Thank you so, so, so much! WORKS!!! Thank you Greg. Fantastic fix. Hope this helps other people. |
|
|
|
Apr 13 2010, 04:58 PM
Post
#21
|
|
|
Member ![]() ![]() Group: Members Posts: 14 Joined: 12-April 10 Member No.: 109,671 |
One more thing...
Upon login, we get this error message: --- Error: File permission errors detected. These may impact the accurate delivery of your ads, See the debug.log file for the list of unwritable files --- Looking at the debug.log file, we see this message: --- [...] Unwritable file [...]var/cache/cache__ComponentHooks_Plugins --- What do we need to do to resolve this? Is it related to the recent hacking attempt? Trying Configuration -> Maintenance -> Plugins -> Rebuild Component Hooks Cache did nothing. |
|
|
|
Apr 13 2010, 07:18 PM
Post
#22
|
|
|
Beginner ![]() Group: Members Posts: 5 Joined: 13-April 10 Member No.: 109,821 |
Thank you so very much for your solution to the problem!
|
|
|
|
Apr 13 2010, 11:54 PM
Post
#23
|
|
|
Beginner ![]() Group: Members Posts: 2 Joined: 13-April 10 Member No.: 110,161 |
I had the same problem. Thanks to everyone who posted various instructions in this thread! I have our statistics back and the accounts cleaned up. However, it doesn't look like the plugin file mentioned above was modified. I saw in our httpd logs that there was a POST request to plugin-index.php, which I'm assuming was to upload the new code. Immediately after that, genericHtml.delivery.php was called directly. From the snippet above, it looks like the encoded script is unpacked when hitting the php script directly. Does anyone know what that script was supposed to do?
|
|
|
|
Apr 14 2010, 09:43 AM
Post
#24
|
|
|
Beginner ![]() Group: Members Posts: 2 Joined: 14-April 10 Member No.: 110,361 |
I have the same problem, I can't see the statistics either since last weekend even though the banners are still served without any problem.
I haven't found a file infected with the following code: CODE if (basename($_SERVER['PHP_SELF'])=='genericHtml.delivery.php') { eval(gzinflate(base64_decode("...")));} I have launched scripts/maintenance/tools/statisticsTestAndCorrect.php and I have quite a lot of lines as follows, all from the 06/04/2010. QUOTE Running in debug mode only, if running correctly, the following would have been performed: DELETE FROM ox_data_summary_ad_hourly WHERE date_time ='2010-04-06 03:00:00' AND ad_id = 20 AND creative_id = 0 AND zone_id = 22 AND requests = 4894 AND impressions = 4166 AND clicks = 3 AND conversions = 0 LIMIT 1; But it finishing by telling me the following: QUOTE Testing for any instances of statistics rows in the data_intermediate_ad table that have not been fully summarised into the data_summary_ad_hourly table. Please be patient while this process runs! Database error while searching for invalid data: MDB2 Error: Array Cannot detect issues, so will not attepmt any corrections. On the 10th we had second user account added, that has already been deleted. I have performed the check: QUOTE update ox_application_variable set value = 1 where name='admin_account_id'; I have upgraded to openx 2.8.5. And after all this I still can't see the statistics. Any idea how to solve this problem? Thanks in advance |
|
|
|
Apr 14 2010, 05:39 PM
Post
#25
|
|
|
Beginner ![]() Group: Members Posts: 2 Joined: 13-April 10 Member No.: 110,161 |
I have performed the check: QUOTE update ox_application_variable set value = 1 where name='admin_account_id'; You should make sure that the value in this sql matches the id of your real admin account. In my case, it was actually 2 (Not sure why, I didn't set the system up originally). You can find it in the accounts table (but make sure you don't use anything added by the attack, in case it wasn't cleaned up properly). |
|
|
|
Apr 15 2010, 07:47 AM
Post
#26
|
|
|
Beginner ![]() Group: Members Posts: 2 Joined: 15-April 10 Member No.: 110,621 |
Thank you, thank you and THANK YOU!
Been at it for days and update db app var worked like a charm! Only question remains that is there still a vulnerability that can be used to screw these things back to hell again? |
|
|
|
Apr 15 2010, 11:35 AM
Post
#27
|
|
|
Beginner ![]() Group: Members Posts: 2 Joined: 14-April 10 Member No.: 110,361 |
You should make sure that the value in this sql matches the id of your real admin account. In my case, it was actually 2 (Not sure why, I didn't set the system up originally). You can find it in the accounts table (but make sure you don't use anything added by the attack, in case it wasn't cleaned up properly). I have made sure that the admin_account_id value points towards the administrator account. Any other idea? |
|
|
|
Apr 16 2010, 02:22 PM
Post
#28
|
|
![]() Mentor ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Group: Members Posts: 2,130 Joined: 24-October 03 From: Ohio Member No.: 419 |
We didn't have this issue with the hacked files, but we've tried all available help suggestions above and our stats are still blank.
Is there anything more we can do to recover our stats, as even new stats are not generated, which is a major problem. |
|
|
|
Apr 16 2010, 02:31 PM
Post
#29
|
|
|
Beginner ![]() Group: Members Posts: 3 Joined: 14-April 10 Member No.: 110,481 |
I discovered that the exploit alters the admin_account_id variable in ox_application_variables to point to its newly created manager (account_id 82). You may need to execute the statement below to regain your statistics: CODE update ox_application_variable set value = 1 where name ='admin_account_id'; I Love you |
|
|
|
Apr 17 2010, 09:16 PM
Post
#30
|
|
|
Member ![]() ![]() Group: Members Posts: 19 Joined: 24-November 08 From: Austria Member No.: 24,344 |
Apparently I've been affected by this exploit. What I've read so far tells me I should:
1. Hunt down and delete every instance of the following in the openx files: CODE if (basename($_SERVER['PHP_SELF'])=='genericHtml.delivery.php') { eval(gzinflate(base64_decode("...")));} 2. Remove any additional admin accounts that were generated 3. Get admin permissions back for the real admin account by going to the database and setting "admin_account_id" to "1" in the table 'ox_application_variable' 4. Upgrade to 2.8.5 Is that all we have to do to get rid of the hack? I think I got rid of the infected files (after using using grep to search for files containing parts of the above code). I also changed that admin permissions setting in the database. Now I can see my stats again. But I'm not sure how to delete the additional accounts. When I switch to administrator and go to Inventory>Account Management, there's only one user in the table (Default Manager, ID 1). However, in My Account > User Log, there are the following alarming lines: QUOTE 10-04-2010, 16:31:17 adm updated User "adm" (#4) 10-04-2010, 16:31:17 adm deleted Account "Default manager" (#12) and additional items 10-04-2010, 16:31:17 adm deleted Agency "Default manager" (#2) 10-04-2010, 16:30:54 Installer updated User "" (#4) 10-04-2010, 13:46:38 Installer inserted Account User Association "Account #12 -> User #4" 10-04-2010, 13:46:38 Installer inserted Account User Association "Account #11 -> User #4" 10-04-2010, 13:46:38 Installer inserted User "adm" (#4) 10-04-2010, 13:46:38 Installer inserted Agency "Default manager" (#2) 10-04-2010, 13:46:38 Installer inserted Account "Default manager" (#12) 10-04-2010, 13:46:37 Installer inserted Account "Administrator account" (#11) So how do I identify the malicious accounts, agencies, associations and users and get rid of them? EDIT: I also noticed the config file for the site in the /var directory was changed the minute after those events in the user log. I diff'ed it with an older backup, but the only difference was that Line 206 changed from "fromAddress=" to "fromAddress=admin@openx.xx". Isn't that weird? EDIT2: Just upgraded to 2.8.5 and got the following message: QUOTE Upgrade package openXBannerTypes" has a version stamp that is older than that of the package you have installed that plugin contained one of the infected files. That's mighty suspicious.
|
|
|
|
![]() ![]() |