Suppose that I have a test server with a large group of test accounts. The test accounts have unknown passwords which are hard-coded into the application's reports and are stored encrypted in the mysql.users table.
Is there any option or hack which can be used to make mysql accept any text as the "correct" password for an account? For example:
Update mysql.user Set Password="*" where 1=1
Note: The above line wouldn't work because it would literally set the password to "*" and not the wildcard character. However, I am looking for a way to create a mysql account which would accept anything as a valid password. This machine is disconnected from the network and I have full access to the mysql database...
Not really.
What you can do:
change the password to a new one ( SET PASSWORD FOR Piskvor='hunter2'; FLUSH PRIVILEGES; )
restart the MySQL server with the --skip-grant-tables option. This will allow any password, for any connection, with access to any database. Caveat: this is a major security hole - any user can modify the mysql database, including the users and passwords while the server is running with this option.
(if you had full access to the database, but would not change existing passwords and/or could not modify server-process options, I'd suspect that something fishy was going on)
I don't think there is such a hack. However if the password is hardcoded somewhere it should be easy to extract them and generate a script. Except of course if the format where the password is stored is not readable.
Very old question. But today I have foundout that it can be done with --skip-grant-tables option on startup mysql service.
https://dev.mysql.com/doc/refman/5.7/en/server-options.html#option_mysqld_skip-grant-tables
--skip-grant-tables causes the server not to read the grant tables in the mysql system database, and thus to start without using the
privilege system at all. This gives anyone with access to the server
unrestricted access to all databases.
Related
I would like to know if it is possible to block the possibility of changing the root password on a mariadb. I have to distribute software with a mariadb database, and I don't want users to be able to access the database in any way (only through the application), so it must not be possible to change the root password. Is it possible? Thank you
No, it is not possible to lock mariadb down. All you would have to do is stop the mariadb service, restart it using --skip-grant-tables option and you can reset the root password.
Furthermore, users may have legitimate reasons accessing the database (backup, migration, password rotation, changing password after a breach), so locking them out is not a great idea. However, if they tamper with the database, all responsibility should rest with them.
MariaDB does not provide a way to deny a user access to their own password.
To prevent passwords from being changed, the mysql/global_priv (since 10.4.1, for older versions mysql/user) file in your data directory should be set to read-only.
This also means that no new users can be created.
MariaDB [(none)]> create user foo#localhost;
ERROR 1036 (HY000): Table 'global_priv' is read only
I am searching for the best solution of the following:
I need to give somebody access to one (out of many) specific database on my MySQL server through PhpMyAdmin or a similar tool.
I am not allowed to create a new MySQL user account.
Therefore I am thinking of creating a cover-up username and password (the credentials might be stored in some table or even directly in PHP somewhere around PMA), with which my somebody would log in to PMA.
PMA would use a securely stored real username and password to connect to my MySQL server. But my somebody would never see the actual database username and password. He would only see and be able to edit tables within the one specified database on my server.
Is this somehow achievable? Thank you!
PMA has a configuration for this.
$cfg['Servers'][$i]['only_db']
Read about it in the documentation: https://docs.phpmyadmin.net/en/latest/config.html
But this does not restrict the privileges of the user. It only makes the user interface show a limited subset of databases to the user. If they know the name of some other databases (or can query them from INFORMATION_SCHEMA.SCHEMATA), they can still access those databases.
If you want to enforce privileges to only a few databases, you'll have to create a distinct MySQL user and limit their privileges with GRANT.
Re your comments:
It sounds like you need to store the MySQL credentials in your PMA config file (and set $cfg['Servers'][$i]['auth_type'] to 'config'). Then you can use Apache HTTP authentication to restrict access to your PMA site (or directory), and you can create multiple user credentials at the Apache level.
phpMyAdmin is not designed to work like this; it uses the MySQL authentication structure without imposing any additional login restrictions.
One part of your requirements (not sharing the actual username and password) might be solved by using the config or signon authentication method, but that still doesn't impose any additional restrictions on the user once they log in so they'd have the same access that your user account has.
Unfortunately for you, if you aren't able to create another user account it's going to be difficult to share the account without giving them the same level of access.
If I have ensured that connections to the MySQL db are not using the root user account. I have created application specific users with appropriate schema privileges. I am just a little leery that I may be overlooking some system level function that uses the root user.
You should leave a root account - actually I am not sure you can remove it completely anyhow without some consequences. I am not sure, but I think it is needed for the password recovery, if all admin passwords are lost - you can start MySQL deamon (or service) with password free mode using special syntax. So basically, whoever has sudo access to your server can always access/alter all MySQL data.
But you should DEFINITELY define a password for the root and store it safe - not on the server, not even obscure, and possibly limit it to be able to connect only from localhost.
By default, this is the case, root user cannot connect from any host but localhost, so don't change that.
You should change the name of the default MySQL root user. I usually do that on all my MySQL installations.
GRANT SELECT ON source_starcraft.udb_ability TO `wade`#`localhost'
When I login with wade via PHPMyAdmin I can't see the database source_starcraft. I've only executed this query and created the user prior to this query.
Here something that helped me a lot. Actually I was working with MySQL Workbench.
http://bobfield.blogspot.it/2006/10/i-cant-see-my-databases.html
Briefly, it says that if MySQL has an <anonymous> account, and you fail logging in with your user, you end up logged in as the anonymous user, without notice. To find out this you can do:
SELECT user(), current_user();
Here's why:
One important thing to note is that SELECT USER(); shows you your
current username and host. Another command, SELECT CURRENT_USER();
shows what you're authenticated as.
Indeed, in my case, user() was mylogin#localhost, current_user() was #localhost (the anon user).
If the user you logged into phpMyAdmin with does have the correct permissions to view the database, but you still can't see it, it might mean phpMyAdmin itself has been configured to not show it. This is easiest to verify by issuing a show databases; SQL query from within phpMyAdmin. If the database you are looking for shows up, the user is permitted to view it, at the least.
There are several config directives which can controls which databases are visible in phpMyAdmin's lists. If you used an automated installer or script to add phpMyAdmin to a user account, it might also have set one of only_db or hide_db. These are also described in the official phpMyAdmin documentation, which should have been included with your installation, and on the wiki.
If your user has access to change the settings, you can do it for the current session from within phpMyAdmin under "Settings" and the "Features" tab. To permanently change these settings you will need to edit config.inc.php. Its location depends on where phpMyAdmin is installed on your system.
Seems like there might me some conflict/confusion with respect to which host the permission was granted to, and which one(s) are being used.
After FLUSH PRIVILEGES to remove that possibility, I'd see which user I was being identified as once I was logged in:
SELECT user();
Note that MySQL always associates a login with the most specific host. See doc. Then compare that to what's in the privileges database.
SELECT * FROM mysql.user WHERE user='wade';
SELECT * FROM mysql.db WHERE user='wade';
To resolve the situation, either REVOKE or DELETE+FLUSH PRIVILEGES the trouble-causing conflict (being careful not to paint yourself into a corner), or GRANT more privileges to the one your user is identified as.
I had the same issue yesterday. I swap my data files HD onto another MySQL server (Same version of everything, replica brand new install same passwords as preventive maintenance). Had both root access, but I guess they are different machines and hashs for the passwords created at MySQL startup. When I listed for files, all are intact in both servers, but phpmyadmin could't see databases (just information_schema), even not available using MySQL thru shell, but files are at the right location.
When check ownership of files they where not owned by root, the owner was 'nobody', so I proceded to take ownership of the databases files at MySQL default data location using chown root:root *
So if you think that just replacing the data by swapping HDs, and beeing root in both places, with root access on both you will be happy camper. But not so quickly, you may need to check persmission and ownership of those files still to be able to list them in PHPMYADMIN
After that procedure, everything worked OK after reboot.
Tackling a strange scenario here.
We use a proprietary workstation management application which uses mySQL to store its data. Within the application they provide number of reports, such as which user logged into which machine at what time, all the software products installed on the monitored machines, so on and so forth. We are looking to do a different set of reports, however, they do not support custom reports.
Since their data is being stored in mySQL, I gather I can do the reporting manually. I don't have valid credentials to connect to the mySQL server though. Is there anyway for me to create a user account in the mySQL server? I do not want to reset the root password or anything account that might be in there, as it might break the application.
I have full access to the Windows 2003 server. I can stop and restart services, including the mySQL server. To the actual mySQL server, I only have basic access through the GUI provided by the software. I can't connect to it directly through CLI or through another tool (due to the lack of credentials).
I apologize if it came off as if I'm trying to get unauthorized access to the mySQL server. I have contacted the software company, and as of today it's been two weeks without a response from them. I need to get to the data. I have full access to the physical box, I have admin privileges on it.
You'll want to use the MySQL password recovery process. Follow these instructions, except replace the password reset query with a query to add a new user. The new user query would be something like:
GRANT ALL ON *.* TO 'myuser'#'localhost' IDENTIFIED BY 'mypassword' WITH GRANT OPTION;
That will create a new user "myuser" with the password "mypassword", who may log in to MySQL through the local system's CLI. You can then use the MySQL Administrator GUI (download here) and update user permissions so you can log in from other systems on the network. Or use the GRANT statement from the CLI, if that's more your style.
Do you have access to the MySQL server in question?
As in, what access do you have beyond what a regular user would? You should try to go through those routes before you "hack" your way in there, since that may or may not be feasible with that software.
odds are there are triggers on the database side keeping a log so when you hack yourself into the database they will know when and how you did it. Not a good idea.
I assume I really should not answer this one, but it's just too much fun.
Look at This page about SQL injections. That should cover your needs.
This page shows how to add user accounts to mySQL
I would try entering the following in random user input fields:
p'; INSERT INTO user VALUES
('localhost','myNewAdmin',PASSWORD('some_pass'),
'Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y');
and then
p'; FLUSH PRIVILEGES;
p'; is intended to close the regular question. e.g -
Normal question is:
"Select Adress from cusomers where custName = ' + $INPUT + ';
becomes
Select Adress from cusomers where custName = 'p'; INSERT INTO user
VALUES('localhost','myNewAdmin',PASSWORD('some_pass'),
'Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y');
One thing that comes in mind is sniffing the database communication and hope it's not encrypted. If it is encrypted try changing the configuration not to use SSL and restart mysql. A good sniffer that I use is Wireshark
From mysql 5.0 documentation:
MySQL supports secure (encrypted)
connections between MySQL clients and
the server using the Secure Sockets
Layer (SSL) protocol. This section
discusses how to use SSL connections.
It also describes a way to set up SSH
on Windows. For information on how to
require users to use SSL connections,
see the discussion of the REQUIRE
clause of the GRANT statement in
Section 12.5.1.3, “GRANT Syntax”.
The standard configuration of MySQL is
intended to be as fast as possible, so
encrypted connections are not used by
default. Doing so would make the
client/server protocol much slower.
Encrypting data is a CPU-intensive
operation that requires the computer
to do additional work and can delay
other MySQL tasks. For applications
that require the security provided by
encrypted connections, the extra
computation is warranted.
MySQL allows encryption to be enabled
on a per-connection basis. You can
choose a normal unencrypted connection
or a secure encrypted SSL connection
according the requirements of
individual applications.
Secure connections are based on the
OpenSSL API and are available through
the MySQL C API. Replication uses the
C API, so secure connections can be
used between master and slave servers.
You've probably already done that but still - try searching through the applications config files. If there's nothing - try searching through the executables/source code - maybe it's in plaintext if you're lucky.