Piwigo.org

terminus · 2017-05-23 23:50:56

Hi,

I upgraded Piwigo by extracting the file on top of my existing installation and going through the database upgrade in the web browser. It appeared to work fine, the admin page loaded and I went through the tour, but then when I tried to view the gallery from its main page, it wouldn't load at all (no error, but just page would hang on loading). Meanwhile the Apache process which is serving this page goes to 100% CPU. I can't even load the admin page again now, because now that I'm logged out it redirects me to identification.php and that page hangs in the same manner as the main page.

This ends up bringing my entire server to a halt, because even if I'm not loading my Gallery, there are random robots attempting to do so. If I replace the index.php page with a phpinfo test page, that page loads fine. I have removed all of the plugins from the plugin directory. So it's clearly something to do with Piwigo rather than another aspect of my webserver configuration.

I'm seeing this in the logs:

PHP Fatal error: Maximum execution time of 1600 seconds exceeded in /var/www/piwigo/include/functions_category.inc.php on line 564

PHP Fatal error: Maximum execution time of 1600 seconds exceeded in /var/www/piwigo/include/functions_category.inc.php on line 562

PHP Fatal error: Maximum execution time of 1600 seconds exceeded in /var/www/piwigo/include/functions_category.inc.php on line 566

If I comment out the entire subroutine in functions_category.inc.php that contains those lines (it seems to be a permissions check), then the page still hangs on some other routine (I didn't wait 1600 seconds to find out which one).

How would I further troubleshoot this?

Thanks.

Piwigo version: 2.9
PHP version: 5.6.30
MySQL version: 14.14
Piwigo URL: http://www.malcolm.id.au/gallery

I put a new index.html in there while I'm fixing this, but the index.php file can still be accessed directly. If you do though, my server will hang.

Last edited by terminus (2017-05-24 22:54:15)

terminus · 2017-05-24 22:53:14

Found something weird in the database that may help to explain this behaviour. It's a bunch of entries in the categories table mostly with the name "OSM0" or some variation of it, and content like this:

OSM virtual album
lat:0 0
lng:(SELECT 5477 FROM(SELECT COUNT(*),CONCAT(0x71627a6271,(SELECT MID((IFNULL(CAST(schema_name AS CHAR),0x20)),1,54) FROM INFORMATION_SCHEMA.SCHEMATA LIMIT 9,1),0x71627a6a71,FLOOR(RAND(0)*2))x FROM INFORMATION_SCHEMA.CHARACTER_SETS GROUP BY x)a) 0

Can't really make head or tail of it, but there are dozens of them. Possibly a hack, or an attempt at one? Or a botched upgrade script

After deleting these mystery lines, my site loads again.

Last edited by terminus (2017-05-24 22:59:33)

flop25 · 2017-05-28 23:04:12

Thx for reporting It sounds like a hacking attempt through the plugin OSM [extension by xbgmsharp] piwigo-openstreetmap
Can you restrict your website to your ip only through an htaccess for a few days to see if you get in your server log specific attempts to reach specific urls
I contact the author of the plugin and Pierrick

terminus · 2017-05-30 23:45:52

Your explanation makes sense. I do use that plugin. And, bingo! - lookie here at the logs:

access.log:188.244.210.112 - - [14/May/2017:07:53:46 -0700] "POST /gallery/osmmap.php?max_lat=0&max_lng=0&min_lat=0&min_lng=%28SELECT%203163%20FROM%28SELECT%20COUNT%28%2A%29%2CCONCAT%280x71627a6271%2C%28SELECT%20IFNULL%28CAST%28COUNT%28password%29%20AS%20CHAR%29%2C0x20%29%20FROM%20osmantemizel_com_1.piwigo_users%29%2C0x71627a6a71%2CFLOOR%28RAND%280%29%2A2%29%29x%20FROM%20INFORMATION_SCHEMA.CHARACTER_SETS%20GROUP%20BY%20x%29a%29 HTTP/1.1" 200 3278 "-" "sqlmap/1.0-dev-nongit-20170324-0b4b (http://sqlmap.org)"

And many others like that.

flop25 · 2017-05-31 01:55:28

thx!
I post on github
So i suggest to change the plugin folder to be sure it's safe

OliverB · 2017-05-31 15:21:56

do you see any risk using the current version of the OSM plugin?

flop25 · 2017-05-31 15:52:08

OliverB wrote:
do you see any risk using the current version of the OSM plugin?

injecting is just one half or one third of a hack ; the injected code has to be executed.
There is a risk which can not be neglected here. Disabling it or not depends on how much you need it and on the content of your database. If you have another CMS, users who wouldn't like to see their email correlated to their username... disable it. If you only use Piwigo with your user only, the cost-benefit ratio is very low : all passwords are hashed and salted. If that would be a potential issue were the hacker could write on the server i would recommend to disable it instantaneously

OliverB · 2017-05-31 17:01:09

the OSM plugin is one of the reasons I selected Piwigo over jAlbum. The other was the powerful search.

I'm (and will be) the only user besides "guest" and use a unique PW for Piwigo.

If I understand correctly, the worst effect is the bunch of OSM virtual album entries in the database?

flop25 · 2017-05-31 17:17:13

OliverB wrote:
If I understand correctly, the worst effect is the bunch of OSM virtual album entries in the database?

currently that's the only proof of hacking attempts. More specifically the first request injected is made to get the schema of the database and the other one to get the passwords "password%29%20AS%20CHAR%29%2C0x20%29%20FROM%20osmantemizel_com_1.piwigo_users" quite hard to know it the hacker actually got the pwds: the full log and temporary files should be carefully reviewed then attempts to reproduce the attack should be performed.

flop25 · 2017-05-31 18:56:53

xbgmsharp answered and after reviewing the code with his help, it seems that this issue has been fixed since November with the release 2.8d
I asked to try to reproduce with the POST values found in the log of terminus, but i'm quite sure it's safe.

which means that you may have been compromised previously but not since the 2.8d update (if you updated)

terminus · 2017-05-31 19:09:25

Thanks, that's comforting. For whatever reason, the problem only manifested itself after I upgraded, I suppose because another code change caused the bogus entries in the categories table to hang the loading of the site. But, indeed, there has been no new damage to the categories table since the upgrade.

OliverB · 2017-06-01 07:26:33

flop25, thanks for checking this!

Piwigo.org

Announcement

#1 2017-05-23 23:50:56

Upgraded Piwigo won't load and sends Apache to 100% CPU

#2 2017-05-24 22:53:14

Re: Upgraded Piwigo won't load and sends Apache to 100% CPU

#3 2017-05-28 23:04:12

Re: Upgraded Piwigo won't load and sends Apache to 100% CPU

#4 2017-05-30 23:45:52

Re: Upgraded Piwigo won't load and sends Apache to 100% CPU

#5 2017-05-31 01:55:28

Re: Upgraded Piwigo won't load and sends Apache to 100% CPU

#6 2017-05-31 15:21:56

Re: Upgraded Piwigo won't load and sends Apache to 100% CPU

#7 2017-05-31 15:52:08

Re: Upgraded Piwigo won't load and sends Apache to 100% CPU

OliverB wrote:

#8 2017-05-31 17:01:09

Re: Upgraded Piwigo won't load and sends Apache to 100% CPU

#9 2017-05-31 17:17:13

Re: Upgraded Piwigo won't load and sends Apache to 100% CPU

OliverB wrote:

#10 2017-05-31 18:56:53

Re: Upgraded Piwigo won't load and sends Apache to 100% CPU

#11 2017-05-31 19:09:25

Re: Upgraded Piwigo won't load and sends Apache to 100% CPU

#12 2017-06-01 07:26:33

Re: Upgraded Piwigo won't load and sends Apache to 100% CPU

Board footer