I have a mssql 2005 and software (that written by visual basic 6) and the software connects to the mssql.(local)
but the problem is that the "sa" user password changes every day!
And the company that write this software does not give us the password.
And the windows authentication does not work and I think that they delete the windows user too.
I searched on the msdn and ... that i found in the LAN, packets from clients were encrypted in SSL type and sent to the mssql and in a specific packet it includes the username and password of the db, and if that user&pass is same with db user&pass it can be full access to db.
I used backtrack & metasploit but it use dictionary for attack but it did not help me .
I used wireshark for finding that specific packet , then i think i found it (99% I sure) but that packet has a lot of unclear characters and i could not find those.
do you think that if i use SSLSTRIP to make a fake certificate then use it between client and server (as a gateway) can i get that? How?
can I use single user mode to add any user to mssql? How?
You are totally approaching this from the wrong angle. You have a software package that goes at extra lengths to prevent access to your data. You problem is the vendor, ditch him. Use a different software, one that has a rational vendor behind it.
Here are the MSDN official, approved, methodology to regain access on a SQL Server that had locked out administrators: Connect to SQL Server When System Administrators Are Locked Out
Related
I'm considering using remote OS authentication to connect to an Oracle database (version 11g). What are the guidelines for using [remote_os_authent]
Here's what I want to do:
We set up a catalog DB to used by RMAN to store metadata about Oracle databases.
I want to connect to the catalog DB via the local machine and execute this command for resync catalog db:
rman target sys/pass#localdb;
connect catalog catuser/password#catdb;
RESYNC CATALOG;
Is it possible for me to do this through oracle Enterprise Manager job?
(I did this process by calling the execute file, but the problem is that the passwords are clear in the executable file.)
I need it because I do not want user passwords to be available and visible.
I can't use oracle valet for passwordless connection.
Using remote os authentication is considered a bad habit because it is insecure.
If you want to have scripting without having to store passwords in a readable format to prevent leaking passwords, easiest is to use the oracle wallet for this.
This still keeps you busy maintaining passwords in the database and in the wallet but it is pretty safe.
Your connection would be something line sqlplus /#tns_alias
where the tns_alias is the key into the wallet that fetches the username and the password.
An example of setup can be found here: http://ronr.blogspot.com/2017/01/cleartext-userid-and-passwords-in.html
An other option could be to enable Central Managed Users (CMU) and kerberos. This does need quite a bit of setup and is less suitable for scripting. For interactive use it works very nice, assuming you have kerberos correctly setup.
An example of CMU setup can be found here: https://blog.pythian.com/part-1-creating-an-oracle-18c-centrally-managed-users-testbed-using-oracle-cloud-infrastructure/
Please change back remote_os_authentication to false. It is not safe because users can easily be spoofed.
I am in a unique situation where I need to test my server connectivity to Oracle databases however I do not have access to any account or password.
Reason why the connectivity needs to be tested is because many times there are multiple layers of firewalls between my servers and the database, and also particularly recently while trying to access RAC/Exadata databases we realized that doing a telnet on the "scan" IP range (which were the only range visible to me) was not enough and that there are underlying physical/virtual IPs that are actually used to connect which were blocked. If I can test connectivity I can at least confirm the database is accessible.
I thought about connecting using sqlplus test#DB, where "test" account doesn't actually exist. If I get a reply saying that incorrect username/password logon denied, then at least I know the database connectivity is working because at least it reached the database to perform authentication. But I have audit concerns (whether DBAs will think someone is trying to hack the system) and also whether there's an actual way or command to do this test.
like #OldProgrammer pointed out, this is pretty much an optimal case for tnsping from the command line
tnsping MY_SERVICE_NAME
Here's a good post showing the basic options. Oh, and I'm pretty sure the DBA's can still see the traffic if they want to.
I need a way to identify whether a given port at a given address is running an instance of Microsoft SQL Server, IBM DB2 Server, or neither, from Python.
My first thought is that I can use Python's telnet library, telnetlib, like this:
import telnetlib
import socket
def checkDBServerType(address, port):
try:
tn = telnetlib.Telnet(address, port)
except socket.error:
return None
tn.write(<something>)
if <something-else> in tn.read_eager():
return "MSSQL"
else:
return "IBMDB2"
The issue is, I have no idea what to send. The user will also be providing my program with a username, password, and database name, so those are also available if that helps.
Also, this is my first post on ServerFault although I've used StackOverflow regularly and SuperUser sometimes. Is this the proper venue for my question, or would it be more appropriate on StackOverflow? (I can't decide if server admin type people or programmer type people would be more likely to be able to help.)
Since you're just looking for a heuristic, I'd say that merely being able to connect to the default port would be a good first cut. So, for instance, if you can connect to TCP 1433, you can reasonably say that that machine is running a default instance of SQL Server. It's not perfect of course (i.e. you could get false positives or false negatives), but it's pretty good. Only you can answer whether it's good enough for you.
You can't simply "talk" to a database server and expect it to tell you what kind of software it's running; there is no standard common protocol to connect to database servers, and although the query language (SQL) is quite standardized, the underlying connection is based on a protocol which is specific to each database system; these protocols are also generally not text-based, thus you can't simply open a socket to a database server and write something on it; also, they are usually never used directly by client applications: every DBMS provides a set of connection libraries which neatly encapsulate them, so that you don't have to understand how to talk to the database server and can focus on actually querying its data.
Your best bet would be to grab the client connection libraries for SQL Server and DB2 and ask each of them to connect to the remote server; whetever one succeeds first will tell you what kind of server is sitting on the remote end.
Quick...
How to use Windows Authentication to SQL Server with the Mono SQL Client running on Windows without a username+ password in the connection string?
More...
We have to use Mono to support multiple platforms for some components of our app
This is an external limitation that we can't change
We will run the components that access the database only on Windows
The portability/OS-agnostic features of the Mono SQL Client add no value
That is, any component running on non-Windows will not access the SQL Server database
The process runs under some Windows user (real user, service account, whatever)
Embedding username and passwords is a bad thing
No matter what angle you come from
So, how can we enable the Mono SQL Client to read the NT Logon Token of the user running the process and pass this to SQL Server? Just like MS .net does?
Is there a flag or setting that isn't well documented
Do we need to implement our own extension?
If so, are we really the first folk to want to do this?
There are 5 other questions (currently) tagged Mono and SQL-Server: they don't answer this...
This is not as easy to accomplish as it sounds. As I'm sure you know, Mono SqlClient has support for NT authentication:
Has a connection string format for NT Authentication:
Server=hostname;Database=databaseName;User
ID=windowsDomain\windowsUserid;Password=windowsPassword;Integrated
Security=SSPI
But of course, you want the simpler form of Integrated Security=SSPI and let the NT authentication handshake use the current process credentials. And here lies the problem. While trivial to retrieve the current process user name (identity), is impossible for a process to discover it's own credentials password. When doing NT authentication an Windows process does not actually do the authentication, but instead is asking the Locas Security Authority (aka. LSASS.EXE, trivia: don't attach a debugger to it ;) ) to authenticate this process. Which means that any library that wants to achieve the same must use the same protocol, ie. ask LSA to authenticate it. The actual details, for the curious, are in the sequence of AcquireCredentialHandle, InitializeSecurityContext, AcceptSecurityContext as described in Using SSPI. I did not study the mono source for SqlClient, but I'm pretty sure they use some GSS-API library for the authentication, not SSPI. therefore, by definition, they require to know the password since they are going to do the Kerberos exchange themselves, not ask LSA to do it on their behalf.
This is, as you can tell, speculation and more of a guess on my side, but I would be surprised to hear a different story. While it is certainly possible to fork or patch Mono.Data.Tds and
modify the authentication implementation to use SSPI instead of GSS, this would, by definition, be a non-portable Windows specific implementation. I would guess there is little incentive for it given that the #1 attraction point of Mono is that is not Windows specific. I'm afraid you are going to have to implement it on your own.
Use NTLM Authorization Proxy Server and connect to SQL Server through the proxy.
I recently made a small app for a friend and then made it a public app, in doing so I forgot that it connects to my MS SQL DB and checks for values. Someone used Red Gate .Net Reflector to get my password and destroy it all. I've contacted their ISP and they are looking into it, apparently this person has a static ip with them.
So this is a lesson learned at a heavy price for me. How can I prevent this from happening again? How can I get away from the unsafe connection string they were able to use?
Never hard code connection strings. Use the configuration section provided for it (connectionStrings), and if really paranoid, encrypt it.
If you are using a shared database, you should not even have a connection string on the client, but create a service point (for example a webservice) that will connect to the database on their behalf. The client can connect to this and your connection string is safe behind your service, which is in your control and on your server.
Don't expose a database connection, but have your app communicate through a webservice, or similar, that only has methods and privileges, to do what the app needs.
If you absolutely need the database connection, make sure the user only has read permissions on the database.
Encrypting the connection string is a start, but your program will have to know how to decrypt it for it to be useful. If your program can decrypt it, an attacker will also be able to - you can only affect the amount of work he needs to put in it.
Therefore, in my opinion, you should expose a read-only service.
If it's a public app, you need to provide individual logins for each user or have a proxy sitting between the database and the application which authenticates the users and talks to the database.
Encrypting the connection string wouldn't help much, I think it can be easily decrypted with built-in tools or with Crack.net.
If you're suuuper paranoid, prompt the sysadmin for the password each time the application starts (maybe an admin interface.) That way it's only memory resident.
I love this question. Like driis said, even with encrypted connection strings you need to store a password (or key, or whatever) to decrypt your encrypted connection string. Just more layers of the same problem.
Using connection strings and encrypted sections in you config will won't stop this type of attack, it's only designed to make the config file unreadable on a machine other than which it is installed.
The only safe way is to create a web service that connects to your database to retrieve the data, and then make sure that the web service logon only has the minimum permissons required, or force the user of the web service to logon and them impersonate that user for the database connection.
It appears you don't have firewall protection to stop external connections directly to your database so I wonder what other even more dangerous ports you may have exposed to the internet???
Using a firewall to limit access to your server to http, and https protocols would reduce the chances of a successful attack.