Security, compromised

[yogurtu]

Hi all,
We are having a problem, and I hope some of you may give me pointers on how to solve this :-)

A client of us, has an EXE (VB5) provided by us. This exe uses ODBC to connect to our SQL Servers.
Basically what they did is to gain access to our SQL servers, decrypt some stored procedures, and access directly to our sql servers to perform business operations. They are not doing 'bad' things, but they may bypass business validations that are being performed by our front end app. And basically, we do not want other people to access our servers.

Our application uses a generic user to connect to the sql server (with very restrictive permissions). Then, the fully authorised username and pass is retrieved from the db in an encrypted form and then the app reconnects with this user. This user, however, is not the dbo, and it cannot create stored procedures, access most of the tables, it may only use the stored procedures, which are encrypted.

We understand they used a sniffer to detect the fully operational user/pass used to connect to the SQL Servers. We used CAIN to reproduce this. The infrastructure guys installed a certificate in the SQL Server, so the connection is now encrypted. After this, CAIN can't tell us the user and pass any longer.

Now, I took cards into the matter, and I decided to attack our own systems to detect the flaws. First I used a debugger (WKTVBDE - found at http://exetools.com/debuggers.htm) and I could see what the exe was doing, and even though the certificate was installed and the connection was now encrypted, I could see the connection string while it was built. To solve this, I thought of some things. First, to compile the exe without Pseudo Code, directly to native. Second, I think I can encrypt the exe (though I didn't do this in the past, I think it shouldn't be that hard - any hints are welcomed). And third to store the strings encrypted in memory; this I don't know yet how to accomplish. I think that though all of these solutions may only delay their attempts to crack our system, these things must be done.

What I couldn't figure out so far is how to decrypt the stored procedures. We think they may have had access to some SQL Server with a dbo user. However, I want to be absolutely certain that without that kind of access they can not decrypt the stored procedures. I found a bunch of things on this, and here (http://www.sql-shield.com/decrypt-stored-procedure.html) I found a way to decrypt them, but I need sa access or 'create procedure' permissions.

Well... I think that's all. Btw, the SQL Server version is 2000 and most of our servers have SP4 installed.

Any and all the help is certainly welcomed.

Thanks guys!!

[warl0ck7]

Hi yogurtu,

First of all welcome to AO.

1. For the connection string, make sure no passwords are *in* it.
2. For the stored procedure, you can implement your own extened stored procedure
(a dynamic link library actually)which could do a industrial strenght encrytion or decryption
using algorithms like RSA or DES.

[yogurtu]

Hi Warl0ck7,
Thanks for replying to my message, and for welcoming me to AO.
Both of your suggestions are great
I'll change the way it's currently connecting, I didn't know that the password may be sent other way than inside the connection string (we're using ODBC).

Also I didn't consider the possibility of having extended sps.

Once again, thank you

[warl0ck7]

Actually if you wish to completely take everything to
the server i recommend you make a web interface instead of a VB application.
Any how for the problem in hand
the only solution is too ask the user for id and password, see
here.

[yogurtu]

This is a legacy application the company developed several years ago (in the Client Server era with two layers, fat client and stored procedures).

This issue came across our atention when we detected unauthorized people getting into our sql servers.

There are several problems, including the fact that we MUST let the users know the user + pwd to connect (otherwise we may not test the odbc data source). We have a very restricted user account for this, but the sole fact that the we give the login information (even with very limited permissions), allows the attacker to open a query analyzer and run scripts on the server. I saw an incredible amount of things that can be done, including port scanning, brute force attack to retrieve the sa pwd, buffer overflows (new vulnerabilities may arise), sql injection into system stored procedures or extended stored procedures, all of this, using the sql server's resources.

We determined we cannot avoid this at this moment.

