Values are randomly set to NULL

Question

Values are randomly set to NULL

Edvard Korsbæk

SSCertifiable

Points: 5991
More actions
December 3, 2018 at 10:47 pm

#416531

Hi!
I have a table with some encrypted values.
It has in total 85 rows, and over the weeend, some of the values has been set to NULL in 25 rows.
I am at a total loss of finding out what happens here.
The table is (Columns that has been set to NULL is marked with an *, its the last columns):
CREATE TABLE [dbo].[secwin_operators5](
    [ope5_GUID] [CHAR](16) NOT NULL,
    [ope5_SITELIMITER] [CHAR](4) NOT NULL,
    [ope5_LOGIN] [CHAR](129) NOT NULL,
    [ope5_FIRSTNAME] [CHAR](252) NULL,
    [ope5_SURNAME] [CHAR](252) NULL,
    [ope5_PASSWORD] [CHAR](129) NULL,
    [ope5_NUMBER] [INT] NULL,
    [ope5_USERGROUP] [INT] NULL,
    [ope5_LASTPASSWORDCHANGEDATE] [INT] NULL,
    [ope5_HOOK1] [INT] NULL,
    [ope5_HOOK2] [CHAR](252) NULL,
    [ope5_EMAILADDRESS] [CHAR](252) NULL,
    [ope5_FINGERPRINT1] [VARCHAR](1024) NULL,
    [ope5_FINGERPRINT2] [VARCHAR](1024) NULL,
    [ope5_SITELOW] [CHAR](4) NULL,
    [ope5_SITEHI] [CHAR](4) NULL,
    [ope5_EXTRALONG] [INT] NULL,
    [ope5_EXTRASTRING] [CHAR](252) NULL,
    [ope5_usetemppwd] [INT] NULL,
    [ope5_questions] [CHAR](252) NULL,
    [ope5_reservedString1] [CHAR](252) NULL,
    [ope5_reservedString2] [CHAR](252) NULL,
    [ope5_reservedlong1] [INT] NULL,
    [ope5_reservedlong2] [INT] NULL,
    [ope5_CRC] [CHAR](16) NULL,
* [MSSQL_encrypted_password] [VARBINARY](256) NULL,
* [OPE_Personal_Id] [INT] NULL,
* [MSSQL_login] [VARBINARY](256) NULL,
*[ope_areaid] [INT] NULL,
* [ope_institutionid] [INT] NULL,
* [ope_lastarea] [INT] NULL,
*[ope_lastinst] [INT] NULL,
* [OPE_ACCESS_AREAS] [TINYINT] NULL,
* [OPE_Use_Institution] [INT] NULL,
PRIMARY KEY CLUSTERED
(
    [ope5_GUID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY],
UNIQUE NONCLUSTERED
(
    [ope5_LOGIN] ASC,
    [ope5_SITELIMITER] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY],
UNIQUE NONCLUSTERED
(
    [ope5_SITELIMITER] ASC,
    [ope5_NUMBER] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply

Jeff Moden SSC Guru Points: 1003894 More actions · Answer 1

Is this, by any chance, a table provided by 3rd party software? If I had to guess, it looks like someone did a very intentional "cleanup" of possible users that aren't supposed to have access any longer.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Edvard Korsbæk SSCertifiable Points: 5991 More actions · Answer 2

Dear Jeff!

Both true and not.
It is a part of a 3'party template, but the only program that has aceess to this DB is mine.
And more mystic - It's so, that ir has happened twice inn a weekend, where the program is not running.

Best regards

Edvard

Jeff Moden SSC Guru Points: 1003894 More actions · Answer 3

Edvard KorsbÃ¦k - Wednesday, December 5, 2018 12:11 AM
Dear Jeff!
Both true and not.
It is a part of a 3'party template, but the only program that has aceess to this DB is mine.
And more mystic - It's so, that ir has happened twice inn a weekend, where the program is not running.
Best regards
Edvard

Then it's time to setup some DML triggers to find out who, what, and when the rows are actually being deleted. I would also include a list of running jobs when the "deletes" (they're actually updates in this case) happen.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Matt Miller (4) SSC Guru Points: 124210 More actions · Answer 4

Jeff Moden - Wednesday, December 5, 2018 6:16 AM
Edvard KorsbÃ¦k - Wednesday, December 5, 2018 12:11 AM
Dear Jeff!
Both true and not.
It is a part of a 3'party template, but the only program that has aceess to this DB is mine.
And more mystic - It's so, that ir has happened twice inn a weekend, where the program is not running.
Best regards
Edvard
Then it's time to setup some DML triggers to find out who, what, and when the rows are actually being deleted. I would also include a list of running jobs when the "deletes" (they're actually updates in this case) happen.

What are the security implications of those columns being wiped? At first glance it kind of smelled like someone or something was attempting to break in or cover their tracks.

----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?