auxiliary/scanner/mysql/mysql_login missing default username or incorrect description

[digininja]

Steps to reproduce

Using the auxiliary/scanner/mysql/mysql_login module, the description says:

This module simply queries the MSSQL instance for a specific user/pass (default is sa with blank).

But the default settings don't have the username set to sa so running the module fails.

Expected behavior

The module should set the default username to sa or it should not run if no username or username file is configured.

Current behavior

Running it after just setting the RHOSTS value results in the following error:

[*] 10.2.3.4:1433    - 10.4.5.6:1433 - MSSQL - Starting authentication scanner.
[*] Error: 10.2.3.4: Metasploit::Framework::LoginScanner::Invalid Cred details can't be blank, Cred details can't be blank (Metasploit::Framework::LoginScanner::MSSQL)

Setting the USERNAME to sa, the module runs fine.

System stuff

Metasploit version

19fa008b4321a06cac0ec0fb1cc85d64f4129430 (HEAD -> master, origin/master, origin/HEAD) Land #12856, whitespace cleanup in cracker lib

I installed Metasploit with:

• Kali package via apt
• Omnibus installer (nightly)
• Commercial/Community installer (from http://www.rapid7.com/products/metasploit/download.jsp)
• [X ] Source install (please specify ruby version)

ruby 2.5.7p206 (2019-10-01 revision 67816) [x86_64-linux-gnu]

OS

Kali rolling.

[h00die]

Looks to be true: https://github.com/rapid7/metasploit-framework/blob/master/modules/auxiliary/scanner/mssql/mssql_login.rb
Also of interest, the mysql module (referenced accidentally i believe) says similar about root no password, but has no username in it as well.
https://github.com/rapid7/metasploit-framework/blob/master/modules/auxiliary/scanner/mysql/mysql_login.rb

[bcoles]

These changes seem reasonable to me.

I believe USERNAME and USER_FILE will be merged if both options are present, so setting a default USERNAME probably won't result in unexpected behavior.

I believe enabling blank passwords by default is also reasonable, given that they are permitted and the default for the privileged root / sa accounts.

As an aside, I ran into another issue:

msf5 auxiliary(scanner/mysql/mysql_login) > run

[+] 127.0.0.1:3306        - 127.0.0.1:3306 - Found remote MySQL version 5.5.5
[!] 127.0.0.1:3306        - No active DB -- Credential data will not be saved!
[-] 127.0.0.1:3306        - 127.0.0.1:3306 - LOGIN FAILED: root: (Unable to Connect: unknown charset number: 45)
[*] 127.0.0.1:3306        - Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf5 auxiliary(scanner/mysql/mysql_login) > mysql -h localhost -u root -p
[*] exec: mysql -h localhost -u root -p

Enter password:        # <-- I provided no password - password is blank
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 64
Server version: 10.3.22-MariaDB-1 Debian buildd-unstable

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> 

Seems the MySQL libraries might not support MariaDB ?

[h00die]

I noted some other inconsistencies with it as well. For instance, if the account is set to only localhost login, you get the error for a bad login, but I think it should actually tell you that its a valid account, but can't login from this host. Then, in theory, skip the rest of that username testing.
I also see it detected 5.5.5 (assuming thats an else case) when it was maria 10.3.22.

[digininja]

I've finished the testing I was doing where I picked this up, but agree the changes look good. On the localhost issue, I've seen a problem that might be related when fixing DVWA issues. In some situations, localhost and 127.0.0.1 are not treated the same. I could be wrong, but I've got memories of the client looking at pipes rather than the network socket if you specify localhost. It is unlikely in the real world that someone will have Metasploit on the same box that they are scanning so not sure if this would be an issue worth spending much time fixing. One last thought, can you remotely pull the database version, or even if it is mysql vs mariadb without successfully connecting? Again, I looked at it for debugging DVWA issues and have memories of not being able to find a way, all I could get were the client library versions. This might account for the discrepancy you see in that example.

…

On Sat, 15 Feb 2020, 12:12 h00die, ***@***.***> wrote: I noted some other inconsistencies with it as well. For instance, if the account is set to only localhost login, you get the error for a bad login, but I think it should actually tell you that its a valid account, but can't login from this host. Then, in theory, skip the rest of that username testing. I also see it detected 5.5.5 (assuming thats an else case) when it was maria 10.3.22. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#12891?email_source=notifications&email_token=AAA4SWKIRCT4JQSQZOBQW6TRC7L4LA5CNFSM4KNJ65TKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3JB2Y#issuecomment-586584299>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA4SWLDYJ3W5NXPKB4LN7LRC7L4LANCNFSM4KNJ65TA> .

[bcoles]

On the localhost issue, I've seen a problem that might be related when
fixing DVWA issues. In some situations, localhost and 127.0.0.1 are not
treated the same.

You are correct.

root@kali:~/Desktop/metasploit-framework# mysql -h 127.0.0.1 -u root -p
Enter password: 
ERROR 1698 (28000): Access denied for user 'root'@'localhost'
root@kali:~/Desktop/metasploit-framework# mysql -h localhost -u root -p 
Enter password: 
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 79
Server version: 10.3.22-MariaDB-1 Debian buildd-unstable

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> 

[digininja]

Woo!

…

On Sat, 15 Feb 2020, 12:37 bcoles, ***@***.***> wrote: On the localhost issue, I've seen a problem that might be related when fixing DVWA issues. In some situations, localhost and 127.0.0.1 are not treated the same. You are correct. ***@***.***:~/Desktop/metasploit-framework# mysql -h 127.0.0.1 -u root -p Enter password: ERROR 1698 (28000): Access denied for user 'root'@'localhost' ***@***.***:~/Desktop/metasploit-framework# mysql -h localhost -u root -p Enter password: Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 79 Server version: 10.3.22-MariaDB-1 Debian buildd-unstable Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. MariaDB [(none)]> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#12891?email_source=notifications&email_token=AAA4SWMEY3ALUOBGKLTRNKDRC7OX3A5CNFSM4KNJ65TKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3JQ2Q#issuecomment-586586218>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA4SWP5FIGITOKY4DPFPD3RC7OX3ANCNFSM4KNJ65TA> .

[bcoles]

I noted some other inconsistencies with it as well. For instance, if the account is set to only localhost login, you get the error for a bad login, but I think it should actually tell you that its a valid account, but can't login from this host. Then, in theory, skip the rest of that username testing.
I also see it detected 5.5.5 (assuming thats an else case) when it was maria 10.3.22.

If possible, it would be good if it reported the username as valid.

Outside the scope of this PR.

I haven't tested the MSSQL module, but the changes look good to me. I think this is good to land?

[h00die]

believe so

[papihuncho]

Hey guys ...am new to metasploit and am tying to use this module to test mysql server which is running in Ubuntu desktop 18.04 TLS but am getting this error...
am runnig Metasploit-framework on MacOS mojave v 10.14.6

Module options (auxiliary/scanner/mysql/mysql_login):

Name Current Setting Required Description

---

BLANK_PASSWORDS true no Try blank passwords for all users
BRUTEFORCE_SPEED 5 yes How fast to bruteforce, from 0 to 5
DB_ALL_CREDS true no Try each user/password couple stored in the current database
DB_ALL_PASS true no Add all passwords in the current database to the list
DB_ALL_USERS true no Add all users in the current database to the list
PASSWORD no A specific password to authenticate with
PASS_FILE ~/Desktop/passwords.text no File containing passwords, one per line
Proxies no A proxy chain of format type:host:port[,type:host:port][...]
RHOSTS xxx.xxx.x.xx yes The target host(s), range CIDR identifier, or hosts file with syntax 'file:'
RPORT 3306 yes The target port (TCP)
STOP_ON_SUCCESS false yes Stop guessing when a credential works for a host
THREADS 1 yes The number of concurrent threads (max one per host)
USERNAME root no A specific username to authenticate as
USERPASS_FILE no File containing users and passwords separated by space, one pair per line
USER_AS_PASS false no Try the username as the password for all users
USER_FILE ~/Desktop/users.text no File containing usernames, one per line
VERBOSE true yes Whether to print output for all attempts

msf5 auxiliary(scanner/mysql/mysql_login) >
msf5 auxiliary(scanner/mysql/mysql_login) > run

[+] xxx.xxx.x.xx :3306 - xxx.xxx.x.xx :3306 - Found remote MySQL version 5.5.5
[-] xxx.xxx.x.xx :3306 - xxx.xxx.x.xx :3306 - LOGIN FAILED: root: (Unable to Connect: unknown charset number: 45)
[-] xxx.xxx.x.xx :3306 - xxx.xxx.x.xx :3306 - LOGIN FAILED: root:password (Unable to Connect: unknown charset number: 45)
[-] xxx.xxx.x.xx :3306 - xxx.xxx.x.xx :3306 - LOGIN FAILED: root:mysql (Unable to Connect: unknown charset number: 45)
[] Scanned 1 of 1 hosts (100% complete)
[] Auxiliary module execution completed