1

I have a legacy VB app without any source code that has the 'sa' user and a 6-digit password hard-coded into it. I would like to use an up-to-date MSSQL but I am getting stuck on the password length policies in more modern MSSQL versions.

I've tried 1) creating a partially contained database for this app (still get password length complaints); 2) I've created a new user and hex-edited the userid in the binary to something else, but the application gives random errors when 'sa' is not used.

Is there any way to "trick" MSSQL into letting me use the 6-digit password? Any reliable decompile/recompile service? This is just one single module.

jstark
  • 11
  • 1
  • 2
    Honestly, I think it's time to bin that app. It might be legacy but having the `sa` account enabled with such a weak password is incredibly foolish. Yes, you can work around it (I've not provided a solution because I don't want to provide one for something I feel is so dangerous), but just *don't*. Address the root problem. – Thom A Jun 16 '23 at 10:45
  • That one single legacy VB app would completely compromise the security of the entire server, since `sa` is, well, `sa`. If you must do this, you should be able to bypass the policies using `ALTER LOGIN sa WITH CHECK_POLICY = OFF, PASSWORD = '123456'`, but ensure that app is the only thing using the server, and preferably lock down the server entirely, since anyone with any kind of access is a potential sysadmin. Trying all possible 6 digit codes for a login should not take a modern machine much time at all, so you may as well treat the server as though it had no password at all. – Jeroen Mostert Jun 16 '23 at 10:47
  • Note that making the database it uses contained isn't going to help matters; the `sa` will be a `LOGIN` with *full* `sysadmin` privileges. It will be able to do anything and **everything** on that instance, on *every* database. And, depending on the type of access the service account has on the network, if could do all sorts of things on your domain too. – Thom A Jun 16 '23 at 10:54
  • What kind of "random errors" are you getting? the safest might be to create a two-character user i guess, if you didn't already do that – siggemannen Jun 16 '23 at 10:58
  • 3
    My recommendation... rename the actual `sa` login to something else and then create a new `sa` login for this brain-dead application to use that has only the minimum access that it requires. – AlwaysLearning Jun 16 '23 at 12:28
  • @AlwaysLearning: interesting, I would not have thought that possible -- but indeed you can rename `sa` to anything you like. The only potential drawback is breaking things that rely on `sa` being a sysadmin (not necessarily the legacy app in question), but those should arguably be redesigned anyway. – Jeroen Mostert Jun 16 '23 at 12:44
  • It might be possible to decompile the VB application back into (likely difficult-to-read) source that could theoretically be recompiled back into a working application. If that is successful, the next step would be to hunt down the connection strings and replace them with ones that uses integrated security or some other secure credentialed method. Then rebuild the updated app. (Disclaimer: I am not speaking from experience here, but think this might be possible with readily available tools.) The result would need debug the "random errors" a do extensive testing before moving to production. – T N Jun 16 '23 at 23:23

0 Answers0