SharePoint Saturday Boston 2015#SPSBOS

© 2008 Jonathan Ralton

Soup to Nuts: SharePoint SecurityPablo Gazmuri

Pablo GazmuriBlueMetalpgazmuri@bluemetal.com@pgazmuri

Soup to Nuts:SharePoint Security

On the Menu

• Definitions (a word soup)• Farm Configuration Salad• Network Configuration Amuze-Bouche• Admin Security Intermezzo• Site Security (Entrée)• Public Facing Sites (Second Helping)• Common Issues and Social Engineering (for dessert)

Definitions

• What makes a system “insecure”?• Exploit

• Software Security Bug / Misconfiguration• Resolved by Patching

• Defense in Depth• “More secure” configuration – just in case a new exploit is discovered

• Internal Security• Protect against threats inside your network• Don’t assume your network is secure

Farm Configuration• Service Accounts

• Why so many different accounts?• Automatic Password Changes• Apply principle of Least Privilege – no admin rights!

• Turn off unused services• Isolate web applications and data access• Isolate Search Service Application / BDC / Profiles

Externally Accessible Sites

• DMZ• Authenticated Reverse Proxy – TMG/UAG• Split Topologies• The Cloud

Admin Security

• Don’t login with the “Farm Account”• Grant admins the necessary permissions so they can login using

their own accounts.• This can be tricky, which is why many of you don’t do it already.

• Audit the event log for site collection administrator and web app policy changes

• Don’t browse the web from the server

Site Security• Site Collection Administrators have full control over the entire site

collection, regardless of any security settings within that site collection. Super user.• Web application policy allows you to grant or deny permissions

across an entire web application, regardless of individual site collection settings. Master override. Used in regulatory and administrative scenarios.

Site Security• SharePoint has it’s own security groups defined at the site collection

level. • Available to all sites in the site collection.• Cannot be nested• But can contain AD Groups

• Generally not recommended to create AD groups for every SharePoint group. 100 sites X 3 groups per site = 300 AD groups.• Rather, add existing AD groups to SharePoint groups.• Site Access Requests will result in individual users being added to SP

groups.

Site Security• Groups are simply collections of users, they don’t grant permissions

on their own.• Groups and Individual Users are granted specific permissions to a

securable.• A Securable is a Site, Subsite, List, Library, Folder, Item or Document• These permisions are “additive”, meaning there is no concept of

Deny, only grant.

Site Security• When permissions are granted, they are granted with specific “Permission

Levels”, which are each made up of a set of granular permissions such as:• Add• Edit• Delete• View• Manage Permissions• Etc….

• Default permission levels include:• Read• Edit• Contribute• Design• Full Control

Site Security• So for any given place where permissions are assigned, they are

represented by combining 3 things:• Group or Person to be granted permission• Securable to which that permission will apply• Permission Level that is granted for that Securable for that Group

• Note that although you can directly assign permissions to AD groups and AD users, it is best practice to only assign permissions to SP groups, and then add specific AD groups or users to that SP group.

Site Security• By Default, a site collection is configured with at least 3 main groups:

• Owners• Members• Visitors

• Which are assigned particular permission levels at the root of the site collection.• These permissions are inherited by every site, list, library, folder, etc…

by default.• To grant new permissions at any level below the root, you must

“break permissions inheritance”.

Site Security

• Many Security Groups = difficult to manage and audit.• Broken permission inheritance = difficult to manage and audit• Use different site collections when you have distinct security needs• Use web app policy to grant/restrict globally across sites in a given web

application

Public Facing Sites• Enable Forms Lockdown Feature• Anonymous users won’t be able to view settings, people,

content or submit to lists• Lock down unnecessary services, even from logged in users.• Don’t grant SharePoint logins to end users automatically – roll

your own login scheme if you must support this.• Consider your network topology very carefully

Public Facing Sites

• Don’t let your site be a platform for attacks on others:• Unsecured email forms/services (e.g. “Share”) allow

spammers and phishers send mail• Unvalidated redirects allow phishers to create addresses

that point to your website, but then redirect elsewhere.• Output that isn’t HTML encoded allows phishers to place

content or code on your site

Common Security Issues

• Custom code, especially…• Account related code• Create Account• Forgot Password• Change Password

• Data Input• XSS, SQL Injection, etc…• Always scrub this data both in and out

• Carefully audit changes to these modules

Common Security Issues

• Improper Security Settings• Can logged in users access:

• Site members list• Search Service• People Picker

• ViewFormPagesLockdown not enabled• Insecure Services

• Unpatched Software – O/S, IIS, ASP.NET, SharePoint Itself, 3rd Party Software

• Improperly allocated service applications

Examples of security malpractice

• Password reset page that requires only username or ID to access• Custom service that would execute any COM/COM+ function• Create account page that did not validate whether an account

already existed.• Output of username to page w/o HTML encoding• Help Desk did not verify identity before resetting password• Custom page would read any file passed via query string

variable

Demonstration

• I will now hack into a SharePoint Site

Demonstration

• Just Kidding

Demonstration

• Finding content that maybe I shouldn’t see

Social Engineering

“It is much easier to trick someone into giving a password for a system than to spend the effort to crack into the system.” – Kevin Mitnick

He’s right: many users will give up their passwords for a candy bar.

Social Engineering

• Phishing• Pretexting• Diversion• IVR Phishing• Baiting• Quid Pro Quo• Exploiting Current Events

Social Engineering

• Establish “framework of trust”• Identify Sensitive Info• Establish Security Protocols• Train Employees in those Protocols• Secretly Test the Framework

SPS Boston 2015 is made possible by our Sponsors

We Are Hiringin Boston!

Junior SharePoint Developer/Administrator

Learn more:https://www.linkedin.com/company/bluemetal-architects/careers