Hi Guys,
I've just had a major security hole reported to me by Colin Keigher (AnimeFreak) animefreak@users.sourceforge.net It relates to how some sites have PMA set up (they have username and password hardcoded, without any .htaccess protection).
Basically, by searching on Google for "Welcome to phpMyAdmin" or it's translated equivilents, you can find a lot of PMA installations. You can put the version number in there as well, like "Welcome to phpMyAdmin 2.3.0-rc1" Here is a sample URL to search: http://www.google.ca/search?hl=en&ie=UTF-8&oe=UTF-8&q=%22Welcome...
With using some of these URL's you can do stuff like: http://www1.tsimtung.com/phpMyAdmin/sql.php?goto=/etc/passwd&btnDrop=No
Here is a front page: http://garfield.vet.fnt.hvu.nl/counter/myadmin/
And other nefarious things. I found a few sites where I could access their entire database with full rights, even some where they have configured the user to root and I could change the mysql database.
This is what we need to do to fix it: 1. All served up pages should contain directives to instruct search robots not to index the files. This will stop so many sites being listed in the search engines.
2. We should deprecate the user/password standard login, or add a bit of technology to it. We should throw up a login page of our own, that should authenticate against a user/password pair in an array inside the configuration file. It might be possible to keep the automatic login of user/password, but it should not be enabled by default, for security. And the configuration option to turn that unsecure method back on should have huge warnings around it.
----- Original Message ----- From: "Robin Johnson" robbat2@fermi.orbis-terrarum.net
I've just had a major security hole reported to me by Colin Keigher (AnimeFreak) animefreak@users.sourceforge.net It relates to how some sites have PMA set up (they have username and password hardcoded, without any .htaccess protection).
Arg...! No comment :o)
Basically, by searching on Google for "Welcome to phpMyAdmin" or it's translated equivilents, you can find a lot of PMA installations. You can put the version number in there as well, like "Welcome to phpMyAdmin 2.3.0-rc1" Here is a sample URL to search:
http://www.google.ca/search?hl=en&ie=UTF-8&oe=UTF-8&q=%22Welcome... in+2.3.0%22&meta=
With using some of these URL's you can do stuff like: http://www1.tsimtung.com/phpMyAdmin/sql.php?goto=/etc/passwd&btnDrop=No
I've just merged a fix against that, but it needs some testing since I do not have a machine here which is affected by this securety hole.
And other nefarious things. I found a few sites where I could access their entire database with full rights, even some where they have configured the user to root and I could change the mysql database.
Cool! We've built a hacking tool!
This is what we need to do to fix it:
- All served up pages should contain directives to instruct search robots
not to index the files. This will stop so many sites being listed in the search engines.
I agree, but we cannot trust in these directives, imho.
- We should deprecate the user/password standard login, or add a bit of
technology to it. We should throw up a login page of our own, that should authenticate against a user/password pair in an array inside the configuration file. It might be possible to keep the automatic login of user/password, but it should not be enabled by default, for security. And the configuration option to turn that unsecure method back on should have huge warnings around it.
Could we detect a .htaccess protection? If so, let's display a big red warning if someone uses the config auth mode without a .htaccess protection...
Alexander
Hi Robin an the others,
http://www.google.ca/search?hl=en&ie=UTF-8&oe=UTF-8&q=%22Welcome... in+2.3.0%22&meta=
With using some of these URL's you can do stuff like: http://www1.tsimtung.com/phpMyAdmin/sql.php?goto=/etc/passwd&btnDrop=No
I've just merged a fix against that, but it needs some testing since I do not have a machine here which is affected by this securety hole.
*G* that has been a very stupid function in the first case .. one should always watch security than coding such stuff I did not check how you fixed that but I guess the easiest way whould be to add $cfg[PmaAsoluteUri] to the $is_gotofile var so the above would result in "http://www1.tsimtung.com/phpMyAdmin/etc/passwd" an therefor fail ;-)
Thomas
Rabus wrote:
----- Original Message ----- From: "Robin Johnson" robbat2@fermi.orbis-terrarum.net
I've just had a major security hole reported to me by Colin Keigher (AnimeFreak) animefreak@users.sourceforge.net It relates to how some sites have PMA set up (they have username and password hardcoded, without any .htaccess protection).
Arg...! No comment :o)
Basically, by searching on Google for "Welcome to phpMyAdmin" or it's translated equivilents, you can find a lot of PMA installations. You can put the version number in there as well, like "Welcome to phpMyAdmin 2.3.0-rc1" Here is a sample URL to search:
http://www.google.ca/search?hl=en&ie=UTF-8&oe=UTF-8&q=%22Welcome... in+2.3.0%22&meta=
With using some of these URL's you can do stuff like: http://www1.tsimtung.com/phpMyAdmin/sql.php?goto=/etc/passwd&btnDrop=No
I've just merged a fix against that, but it needs some testing since I do not have a machine here which is affected by this securety hole.
Alexander,
you won't like me, but I think we should wait to include a fix for a "hole" until a developer can reproduce it.
Marc
On Mon, 12 Aug 2002, Marc Delisle wrote:
I've just merged a fix against that, but it needs some testing since I do not have a machine here which is affected by this securety hole.
you won't like me, but I think we should wait to include a fix for a "hole" until a developer can reproduce it.
I'm going to set up a copy of PMA that exhibits the security hole for us to test out bug. Give me a day or two, as I have some more pressing work at the moment.
Robin Johnson a écrit :
On Mon, 12 Aug 2002, Marc Delisle wrote:
I've just merged a fix against that, but it needs some testing since I do not have a machine here which is affected by this securety hole.
you won't like me, but I think we should wait to include a fix for a "hole" until a developer can reproduce it.
I'm going to set up a copy of PMA that exhibits the security hole for us to test out bug. Give me a day or two, as I have some more pressing work at the moment.
Robin,
the "goto" problem?
Marc
On Mon, 12 Aug 2002, Marc Delisle wrote:
On Mon, 12 Aug 2002, Marc Delisle wrote:
I've just merged a fix against that, but it needs some testing since I do not have a machine here which is affected by this securety hole.
you won't like me, but I think we should wait to include a fix for a "hole" until a developer can reproduce it.
I'm going to set up a copy of PMA that exhibits the security hole for us to test out bug. Give me a day or two, as I have some more pressing work at the moment.
Robin,
the "goto" problem?
Marc
I've checked out the goto problem, and you were right, it is fixed in the recent releases. It now limits you to files only in the phpMyAdmin install directory. Which can still be a problem in itself I think.
On checking out the other problem with systems totally open using the config mechanism, try out this series of SQL Commands:
First time around: CREATE TABLE testB ( t mediumtext ); LOAD DATA INFILE '/home/robbat2/public_html/PMA/config.inc.php' INTO TABLE testB FIELDS TERMINATED BY '\n' LINES TERMINATED BY '\n';
Where you need to change the path of the file, and the 'TERMINATED BY' parts for your own systems.
When that completes, I ran this: SELECT * FROM testB WHERE t like '%Server%' AND (t like '%user%' or t like '%password%');
To get just the PMA authentication data.
Of course, this exploit requires that the user have the FILE privilege. This would apply to all cases where PMA has been set up with the user as root, or anybody else with the FILE privilege.
I'm carrying on looking for more holes along these lines.
Robin Johnson wrote:
On checking out the other problem with systems totally open using the config mechanism, try out this series of SQL Commands:
First time around: CREATE TABLE testB ( t mediumtext ); LOAD DATA INFILE '/home/robbat2/public_html/PMA/config.inc.php' INTO TABLE testB FIELDS TERMINATED BY '\n' LINES TERMINATED BY '\n';
This fails if the config file is chmod 660, as suggested by faq [4.2].
Robin Johnson wrote:
Hi Guys,
I've just had a major security hole reported to me by Colin Keigher (AnimeFreak) animefreak@users.sourceforge.net It relates to how some sites have PMA set up (they have username and password hardcoded, without any .htaccess protection).
Basically, by searching on Google for "Welcome to phpMyAdmin" or it's translated equivilents, you can find a lot of PMA installations. You can put the version number in there as well, like "Welcome to phpMyAdmin 2.3.0-rc1" Here is a sample URL to search: http://www.google.ca/search?hl=en&ie=UTF-8&oe=UTF-8&q=%22Welcome...
With using some of these URL's you can do stuff like: http://www1.tsimtung.com/phpMyAdmin/sql.php?goto=/etc/passwd&btnDrop=No
Can a developer reproduce this problem? I tried and could not. I even put my PHP in non-safe mode.
Robin Johnson wrote:
Hi Guys,
And other nefarious things. I found a few sites where I could access their entire database with full rights, even some where they have configured the user to root and I could change the mysql database.
I know at least one distribution of Linux that installs MySQL with user root and no password.
Let's add a red warning when we detect that they are using 'config' auth mode, with a blank password, to try to educate the admin of this system.
This is what we need to do to fix it:
- All served up pages should contain directives to instruct search robots
not to index the files. This will stop so many sites being listed in the search engines.
- We should deprecate the user/password standard login, or add a bit of
technology to it. We should throw up a login page of our own, that should authenticate against a user/password pair in an array inside the configuration file. It might be possible to keep the automatic login of user/password, but it should not be enabled by default, for security. And the configuration option to turn that unsecure method back on should have huge warnings around it.
----- Original Message ----- From: "Marc Delisle" Delislma@CollegeSherbrooke.qc.ca
Robin Johnson wrote:
Hi Guys,
And other nefarious things. I found a few sites where I could access
their
entire database with full rights, even some where they have configured
the
user to root and I could change the mysql database.
I know at least one distribution of Linux that installs MySQL with user root and no password.
MySQL ships with this configuration as default to make the first access easy. But of course this is not meant to be left like this after the server has been configured.
Let's add a red warning when we detect that they are using 'config' auth mode, with a blank password, to try to educate the admin of this system.
I agree.
Alexander
Rabus wrote:
----- Original Message ----- From: "Marc Delisle" Delislma@CollegeSherbrooke.qc.ca
Robin Johnson wrote:
Hi Guys,
And other nefarious things. I found a few sites where I could access
their
entire database with full rights, even some where they have configured
the
user to root and I could change the mysql database.
I know at least one distribution of Linux that installs MySQL with user root and no password.
MySQL ships with this configuration as default to make the first access easy. But of course this is not meant to be left like this after the server has been configured.
Let's add a red warning when we detect that they are using 'config' auth mode, with a blank password, to try to educate the admin of this system.
I agree.
Done!
-
"Thomas Bähr [Office]" -
Marc Delisle -
Marc Delisle
-
Rabus -
Robin Johnson