To prevent the attacker from knowing a less restricted login, we installed a certificate at the server, so the connection string 'travels' the network encrypted, and decided to recompile to native (instead of PCODE), and to encrypt the exe file (see http://www.softpedia.com/get/Program...-Stealth.shtml) to prevent debugging.

We also decided to implement Intruders Detection, and how to react to intrussions. To this, I am new. I will have to research a lot on this.

After this, we are all commited to develop a new web based version.

Thanks a lot.

[warl0ck7]

It is nice to see you have planned to shift over too web based solution. do take
a look at the following resources

www.sqlsecurity.com
www.oswap.org
of course www.google.com

[nihil]

Basically what they did is to gain access to our SQL servers, decrypt some stored procedures, and access directly to our sql servers to perform business operations.

We understand they used a sniffer to detect the fully operational user/pass used to connect to the SQL Servers

They are not doing 'bad' things, but they may bypass business validations that are being performed by our front end app

I shudder to think what you would actually describe as "bad things"

I presume that you have a contract with these people and that there is an AUP in force that has been agreed by you both??????

Have you consulted your corporate lawyers? Are your CEO and CFO aware of this? Is this activity even legal where you are?

This is totally unprofessional and unacceptable behaviour by a business partner. Is their CEO aware of what has been going on?

This isn't an issue of applications or database security, this is a matter of dealing with people you can trust. I presume that you have more than one client............well I can assure you that the others will not be impressed if you don't deal with this.

Just my view





EDIT: To make myself a little clearer. You have customers who have employees.........perhaps these employees are not trustworthy? What they have done is unacceptable, but may well have been done without the knowledge and approval of their management.

They may well be attempting to defraud you, their employer, or both. I would strongly recommend that you escalate this within your organisation, as life is complicated enough without having to deal with people who obviously cannot be trusted.

This is not some little high school or college game with the students trying to outsmart the administrators. This is business...............there are standards to be observed.

[Tiger Shark]

Why do I have the horrible, horrible feeling that you aren't entirely aware of what these people are/have been doing?

If they could carry out their "business operations" after a valid login with your existing system why would they go to all the trouble they have in order to to so?

If they couldn't carry out those "business operations" did they _ever_ request the ability to do so through proper channels and if they did how did the proper channels respond?

People simply don't go through the amount of effort required to do what they have done for no reason. I can understand if they needed to do something that your system did not easily provide them and your company would not alter things - but then you would be aware of this partner's needs. It seems to me that you aren't and therefore it further seems to me that there is no pressing reason for this activity. That being the case this is malicious, probably criminal and I would block all access to your servers until further notice.

[ammo]

The issue here is the use of a two-tiered application.
Basically, the flaw here is that you're trusting your client application, which is by definition NOT thrustworthy.
This is much the same as trying to do web app validation in client side javascript.

Ultimately, I see two possibilities for you:
1- Implement some accountablitity in your system: drop the generic users and assign private database user accounts to all clients.

2- Make sure all validation logic in the client app is replicated in your stored procedures.

All efforts at securing the system at the client app layer is mear obfuscation and are bound to fail sooner or later. You will never be able to trust the client app since it runs on an untrusted machine and network.


Ammo

[yogurtu]

I shudder to think what you would actually describe as "bad things"

Well... The sole fact that they are performing unauthorized actions in our servers is a bad thing... But they are not performing DOS attacks nor using our SPs to sell on behalf of inexistent agencies, etc... At least, not yet.

I presume that you have a contract with these people and that there is an AUP in force that has been agreed by you both??????
Have you consulted your corporate lawyers? Are your CEO and CFO aware of this? Is this activity even legal where you are?
This is totally unprofessional and unacceptable behaviour by a business partner. Is their CEO aware of what has been going on?

Well, there is a commercial contract, but not AUP. After detection, our CEO consulted the lawyers and it was determined that this is an illegal intrusion, abuse of trust and probably violation of copyright. I agree this is totally unacceptable. Their CEO is aware of this, this is not just 'some of their guys'.

This isn't an issue of applications or database security, this is a matter of dealing with people you can trust. I presume that you have more than one client............well I can assure you that the others will not be impressed if you don't deal with this.

Well... I agree that this is a matter of trust, or abuse of trust. However they did irrupt into our systems, they did capture information on how to connect to our servers, and they did decrypted our stored procedures (among other things). I am not in a position to defend legal matters for the firm. The only thing I can do is try to protect our servers, so they cannot do any of these things anymore.

EDIT: To make myself a little clearer. You have customers who have employees.........perhaps these employees are not trustworthy? What they have done is unacceptable, but may well have been done without the knowledge and approval of their management.

As I said before, their management was aware of this, and presumably, they even engouraged these actions. Personally, I think that they were trying to put ourselves out of business.

Our management decided that it was better if we kept this quiet, so other clients don't think of our systems as 'not secure'.

I was asked to secure the systems, because if our managment decides to launch legal action, we have to be certain that we can defend ourselves from a full scale attack.

Thanks