December 4

Sybase: Hacking Sybase/MS-SQL for the NT Administrator

We were recently faced with getting into a Sybase database where we had fully authorized Administrator access to the NT system, but everybody who knew the “sa” password was long gone. We positively needed the data, so we found a way in, and we’re recording this here so we don’t forget how we did this. We also hope to save others some time — we spent the better part of a day fooling with this, and it could have all been much easier had we known.

The machine in question ran NT Server 4.0 with SP4, and Sybase version 11, but we suspect that this approach would work for newer versions too. We’d also not be surprised if this worked for Microsoft SQL server as well.

Like Microsoft’s SQL server, Sybase permits three modes of authentication:

Standard security mode
Standard security mode is where Sybase maintains its own user database — with login names, passwords, and access rights — and is probably the default. In this mode, the NT user accessing the server is never considered, so being an NT Administrator doesn’t give you any special access.
Integrated security mode
This mean that authenticated NT logons map to Sybase logons, so once you’ve passed the NT domain logon process, that credential gets you into the Sybase door as well. The mapping is not automatic: the DB administrator has to set up the NT -> Sybase user mappings explicitly and then grant rights to those mapped users. Its main benefit seems to be elimination of a separate database login step.
Mixed security mode
This is a hybrid of the previous two.

In “Integrated” security mode, there is further a method of translating otherwise unknown authentication attempts into a specific database user. Not all NT users necessarily map to a valid Sybase user, so the “DefaultLogon” is used to map unrecognized NT users into a single Sybase user. This could be used to provide a kind of generic “guest” access, and we believe that this is disabled by default.

We went into the registry under:

HKEY_LOCAL_MACHINESOFTWARESYBASEServerserver_name

where “server_name” is the name of the database server in question. A machine can run more than one database, and each is administered separately (they even have different NT services to manage).

Under this key, we set LoginMode to “1” and DefaultLogin to “sa” and restarted the associated NT service. From here we ran the Sybase SQL Central and connected while running as an otherwise unknown NT user. This was mapped to the “sa” account, and now we’re an administrator of the databse.

We added a “real” Sybase user with proper SA access, and we were careful to pick a good password: Sybase will allow anybody to use it. We then unwound our changes to the registry and restarted the Sybase service to put things back as we found them. With our new SA user we were able to extract our data.

Standard “Please behave yourself” plaintives apply.

By: S Friedl


Copyright 2021. All rights reserved.

Posted December 4, 2014 by Timothy Conrad in category "Databases

About the Author

If I were to describe myself with one word it would be, creative. I am interested in almost everything which keeps me rather busy. Here you will find some of my technical musings. Securely email me using - PGP: 4CB8 91EB 0C0A A530 3BE9 6D76 B076 96F1 6135 0A1B