Circumventing Security

Hi,

I have a user who is a member of a group who has restricted access to F986101 (Object Configuration Master). They cannot run this application. I have checked the security in the F00590 table and it has not been changed since it's creation in 2003. The user has changed the OCM mappings recently and there is a record in theF986101 table with his user id and a date and time stamp? Does anyone have any idea how this user can change the OCM mapping if the security table says they don't have access to it. I have asked the databse guys if there has been any unusual sql activity during that period, there has'nt. Why is there a date/time stamp on the record with his ID surely if you were going to do this kind of thing you wouldnt use your own id.

any ideas would be great as this may potentially be the tip of a large iceberg.

thanks

Can you send me a snapshot of how you have the file secured in the F00950. Does the user have access to the form?

If you only secured the "application", then it can certainly be bypassed - any APPL or UBE / UBEVER can do direct table updates. Particularly, if the users have development rights (even Create Version, because then they can do ER Overrides).

Bob

I have tried to email you but my system keeps returning the mail as undelierable. Please see the attached file

Are there other F00950 entries for the user, BRCROL1-C? If the user updated this via a UBE, SQL, etc...there probably wouldn't be a UserID in the audit fields.

I'm very curious to see all F00950 entries for the user.

- Scott

The user in question does not have any individual security attached to them. All the security is located within a single group. It is logical to think that if the user wanted to remain anonymous they would not put their user id stamp on the record. I would need to check every application they have access to and then check the table to see if they has changed their access. There is nothing in the F00950 table to indicate that they havec access to these apps? UBE or SQl modification seems to be the answer but I'm still not convinced.

It appears, if you look at your updated record, that the user is running some custom UBE "R55...", which is probably calling some function of the application, so wa-la, a user that can't run the OCM application, can still access and modify the table using something else...in this case, it appears to be not only a UBE, but a custom UBE. Like Alex stated, there are many ways at information in tables, the application itself is not the only method to access.

In my experience as a consultant, I encountered MANY sites that would copy the system applications (OCM, Data source setup, etc) to custom appications without anyone knowing. Thus giving them total control of the system unbeknown to anyone. Check all your custom apps and see if any are similar to the ones you put security on. Sneaky buggers.

Hi Guys

after abit of investigation I have found out how the security was comprimised. I checked the security history and found that for a given change (user had added themselves to a projet with PVC rights) there was a user profile change on the same day. The next day or later the profile was changed again. I found quite a few of these correlations where something in the system was altered which matched a change in the user profile before and after the change. Security workbench and menu security barred such users from doing these changes/running specific apps.

I logged into the users fat client and checked their default project. Low and behold they had taken a copy of the P0092 User Profile app and created a client version. They were then running this version to change their Group to one which had significant access, doing the change in OneWorld then using the same app to change their group back to what it was. They forgot however that the application was still putting their user-id as an audit stamp which was how I originally knew it was this user. Needless to say heads will roll!!

thanks again for the advice

Hopefully corporate security will be escorting that user off the premises forth with. Make sure you have everything well documented. It sounds like you do. Good luck!

Note to self... when hacking an employer's system: Remember to comment out the audit-field updates... (or, better, put in gregglarkin's name)...

Thanks for 'learning' us another way to plug a security hole! Now - how do we keep users from creating their own copies of the applications we have grown to love and distrust?

(db)

This was, by far, the easiest way to break it. Writing ER in a Version Override was obviously going to be more complicated.

But the principle is the same and it teaches us two lessons:
- Table security is the only security. Anything less is an exposure.
- Any Development access can be used to break it. With enough skills and time, even table security will not stand.

Does anyone recall a discussion at Quest in 2005 discussing either the plan to put in place security to prevent this from happening?

I distinctly remember discussing this.



[ QUOTE ]
Hi Guys

after abit of investigation I have found out how the security was comprimised. I checked the security history and found that for a given change (user had added themselves to a projet with PVC rights) there was a user profile change on the same day. The next day or later the profile was changed again. I found quite a few of these correlations where something in the system was altered which matched a change in the user profile before and after the change. Security workbench and menu security barred such users from doing these changes/running specific apps.

I logged into the users fat client and checked their default project. Low and behold they had taken a copy of the P0092 User Profile app and created a client version. They were then running this version to change their Group to one which had significant access, doing the change in OneWorld then using the same app to change their group back to what it was. They forgot however that the application was still putting their user-id as an audit stamp which was how I originally knew it was this user. Needless to say heads will roll!!

thanks again for the advice

[/ QUOTE ]

See, this is exactly why I never use my own UserID AND I make sure my custom tools are on my patsys default project. MUUAAHAHAHAHA

Seriously though, that took quite a lot of audacity for the programmer to put those tools together. I can't imagine taking such a huge risk just to get different OCM maps. I wonder if he was just lazy, or after something big. Nice catch.