On Friday, May 17th 2019, Salesforce experienced a large-scale service disruption affecting profile permissions. This included the erroneous addition of the Modify All permission against many standard and custom objects to all profiles in customer orgs. This is one of a series of articles written by the AppOmni Security Engineering team diving into the technical specifics of the incident, its impact on your Salesforce data, and how to prevent similar incidents in the future.
To answer the question of how the “Modify All” and “Modify All Data” (MAD) permissions impact cloud data leaks it’s important to understand exactly what “Modify All” does on a profile or permission set. Salesforce object access operates on four main permissions known as CRUD – Create, Read, Update, and Delete. Users granted one of these four permissions can take that action on records of the object for which the permission was granted, subject to record access restrictions like sharing rules.
Modify All circumvents access restrictions and grants all of CRUD access on all records of the object for which it is granted. For example, if a user is granted Modify All on the Account object via a permission set or their profile, then they have access to create new Account records, view and update all existing Account records, and delete any Account records they choose. In short, Modify All is an administrative or super-user permission.
Modify All Data (MAD) is a system-level extension of object-level Modify All. Modify All Data, when granted to a user, allows that user unfettered access to data. Salesforce recommends that this permission be granted to “Administrators of an entire organization”.1
The Modify All Data permission, by virtue of granting write access to all object types, also allows for several business logic and process flow actions A full list of these can be found in Salesforce Help & Training. Finally, the Modify All Data permission grants access for the permissioned user to view Salesforce Setup and Configuration settings.
Because Salesforce’s permissioning system is additive, a user being granted Modify All on an object via their profile or any permission set will have that access despite any other restrictions put in place via permission sets or sharing rules. The substantial impact of the Modify All permission is one of the reasons it is generally a carefully guarded permission only granted to extremely high-privilege profiles.
On May 17th, due to an inadvertently impactful database script, Salesforce accidentally modified most or all profiles in some Salesforce orgs to include Modify All for many standard and custom objects. At this time, it appears that Modify All was granted for all standard and custom objects in the profile’s license.2
This means that for a period of time on May 17th, all users in affected Salesforce orgs could view, edit, and delete all records of those objects in a Salesforce org. As far as we know, the increased permissions did not include modifications to a profile’s tabset or tab ordering, meaning that a user would have had to actively navigate to the object views for objects they do not normally see access to. There would have been nothing stopping them from doing so, though.
For users not typically allowed to see all records of a given object type, new records would have appeared in their normal views, as well as buttons for edit, delete, and create operations, which otherwise would not normally have been exposed.
It is important to note that this database script resulted in the assignment of the object-level Modify All permission against standard and custom objects in the Salefsorce org. It did not result in the application of the Modify All Data (MAD) permission to any users. While being granted Modify All on standard and custom objects is a significant percentage of the MAD permission, it would not allow users to view Salesforce Setup or perform other administrative functions.
Based on our observations and communications from Salesforce during incident bridge calls, the Salesforce script that accidentally granted these permissions was limited to object permissions. This means that the script itself could not have accidentally enabled other permissions on external users such as API Enabled. Depending on the total configuration of the external user profiles in your org, those users may or may not have easily been able to view internal records, download files and attachments, or perform other normally-forbidden actions.
