In December 2021, I discovered a misconfiguration in the Health Service Executive’s (HSE) COVID Vaccination Portal. The HSE provides public health and social care services to everyone living in Ireland. The vaccination portal, developed by the HSE with Salesforce Health Cloud, granted registered users excessive permissions. This oversight allowed individuals to access sensitive Personal Identifiable Information (PII) and Protected Health Information (PHI) of other registrants, as well as internal Health Service Executive (HSE) documents. Since all vaccinations occurring in Ireland go through the HSE, it is estimated that the private information of over a million Irish citizens was inadvertently made publicly accessible.

Once reported to the HSE, I assisted them with resolving the issue over the course of several weeks until the misconfiguration was fixed. After investigation by the HSE, they fortunately did not find any evidence that any information was accessed by unauthorized individuals with malicious intent.

My goal in writing about this issue is to provide a public service to organizations that handle sensitive data in SaaS applications. I have attempted to coordinate disclosure of the issue over the last two years with HSE, but to my knowledge, it has not been publicly disclosed or acknowledged by the HSE (see section below on Disclosure Timeline). This article is the first to publicly acknowledge the misconfiguration in the HSE portal. It seeks to discuss the misconfiguration(s) that occurred, a timeline of events, and provides security posture recommendations for organizations that use the Salesforce platform to store and process sensitive information.

The vaccination portal, built on top of Salesforce, allowed any individual to sign up to the portal through a self-registration form. In Salesforce nomenclature, this particular type of portal is known as a Lightning Community or Digital Community. These communities are configured to grant all registered users a specific Profile. Through the permissions granted by the profile, users can then perform actions using the vaccination portal’s user interface, such as register for a vaccination or view their own personal vaccination appointment details. All of this information was being stored in various tables of data (referred to as objects) within the Salesforce Health Cloud application.

Unfortunately, the individuals who had configured the profile’s permissions had accidentally granted the profile an unprecedented level of access to the Health Cloud object that is responsible for storing information specifically about vaccination administration. In the Health Cloud application, this object is referred to as ‘EhrImmunization__c’ and is used to store both PII and PHI. Thankfully, the ability to see everyone’s vaccination administration details was not immediately obvious to regular users who were using the portal as intended.

Furthermore, the same profile had accidentally been granted read access to a folder containing internal HSE documents. Because of that, sensitive information could have been downloaded and distributed by anyone who had registered to the portal.

How It Could Have Been Accessed

In the previous section, I alluded to the fact that normal users would not have realized they had this level of access. This is because when information is being displayed after logging in to the portal, it is designed specifically to show only your own data.

However, several years ago I published an independent blog post which was the first of its kind to outline how individuals could retrieve data through the out-of-the-box Salesforce API known as the Aura API. When information is accessed through the methods outlined in that blog or similar alternative methods, users can see not only their own information but also any other information they have been granted permission to access.

By following that methodology, a malicious user could have performed the following steps:

1. Registered to the Vaccination Portal in order to be automatically assigned the over-privileged Salesforce profile.
2. Through the API, view all objects that existed within the Salesforce platform including those belonging to the Health Cloud application.
3. Iterate over the list of available objects and attempt to access the data within them.
4. For any successful attempts, proceed to access and download thousands of rows of data at a time.

Using those four simple steps, this would have allowed the malicious individual to access both internal HSE documentation, and all vaccine administration records for over a million individuals.

In this example, the HSE had poor permission management practices which resulted in registered members of the portal having the ability to view data far outside the scope of what was intended. This is a common problem among organizations using Salesforce, as managing object and field access alongside sharing rules can be challenging and cumbersome. For organizations that have publicly facing content on the Salesforce platform, this is the number one cause of data exposure.

Typically, I recommend that organizations follow several steps in order to accomplish a strong initial security baseline for Salesforce. These include:

• Principle of Least Privilege: Ensure that both internal and external users have the minimum required permissions to fulfill their needs.
• Routine Permission Model Reviews: Regularly review import access-granting elements within Salesforce, such as profiles, permission sets, and sharing rules.
• Classify Sensitive Data: Review the data being stored on-platform, categorize it, and implement classifications based on its sensitivity level. This allows organizations to easily target data of utmost sensitivity and employ stricter access controls.
• Monitor Salesforce Logs: Salesforce provides multiple types of readily available logs that can be ingested into an external SIEM tool and analyzed. Of most interest with respect to this particular issue is the relatively new ‘Aura Request’ event which captures the use of Aura Controllers in the logs. This makes it especially useful for detecting data exfiltration attempts.
• Audit the Platform’s Configuration: Settings within Salesforce have the ability to influence the security of your organization in nearly any capacity, including access control. These settings should be seen as the first line of defense and configured to be in line with internal security policy or adhere to a globally accepted security framework, such as NIST. This must be done on a continuous basis as the configuration will change very frequently in most organizations.

We can recognize that this vaccination portal was deployed during a particularly chaotic period in which many governments across the world were scrambling to provide a single streamlined vaccination management solution for its citizens. Under these conditions, it would have been exceptionally difficult for the HSE to manually implement the preventive strategies I had outlined in a manner that is both quick and effective.

This makes it a perfect use-case for AppOmni’s SaaS security solution for Salesforce. AppOmni provides immediate value for organizations by not only providing a holistic, current, and continuous view of their platform’s security, but also assisting them in preventing these kinds of data exposures long before they can happen.