A security audit was performed on my network and the auditor flagged an issue which he feels is a high-level threat regarding our MySQL 5.7.24 installation on an IIS server.
When browsing to http://%myIP%:3306 the visitor receives the following message:
[���5.7.24-log�C���.m[aUg&$�ÿ÷�€����������p;}fQ^Z?Ia�mysql_native_password�!��ÿ„#08S01Got packets out of order
The auditor feels that MySQL is possibly revealing a user name or password in this response.
I doubt this is the case, but wanted to get responses from the experts.
Also, is this (what appears to be a login prompt) necessary? Is there a way to turn this response off?
Some things:
Using unencrypted rather than TLS-encrypted MySQL connections is a far bigger vulnerability than MySQL responding with error gibberish when you hit it like it's a web server. Badguys can sniff your customer data.
You should consider firewalling your MySQL instances so they can only be hit from the machines needing their services. If this audit probe comes from the public network, this is definitely something you must remediate. "True positive."
MySQL here announces its available authentication method (mysql_native_password). It also indicates its confusion upon receiving HTTP protocol data rather than MySQL protocol. packets out of order. So it is functioning as designed and revealing nothing except that it is MySQL. "False positive."
If this auditor insists this is still a problem after you explain it, then you should consider switching to TLS connections to your MySQL instances.
For what it's worth, I've never seen an auditor who knew much about protocols other than HTTP/S.
Related
I'm finishing a system at work that makes calls to mysql server. Those calls' arguments reveal information that I need to keep private, like vote(idUser, idCandidate). There's no information in the db that relates those two of course, nor in "the visible part" of the back end, but even though I think this can't be done, I wanted to make sure that it is impossible to trace this sort of calls, with a log or something (calls that were made, or calls being made at the moment), as it is impossible in most languages, unless you specifically "debug" in a certain way, while the system is in production and being used. I hope the questions is clear enough. Thanks.
How do I log thee? Let me count the ways.
MySQL query log. I can enable this per-session and send everything to a log file.
I can set up a slave server and have insertions sent to me by the master. This is a significant intervention and would leave a wide trace.
On the server, unbeknownst to either Web app and MySQL log, I can intercept communications between the two. I need administrative access to the machine, of course.
On the server, again with administrative access, I can both log the query calls and inject a logging instrumentation into the SQL interface (the legitimate one is the MySQL Audit Plugin, but there are several alternatives, developed for various purposes by developers over the years)
What can you do? You can have the applications use a secure protocol, just for starters.
Then, you need to secure your machine so that administrator tricks do not work, and even if the logs are activated, nobody can read them and you can be advised of any new and modified file to delete it promptly.
I'm developing a HTML5 Websocket-Based application which should notify the users in real-time about different events. The client connect to the server, send a handshake with some securitytoken, the server check if the securitytoken is valid and add the client to the list of active clients. Now he get notifications on special events.
Because there are different notifications from multiplice applications, there is a notification-core where handle the basics of the connection and also the authentification because this is always the same. The core can be accessed from applications, with them they can communicate to the server.
Does it make sense or is it necessary to insert some limitations in the core? For example tracking the user-ip and refuse the connection if the user has more than lets say 3 connections to the server in the last 10 seconds to prevent flood-attacks.
In my oppinion I think it can reduce serverload if someone try to crash my service by holding the F5 key or using some botnet as long as he isn't sending so much traffic to my server that my connection can't handle that much.
I'm using socket.io if this is important.
If you're trying to protect your application from malicious attacks, there are many, many things you would need to consider and it is important to prioritize those things and spend your development time on the things that could most impact your service. I would think that creating multiple webSocket connections would be very low on the priority list way behind operations in your service that actually change state such as cause writes to a database, etc... Modern servers can easily hold tens of thousands of sockets and it costs little server load to just be sending the same notification to lots of sockets.
In addition, using the IP address as something to limit by can cause problems because larger organizations may use NAT to share a single IP address among many users for outbound connections. If you are going to limit by user, it's much better to limit by a userID (something each user uniquely logs in with).
I have an encrypted connection from my ios app to my mysql database. My question is whether or not they would be able to intercept the connection form the ios app and find the domain with or without an encryption
whether or not they would be able to intercept the connection form the ios app
Yes, they would be able to do so. At least surely using a jailbroken device - for jailbroken devices, there are a couple of factors that make hacking easier.
On the one hand, on a jailbroken system, it is possible to prevent Apple's encryption of the app executable (by dumping the unencrypted program code from memory to the disk) and run a utility called "class-dump" to obtain the Objective-C class information (it is also possible to use the GDB debugger on the device or IDA Pro in order to reverse engineer the application logic).
On the other hand, the same MobileSubstrate library that is used for making iOS tweaks can be used to alter the behavior of any given application (I have successfully used this technique for circumventing some code obfuscation at runtime), so in theory an attacker would alter the communication logic of your application and dump the unencrypted data of yours and your users.
On the gripping hand, most standard and less-used Unix utilities usable for such kind of hacking are ported/compiled for jailbroken iOS - including the popular network sniffing tool nmap, the "John the Ripper" password cracker, the infamous aircrack-ng WEP/WPA key cracker, the GNU debugger (GDB), etc. These are also useful for executing an attack you described.
If the connection itself is encrypted, then, in theory, your data should be safe while in the wire. This still doesn't prevent the MobileSubstrate-based approach to exploitation. It is also true that the IP address of the server you're connecting to can be found relatively easily (end even the domain it is matching, since there are also known techniques for obtaining reverse-DNS information using a known IP address).
I'm not sure if this is possible without a jailbreak, but a similar man-in-the-middle attack was performed against Apple's in-app purchases by a Russian hacker (effectively rendering ineffective the underlying payment system and allowing purchases to be freely downloaded), merely by requiring users to install SSL certificates, profiles and using the hacker's own proxy server, so I'd suspect it is possible even without a jailbreak. Note that in this case the connection was also encrypted, and it was not the encryption that mattered.
You should not imo create a direct connection to the mysql-database but instead pursue a connection with a server program/api with a connection to the database in question. To answer the question more directly users should not be able to intercept the connection from the ios-app if it is encrypted correctly but still, is it worth that risk?
If the connection is encrypted, the data are secure. But not the domain. The iPhone is connecting to an IP Address, and that IP Address is obviously not encrypted.
Create a PHP interface between your app and the Mysql. Doing this they will be able to hack only app-accounts not the entire database! Your Mysql credential will be stored in the remote domain where the PHP code runs.
My users are using MS Access and ODBC connector to connect to my remote MySQL database. I wonder how secure this is, in the sense of possible password disclosure to 3rd party. Is the mysql protocol authentication safe to eavesdropping or even man-in-the-middle attacks? I would be quite happy with safety against eavesdropping. Note that my concern is only authentication, I'm not concerned about data disclosure.
Please don't reply that I should use SSL. I know this would be ideal however the setup doesn't seem very simple. Anyway, I would like to know what is the safety level of plain mysql protocol.
What is it that you want to be "safe to eavesdropping or even man-in-the-middle attacks"? Your password, or your data?
The title of your question refers specifically to authentication. MySQL does a reasonable job of protecting your password from eavesdroppers (it is not sent plaintext, and the use of a nonce defeats replay attacks). Citing MySQL protocol internals:
MySQL 4.1 and later
Remember that mysql.user.Password stores SHA1(SHA1(password))
The server sends a random string (scramble) to the client
the client calculates:
stage1_hash = SHA1(password), using the password that the user has entered.
token = SHA1(scramble + SHA1(stage1_hash)) XOR stage1_hash
the client sends the token to the server
the server calculates
stage1_hash' = token XOR SHA1(scramble + mysql.user.Password)
the server compares SHA1(stage1_hash') and mysql.user.Password
If they are the same, the password is okay.
(Note SHA1(A+B) is the SHA1 of the concatenation of A with B.)
This protocol fixes the flaw of the old one, neither snooping on the
wire nor mysql.user.Password are sufficient for a successful
connection. But when one has both mysql.user.Password and the
intercepted data on the wire, he has enough information to connect.
However, authenticated sessions continue in plaintext: an eavesdropper will be able to see all queries and results; and a MITM would be able to make alterations to the same. As stated in the manual:
By default, MySQL uses unencrypted connections between the client and the server. This means that someone with access to the network could watch all your traffic and look at the data being sent or received. They could even change the data while it is in transit between client and server.
Whilst you may not like the answer, SSL is the tool designed to defeat both data eavesdropping (how else can the communications be encrypted?) and MITM attacks (how else can either party verify that its peer is who it thinks it is?). Indeed, if the mysql client-server protocol alone defeated these threats then there would be no reason to use mysql over SSL (and thus it would be unlikely to be a supported configuration).
Short answer: Yes, the protocol is safe from Eavesdropping and MITM attacks.
Only if the attacker manages to sniff an authentication attempt AND if the attacker knows the contents of mysql.user, then he can subsequently authenticate against the server. For example if you're using the same password on two different mysql servers and the attacker gains access to one of them, he can also connect to the second server.
I have one app. that consists of "Manager" and "Worker". Currently, the worker always initiates the connection, says something to the manager, and the manager will send the response.
Since there is a LOT of communication between the Manager and the Worker, I'm considering to have a socket open between the two and do the communication. I'm also hoping to initiate the interaction from both sides - enabling the manager to say something to the worker whenever it wants.
However, I'm a little confused as to how to deal with "collisions". Say, the manager decides to say something to the worker, and at the same time the worker decides to say something to the manager. What will happen? How should such situation be handled?
P.S. I plan to use Netty for the actual implementation.
"I'm also hoping to initiate the interaction from both sides - enabling the manager to say something to the worker whenever it wants."
Simple answer. Don't.
Learn from existing protocols: Have a client and a server. Things will work out nicely. Worker can be the server and the Manager can be a client. Manager can make numerous requests. Worker responds to the requests as they arrive.
Peer-to-peer can be complex with no real value for complexity.
I'd go for a persistent bi-directional channel between server and client.
If all you'll have is one server and one client, then there's no collision issue... If the server accepts a connection, it knows it's the client and vice versa. Both can read and write on the same socket.
Now, if you have multiple clients and your server needs to send a request specifically to client X, then you need handshaking!
When a client boots, it connects to the server. Once this connection is established, the client identifies itself as being client X (the handshake message). The server now knows it has a socket open to client X and every time it needs to send a message to client X, it reuses that socket.
Lucky you, I've just written a tutorial (sample project included) on this precise problem. Using Netty! :)
Here's the link: http://bruno.linker45.eu/2010/07/15/handshaking-tutorial-with-netty/
Notice that in this solution, the server does not attempt to connect to the client. It's always the client who connects to the server.
If you were thinking about opening a socket every time you wanted to send a message, you should reconsider persistent connections as they avoid the overhead of connection establishment, consequently speeding up the data transfer rate N-fold.
I think you need to read up on sockets....
You don't really get these kinds of problems....Other than how to responsively handle both receiving and sending, generally this is done through threading your communications... depending on the app you can take a number of approaches to this.
The correct link to the Handshake/Netty tutorial mentioned in brunodecarvalho's response is http://bruno.factor45.org/blag/2010/07/15/handshaking-tutorial-with-netty/
I would add this as a comment to his question but I don't have the minimum required reputation to do so.
If you feel like reinventing the wheel and don't want to use middleware...
Design your protocol so that the other peer's answers to your requests are always easily distinguishable from requests from the other peer. Then, choose your network I/O strategy carefully. Whatever code is responsible for reading from the socket must first determine if the incoming data is a response to data that was sent out, or if it's a new request from the peer (looking at the data's header, and whether you've issued a request recently). Also, you need to maintain proper queueing so that when you send responses to the peer's requests it is properly separated from new requests you issue.