COVID-19 surely caught many off guard and one of the implications of that was the need to quickly come up with software solutions that eased decision-making around the virus and also to help citizens staying informed.
In Portugal, the government created the COVID-19 Digital Response Office with the goal of evaluating, implementing and providing information on how to best use the digital world to tackle the pandemic. Its members are the government itself, other national entities (including health departments), some IT companies, academic instutions and some associations.
One of the outputs of this response office was a set of dashboards combining data on the evolution of virus spread in the population over time. These dashboards were built with ArcGIS, a geographical information system available since 1999 and created by ESRI, a company whose official portuguese distributor is a member of the COVID-19 Digital Response Office.
Those dashboards did call for my curiosity on finding out more about the software and data behind them. This article is therefore a compilation of security vulnerabilities, misconfigurations and data exposures that I have encountered and reported to the responsible entities so that they could get addressed.
1. Accidentally hacking™ a user
While searching the ArcGIS documentation pages for reference information on its REST API, I felt the need to go more hands-on and actually play with the API myself. In fact, ArcGIS is licensed for free for personal use, but I was not aware of this fact at the time. Instead, I found some test credentials (something like "test" as username and "test" as password) which I figured could be the credentials for a test development account in ArcGIS.
Turns out I was able to successfully log in to the system with those credentials, but my assumption was wrong. This was not a test account, it was an actually usable account. And this account had a ton of usage credits available.
The exploitation of default credentials is a very common attack vector and of zero complexity in most cases. However, after contacting ESRI about this incident, I was informed that this was not an officially created test account, instead it was created by an actual user of the system, who happened to work at ESRI judging from the @esri.com email address.
2. Leaked data due to wrong permissions
The same server that hosted the COVID-19 dashboards also hosted multiple other services including, but not limited to:
-
source data for other COVID-19 dashboards
-
feedback forms
-
experiments done to understand the ArcGIS software
-
geographical data
Me and my friend André Maia went through the hundreds of services available and discovered that 23 of these services contained sensitive personal data. In total, the exposed data contained:
-
~2500 personal names
-
~500 personal email addresses
-
~500 personal phone numbers
-
~50 personal street addresses
-
~1000 ID card numbers
-
~150 free-text opinion form responses
-
~150 1-5 rating form responses
In addition to this textual data, we found an attachment image containing a screen capture of a video conversation that had happened on the 20th April 2020. The chat messages visible in this screen capture included an URL and two values which appeared to be a username and a password. The URL pointed to the ArcGIS administration page used by a Portuguese city council, which means that the other two values were very likely the administrator credentials of the ArcGIS service used by this city council.
Having contacted both Esri PT and the affected city council, the issues got resolved quickly and therefore the personal data is no longer exposed and the password for the administrator account has been changed.
3. Wrong permissions in a COVID-19 dashboard
One of the dashboards made available by Esri Portugal displayed a map and list of closed facilities and cancelled/rescheduled events:
Looking at the configured permissions of the service behind this dashboard, the following aspects stood out:
-
It allowed executing the following actions: Create, Delete, Query, Update, Editing, Extract, Sync
-
All anonymous users were allowed to execute the actions above
The data present in this dashboard could therefore be compromised by a malicious user, who could use it for advertising, phishing attempts, links to malicious websites or even the removal of all entries.
After I notified the team behind this service, the issue was resolved by properly restricting the permissions of the service so that anonymous users are only allowed to query data and not to change it.
4. Access Control vulnerability
Note: This last section is very specific to the ArcGIS software. Read it only if you are really interested or really bored 😊.
In the ArcGIS software, replicas are copies of a database in another location. Replicas can be used to sync data between ArcGIS online and a local client, which is particularly useful to make edits while offline and later synchronize the local edits with the server.
The process of working with replicas follows these two steps:
-
Create a replica on a given Feature Service (a service that hosts a set of data). Here we configure our replica and specify which layers we want to replicate (think of layers as different tables in a database or different sheets in a spreadsheet).
-
Synchronize replica, which means sending any edits that have been performed offline and receiving other edits that may have been applied by other users.
As we have seen in a previous section of this post, Feature Services have a configurable set of available actions (e.g. Create, Delete, Query, Update, Editing, Extract and Sync). In specific, the Query capability is what allows reading data from a service.
While investigating how replicas worked in ArcGIS and looking for potential security issues, I found an incorrect access control vulnerability which allows remote attackers to read data from a Feature Service which does not have the "Query" capability by synchronizing it against a replica which belongs to a different Feature Service.
These are the steps to reproduce:
-
Create Feature Service A with capabilities "Create, Editing, Sync" (no Query) and which disallows creating replicas.
-
Try to create a new replica of Feature Service A at https://<featureservice-A-url>/createReplica and verify the operation fails with the error "This operation is not supported.".
-
Create Feature Service B with capabilities "Create, Query, Editing, Sync" and which allows creating replicas.
-
Create a new replica of Feature Service B at https://<featureservice-B-url>/createReplica.
-
Use the new replica to synchronize snapshot against Feature Service B at https://<featureservice-B-url>/synchronizeReplica and verify the operation succeeds as expected.
-
Use the same replica ID of Feature Service B to synchronize snapshot against Feature Service A at https://<featureservice-A-url>/synchronizeReplica and verify the operation succeeds displaying a snapshot of all data, even though the replica belongs to a different feature service and the "Query" capability is not present.
In short, we trick the system by asking to synchronize a service against a replica of a different service and this way we are able to read data that should not be accessible as the "Query" capability is not enabled.
Having spoken to the Incident Response Team behing ArcGIS, the issue was acknowledged and a patch was released soon after the report. I thank the team for including me in their list of security researchers.