Testing Script - Find open MySQL Ports and check Database - mysql

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.

Related

How to pass the password securely to MySQL Client with automation

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.

Initial database connection error at the start of the day

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.

Is there a way to determine MySQL SSL connectivity without authentication?

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).

Auto-Discourage MySQL brutforce login attempts

I noticed in one of my MySQL server that a remote attacker tried around 2000 login attempts in one night using 'root' and 'admin' usernames over 'mysql' system database. Luckily, I had setup mysql's query-log into a file log for monitoring purpose, and the passwords were difficult.
My database server survived that attack, even though it received almost one login attempt per second during the off-hours at (night).
There were around 10 different IPs with the same attack behavior all together, most of them having 'good reputation' in blacklist checking.
In this case, changing the database password may not be a good protective idea.
Is there a way to discourage such mis-behavior? For example, if there are about 5 wrong login attempts in short time, deny them the service?
How do MySQL experts handle this attack in case the MySQL port is open for remote login?
A lot of servers might be facing this kind of silent login attempts.
I recommend Fail2Ban. This is a script that watches logfiles for any patterns (e.g. failed logins) and creates then a firewall rule to prevent that IP to access your server. You can configure how many failed logins are necessary and for how long the access should be denied before the firewall rule is removed.
With fail2ban you can also watch ssh logins, mail accounts or event your own web-application logfile for malicious logins/behaviour.
As a general hint: rename your root/admin account to something else, so that they will never success anyway and change the public mysql port of your server (which is both just obscurity, but no real security). Also you should disable remote login for accounts (which is security).

Restricting MySQL connections from localhost to improve security

I heard that anyone that knows my MySQL Username and Password can access it, Even if it's listening only to localhost.
Supposing my info is as following:
USER: root
PASS: 123456
Host: LOCALHOST (only)
How is it possible that anyone out there (local) can access it?
If you restrict access from remote hosts to your usernames and passwords then someone won't be able to access the database externally.
You could also configure your firewall to only allow traffic to 3306 (MySQL Default Port) from the localhost machine.
Update
To setup your user so they can only access through LOCALHOST use:
GRANT ALL PRIVILEGES ON *.* TO db_user #'localhost' IDENTIFIED BY 'db_passwd';
GRANT ALL PRIVILEGES ON *.* TO db_user #'127.0.0.1' IDENTIFIED BY 'db_passwd';
Also, bind your MySQL server to the local address. You can do this by editing the [mysqld] section of my.cnf:
[mysqld]
bind-address = 127.0.0.1
you can block direct access to MySQL at the firewall or within MySQL itself, but the most likely way you'd be hacked is through an insecure web application - in that situation the attacker would most likely be able to read your database login and connect from the server.
So keep your applications secure - keep everything updated, don't allow file uploads, use suPHP if you have multiple accounts etc.
If you restrict your mysql application follow this steps:
1.You could just block port 3306. If the site is on the same server then it will still be able to access the database using localhost as the hostname.
2.Just add "bind-address = 127.0.0.1" to the "[mysqld]" section of their my.cnf file to restrict access to localhost only.
Most of people use this type of restriction.
This is an older question that I stumbled across, but if Darkeden had phpMyAdmin or similar running, anyone can log in to that using valid MySQL credentials.
If it was compromised, then in addition to restricting connections, change all passwords.
I didn't see an answer that answered his (adjusted) question - he has locked it to localhost and the attacker is still getting in.
If you have truly restricted it to local host (check using netstat -an | egrep 3306 to check it is listening to 127.0.0.1 not 0.0.0.0),
then the only way of accessing it is to originate a connection from that local host.
Initial steps to take:
probably rebuild a replacement system from scratch and hardening it before you make it publicly accessible (having a repeatable recipe eg using ansible will help as you may have to go through a few iterations to learn how he gets in)
Check with reputable security scanners what you obvious holes are,
Get help from a security professional (depends if you want to spend $ or time and frustration to fix)
Apply security patches,
Remove services you don't need,
restrict the database access to only those programs that need it,
redo all your passwords,
check for installed root kits, and other viruses,
secure your server if at your own office and train staff in handling social engineering,
use a service that will monitor and filter the requests coming through and deny direct access (eg use cloudflare as a cheep starting point)
check for keyboard loggers (physical and software and other viruses) on all machines used to access the server),
check for physical means of logging your keystrokes in accessing your server (eg web cam style used in atm), the more exotic include sound (https://en.wikipedia.org/wiki/Acoustic_cryptanalysis), typing with a nearby wifi access point (eg https://www.schneier.com/blog/archives/2016/08/keystroke_recog.html)
Add an audit trail and monitor database activity to work out how he is getting through, but at least you need to do all the obvious securing first because otherwise he will just hop from one security hole to another
He could be also getting through using:
accessing via some program you are running (eg a web server) that is externally accessible and has a security hole that allows him to run arbitrary sql commands through its existing database connection - see https://www.w3schools.com/sql/sql_injection.asp
tricking some program he has access to from outside to proxy a connection for him to localhost:3306 (eg through a miss-configured network firewall on the machine)
tricking some program to run a local program (bash. mysql etc), and from there gaining access to the database - buffer overflows and other specially crafted data is a common issue to running arbitrary code
man in the middle attack on a connection that has legitimate access
bugs in a program that is automatically or manually processing data from outside, eg email, processing of postscript/pdf/any document with scripting processing - even viewing a text file can be dangerous - see https://www.proteansec.com/linux/blast-past-executing-code-terminal-emulators-via-escape-sequences/
social engineering a way through getting people to give you access
managing to get a hardware device attached to a computer that has access (how many people will pick up a "memory stick" lying in the work car park and check it out instead its a "programmable keyboard", and ALL computers trust keyboards!)
and then many more all the other sorts of methods I don't know, but those that are involved share ...
Just remember that you need to have practical security, I think xkcd says it just right: https://xkcd.com/538/