I'm seeking for solution to pass the password securely to MySQL client on *nix platforms while using automated script solution (i.e Bash script).
So far, I had to realize that MySQL ignores password input from stdin at all (still asks for password on terminal, crashes on automation).
The worst, solution using ~/.mylogin.cnf also doesn't work for me, it seems MySQL somehow ignores it at all.
I prefer to not to use the command line -p argument for password to prevent described "all-around" security issues.
--defaults-file and --defaults-extra-file handn't give the solution as well, seems like the password is prompted by client at "all-cost".
Therefore, I'm just running out of solutions for that primitive (at first sight) task!
Any help will be highly appreciated!
I'll try to be short in my findings:
First, the solution using mysql --defaults-extra-file="path/to/file" is actually worked for me among with --default-file option until it is passed as the first argument (as well noticed by Bill Karwin here).
Second, usage of ~/mylogin.cnf also workes fine until the file access restricted for all users except the current account the MySQL client is running under + file is restricted from execution even by current user (chmod u-x) as well, possibly treated by MySQL as a threat due to Linux GUI x permission umbrella on many systems (execute permission is enabled for user, group and others by setting one V in GUI for the file). Still this reason is just a suggestion.
Related
Context: Telephony system (Asterisk) using the MySQL C API to connect to the database to lookup the routing for a call as it comes in. The lookup involves connecting to the database, executing a query, then closing the connection.
Sometimes the very first call in the morning generates the following error:
Access denied for user 'asterisk'#'127.0.0.1' (using password: YES)
Normally this would mean the password was wrong, but that's obviously not the case here, since it uses the same user and password all the time for all the calls. It's as if the system has somehow "gone to sleep" or perhaps a file handle has become stale somewhere, so that the first attempt to the connect to the database fails, but the rest work fine. Also it only happens occasionally, so I'm unable to replicate it - very strange!
I'm using Asterisk 1.8.32 with MySQL 5.5 on Debian 8.7.
It's a bit of a headscratcher, so I would be grateful for any suggestions!
First of all it is very bad idea use 1.8.* tree at current moment becuase of security feature.
Move to 11.* fix this issue.
Also you can do following in my.cnf
interactive_timeout=
Set to any value more then 4 days(weekend)
Other option is reload mysql module by crontab every 3 hrs.
Best option(except upgrade) is move from mysql to res_odbc, which have keepalive option. res_config_mysql considering deprecated, so any new systems should use ODBC.
following Problem:
I want to Check all Open MySQL Ports in a network and give myself a list of them.
After this i want to check if i can get access to the MySQL database from the open ports.
It Would be just a security check script to avoid other people getting access to the databases.
Bash/perl/Powershell... maybe someone can give me a hint?
You can use NMAP for all port scanning tasks.
EDIT:
Lets asssume an example: mysql-vuln-cve2012-2122(This vulnerability tries to access the MySql server through open ports by bypassing authentication, if possible, also dumps the MySQL usernames and password hashes.)
Pre-requisite: You need the 'Vulns' library to be installed separately. Please read the documentation, to know more about how to install and other details, since it would be too tedious to explain it here.
mysql-vuln-cve2012-2122.pass
MySQL password. Default: nmapFTW.
mysql-vuln-cve2012-2122.user
MySQL username. Default: root.
mysql-vuln-cve2012-2122.iterations
Connection retries. Default: 1500.
mysql-vuln-cve2012-2122.socket_timeout
Socket timeout. Default: 5s.
Please leave the password blank to check for non-password vulnerabilities.
Command to run:
nmap -p3306 --script mysql-vuln-cve2012-2122 <target>
Here is your MySql instance
This will give an output, something like this:
PORT STATE SERVICE REASON
3306/tcp open mysql syn-ack
mysql-vuln-cve2012-2122:
VULNERABLE:
Authentication bypass in MySQL servers.
State: VULNERABLE
IDs: CVE:CVE-2012-2122
Description:
When a user connects to MariaDB/MySQL, a token (SHA
over a password and a random scramble string) is calculated and
compared
with the expected value. Because of incorrect casting, it might've
happened that the token and the expected value were considered
equal,
even if the memcmp() returned a non-zero value. In this case
MySQL/MariaDB would think that the password is correct, even while
it is
not. Because the protocol uses random strings, the probability of
hitting this bug is about 1/256.
Which means, if one knows a user name to connect (and "root"
almost
always exists), she can connect using *any* password by repeating
connection attempts. ~300 attempts takes only a fraction of
second, so
basically account password protection is as good as nonexistent.
Disclosure date: 2012-06-9
Extra information:
Server granted access at iteration #204
root:*9CFBBC772F3F6C106020035386DA5BBBF1249A11
debian-sys-maint:*BDA9386EE35F7F326239844C185B01E3912749BF
phpmyadmin:*9CFBBC772F3F6C106020035386DA5BBBF1249A11
For more and detailed info, please refer the above link.
The NMAP tools will not only help you in getting the list of port related vulnerabilities. It can also be used to search for other vulnerabilities like MySql injection,DDOS, brute force vulnerabilities and lot more. Though you need to download separate libraries for those.
I have written several shell scripts with tcl/tk and I run it on the machine with the user group, when I give it to another user with different machine or from another IP it gives error.
Spawn/bin/bash
But if I run it from my machine where I wrote it, it runs correctly.
The header is so defined.
#! / Usr/bin/expect -f
#
Can you tell me that I have not added or am missing so that it can run from any pc and any user?
From the question you have posted, it looks like to me one or more of following issues. Apart from that the real problem looks to me is in /bin/bash. Check manually once in the machine where the problem lies.
First check manually from other machine where the issue is present. Checking is easy.
which expect
expect
spawn /bin/bash
Have you got the error? Also check if there is -
Difference in expect version
Permission issue
Have you considered the scenario where you are prompted for storing RSA key? Relevant in case you are connecting to other machines from the host you are running the program.
Thank,
Mr. Bordoloi
I'd like to connect to a MySQL server (AWS RDS, if you must know) via SSL. I'm familiar with the basic mechanics involved.
All the methods I've seen so far involve running a SQL query to determine that the current connection uses SSL.
My concern is that this is a "chicken and egg" problem: I would need to send my credentials to the server potentially in plain text, so I can run a query on the server to determine that it was not plain text.
Is there a way to run the SHOW STATUS LIKE 'Ssl_cipher'; query without first authenticating?
This seems like a pretty basic requirement (I'd like to know that my password will be encrypted BEFORE sending it over the wire) but it seems difficult to find the required information.
I've read the following resources:
https://kb.berkeley.edu/page.php?id=23112
http://dev.mysql.com/doc/refman/5.1/en/ssl-options.html
http://dev.mysql.com/doc/refman/5.0/en/creating-ssl-certs.html
MySQL native authentication was never sending password over network without regard of SSL usage (it always sends result of function of password and salt returned from Server instead).
In recent versions it may be beneficial to send clear text password - but that may happen only if you explicitly provide option (on client) --enable-cleartext-plugin (or similar).
I have a web application that runs queries on the database. The application is trying to run a query, and send the results to the an output file. I have confirmed that the issue is actually a permission denied (error 13) problem, not an issue with any other part of the query. A simplified form of the query follows:
SELECT 'anything'
INTO OUTFILE '/var/www/html/sl/filestore/dbadpt_database.tmp'
FROM INFORMATION_SCHEMA.TABLES;
This query runs fine when I remove the INTO OUTFILE line. I have tried every permissions setting for this dir that I can think of. I have even changed the permission to 777, and gotten the same results. (Yes, I know 777 is not secure. Just did it for testing) I have tried every ownership combination of 'root', 'apache', and 'mysql' that I could think to try for this dir. I have pasted the above query into the MySQL command-line tool, and it has produced the same results.
We are running CentOS 5.5. The web server running the application is Apache 2. I cannot create the file ahead of time, nor can I change the directory that the program is trying to write to.
I would hazard a guess that problem is with SELinux.
The first thing I would try would be setenforce 0 and see if that fixed it. It will only fix the symptoms (you still need to reconfigure SELinux to allow what you need), but it will at least confirm whether that's the problem or not.