Protecting the medical sector from ongoing cybersecurity threats poses a highly complex challenge due to its unique combination of highly specialized and domain-specific technologies, coupled with an endemic lack of resources and skill gaps. In assessing the maturity level of Italy's healthcare cybersecurity landscape, we showcase four concrete examples of glaring data leakage and exposed vulnerabilities, illustrating how seemingly trivial issues that could be easily checked or fixed are left unattended. We then ofer insights into the reasons behind the occurrence of these basic flaws and suggest alternative strategies that might assist the Italian healthcare sector in addressing cyber threats more efectively, thereby ensuring an adequate level of security to protect health information.
potential threats [
In this context, the core of this paper is dedicated to raise awareness about the insuficient level of cybersecurity hygiene in the Italian medical landscape. Through five pragmatic experimental examples belonging to four diferent categories (Sections 3-6), and with no pretense of a systematic exploration, we highlight glaring security flaws that should be prioritized before burdening the medical sector with the mandate of deploying more advanced protection solutions. Only by first focusing on the low-hanging fruit — those easily identifiable and fixable issues — can we lay a solid foundation for improvement. This approach is crucial, especially considering that many vulnerabilities highlighted in the subsequent sections stem from elementary and baseline errors, making them relatively straightforward to rectify.
In such a scenario, and keeping in mind the substantial skill gap and resource shortage characterizing the Italian healthcare sector, we hardly believe that further cybersecurity prescriptions will solve the problem. Neither is a "lift and shift" solution, involving the migration to centralized and more easily controllable cloud systems, attainable in the foreseeable future. This approach would face incredible dificulties due to the necessary coexistence with outdated legacy systems and the cyberphysical nature of most medical instruments and devices. A companion goal of this paper is thus to provide our view on practical processes and strategies that can be employed to enhance the cybersecurity health of the medical landscape, in a way that we believe is compatible with the limited resources and skill gaps afecting the medical sector.
The remainder of the paper is structured as follows. After a brief discussion in Section 2 about the Italian healthcare landscape in relation to cybersecurity issues, Section 3 presents two examples of sensitive data currently exposed in plain sight on the Internet. Section 4 demonstrates how potential vulnerabilities can be located within healthcare premises via correlation among public data gathered from various open sources. Hardcoded cryptographic credentials in medical devices are a long-standing problem, exemplified in Section 5 with (yet another) real-world example. More instructive is the incident presented in Section 6. This is a very elementary Stored Cross-Site Scripting (XSS) vulnerability that we spotted months ago over the Italian EHR system and responsibly disclosed to a national CSIRT. This case clearly highlights how a very basic issue may become lengthy and non-trivial to solve when occurring in the highly fragmented Italian medical landscape. While insights from each case are discussed in their respective sections, we introduce an additional Section 7, where we ofer our perspective on potential future directions for cost-efective and practical enhancements to cybersecurity in the medical landscape. The paper concludes with some final remarks.
The ubiquitous incorporation of digital technologies into hospital infrastructures, the capillary
distribution of interconnected devices in the emerging paradigm of the Internet of Medical
Things (IoMT) [
Securing the medical landscape indeed proves to be a dificult task for several reasons. The very first one resides in the sensitive and critical data handled in the medical context, and its high impact on people’s lives and potential life-threatening implications. Especially the high sensitivity of data often translates into a powerful motivation for cybercriminals to demand ransom for not disclosing the data that has been exfiltrated.
Another unique aspect of the medical landscape resides in the huge attack surface exposed.
This is composed not only of cloud servers, gateways [
Furthermore, the Italian scenario presents unique challenges due to the juxtaposition of
modern technologies with outdated infrastructures. According to a 2023 survey conducted by
the Digital Health Observatory of the Polytechnic of Milan [
At the same time, according to a report by Trend Micro [
The combination of practice and skills in using publicly or commercially available search and crawling tools, along with a baseline understanding of medical information technology terms and concepts, allows researchers to discover a significant amount of unintentionally exposed data on the Internet. The following two examples are meant to provide evidence of the degree to which the inadvertent exposure of sensitive information is currently detrimentally impacting the national medical landscape.
PACS servers in plain sight. A plethora of cyberspace-related search services and engines,
including Shodan, Censys, Zoomeye, Fofa, NTI [
(a) Publicly exposed PACS in Italy
(b) Efect on a potential exposed system
the Internet. Among those, Shodan (probably the most known Internet of Things (IoT) search
engine [
Rather than targeting medical devices, we ran Shodan queries to identify servers storing
medical data. The majority of healthcare organizations rely on domain-specific servers known
as PACS, used to archive medical images and enable HCPs to share these patient records and
images with other providers. PACS systems receive images from various imaging modalities
such as X-ray, Magnetic Resonance Imaging (MRI), Computed Tomography (CT), ultrasound,
and nuclear medicine. The most widely used format for this type of report, called DICOM,
is a standard created in 1985 to define the storage and transmission of medical information,
with some known security issues [
We utilized this method to search for PACS instances exposed on public IP addresses in Italy.
The results are depicted in Figure 1a. In the simulated scenario shown in Figure 1b, we illustrate
the potential consequences if some of these PACS were left open: any user with a DICOM client
could potentially access thousands of medical records without requiring a password. This poses
not only a privacy concern but also a security risk, as the permitted DICOM operations include
not only C-FIND and C-MOVE but also C-STORE, which enables the transmission of DICOM
ifles (potentially containing malware or fake data [
Misconfigured Cloud Buckets. The current surge in healthcare’s adoption of cloud technology can be attributed to the growing digitalization of medical applications and the potential improvements in eficiency, cost reduction, and the security and privacy of medical data. In fact, a significant amount of medical data is transmitted through cloud-based medical applications, utilizing services such as AWS S3 buckets, Azure Blob Storage, Digital Ocean Spaces, or Google (a) Medical reports exposed (b) 100,000 “.dcm" files exposed
The data stored in these buckets must, of course, be protected with adequate access control, a common but not always implemented practice. Unfortunately, some buckets expose all data as “public on internet,” either due to misconfigurations or the risky practice of protecting files solely by assigning them unguessable names. Confidentiality is compromised in both cases, especially when cloud providers ofer a listing of files within the buckets. This has led to the emergence of web crawlers like GrayHat Warfare2 or OpenBuckets3.
We employed such search engines to investigate various medical terms, aiming to determine whether these public searches could potentially allow adversaries to intercept inadvertently left unprotected sensitive data. Figure 2a illustrates an example of such a search conducted using the Italian keyword “referto” (i.e., patient medical report). The number of identified records (less than 100 with free OpenBuckets access, but increasing to about 200 with premium access) may not be significant by itself, but it serves as clear evidence of the existence of misconfigured buckets storing medical data, potentially totaling millions of data points with diferent names. Notably, when searching for the “.dcm" file extension (representing DICOM files, i.e., files storing medical data), the results reached 100,000 with free access and increased to about 1 million with premium access (Figure 2b).
Lessons Learned. It is fair to note that the above findings are certainly not new or unexpected.
In September 2019, ProPublica revealed that millions of medical images were being exposed
online through unsecured PACS. Subsequently, NNT discovered more than 2 petabytes of
unprotected medical data on PACS servers, leading to 13 million medical examinations related
to approximately 3.5 million U.S. patients being exposed, unprotected, and accessible to anyone
on the internet [
What surprised us, however, is that, following the initially noticed surge of misconfigured systems, the number of exposed systems actually increased over time! Particularly concerning is the fact that this data is in plain sight over the Internet and exploitable even by individuals with no computer skills. Indeed, such analyses are accessible to everyone via trivial-to-use online tools, and do not depend on any specific leak or data breach. These examples illustrate how reconnaissance, the initial phase of the kill chain, can be easily conducted in the medical domain,
3https://www.openbuckets.io/ highlighting the extensive attack surface of healthcare that inevitably leads to numerous privacy and security concerns - in the words of Mark Dowd, “The attack surface is the vulnerability. Finding a bug there is just a detail”.
On the other hand, the natural emerging question is: if such reconnaissance is so easy, why is it not systematically conducted - for prevention purposes - by our national authorities? In fact, while detailed reports in this area are found in other countries, we observed a dearth of specific reports tailored to the Italian market.
While the elementary queries shown in the previous section were based on public engines, the more “creative” use of open data highlighted in what follows permits to gather further evidence about the presence of potentially vulnerable MDs inside specific Italian hospitals.
For transparency purposes, in Italy (but also in many other countries, see [
By applying a methodology proposed in our previous work [
Our analysis establishes a detailed timeline of when healthcare facilities acquired potentially
compromised devices. It is important to note that the presence of these devices in purchase
records does not necessarily imply that they remain vulnerable at present. Many manufacturers
proactively recall MDs that pose health risks. However, the recall process may encounter
challenges related to the efectiveness of communication among manufacturers, healthcare
providers, and patients [
The specific results of such an analysis, tailored to the Italian scenario and reported in the Appendix, underscore that the difusion status of potentially vulnerable devices within healthcare facilities appears quite critical, either in terms of exposure time (the time between the purchase of the device and the publication of the vulnerability, more than 3 years on average) as well as in terms of severity of the vulnerabilities, measured via their CVSS score. Lessons Learned. While, at first glance, the described approach might be viewed as susceptible to adversarial behavior, allowing the identification of vulnerable devices within healthcare institutions, we believe it serves as a compelling example of how systematic correlation among (open) data, conducted for preventive purposes, can efectively manage risks and enhance awareness. We would actually advocate the extension of the described approach to incorporate additional non-public data, such as that collected by hospitals’ inventory systems, thereby serving as valuable resources for authorities aiming to improve the cost-efectiveness of security audits.
According to the World Health Organization (WHO), there are more than 2 million diferent
types of MDs [
With no pretense of a systematic analysis, we here limit to show yet another contemporary example of hardcoded credentials (kept anonymous for obvious reasons, and being just one among many other similar cases). This example refers to a MD controlled via a mobile app. In this case, code inspection is especially easy as we can directly analyze the app code, without the need to extract the device’s firmware.
As a first step in our analysis, we employed an automatic static Java code analyzer (MobSF), uncovering no specific warnings. However, from a following manual analysis we found some interesting elements not noticed by the automatic analyzer.
In a medical mobile app, the analyzer overlooked a shared secret key, as shown in Figure 4a. This likely occurred because it attempted to match strings, whereas the key was represented as an array of bytes.
(a) Hardcoded Shared Secret Key (b) Hardcoded credentials in native libraries
In another medical app we found an insecurity which could be releated with the recognized trend in current mobile app development to move away from Java classes and Android DEX ifles. To improve performance and access platform-specific features, developers are increasingly opting for the use of “native" code or libraries, which directly interact with the device’s hardware and operating system. Native code, typically written in languages like C or C++, is compiled and loaded onto the mobile device as binary.
We cannot determine whether the dependence on native code might instill developers with a falsely perceived sense of enhanced security. However, it is evident, as illustrated in Figures 4b, that in our specific case, a native component was utilized to store multiple hardcoded credentials. Clearly, this is easily discoverable with minimal familiarity with ELF files and a good disassembler, allowing the exposure of credentials4 in plain sight as demonstrated in Figure 4b.
Lessons Learned. Since reverse engineering is today afordable to any practicioner, there is little more to add to this example beyond quoting the renowned computer security expert Thai Duong: “Assume that your opponents know everything: if the source code or design blueprint were leaked today, it should not change the security exposure of your product."
EHRs are centralized, patient-focused repositories accessible immediately and securely to permitted individuals, predominantly physicians. One of the key diference with Electronic Medical Records (EMRs), is that the core purpose of EHRs is to facilitate the exchange of data, governed by interoperability standards such as HL7, IHE or LOINC. Within the context of Europe’s digital health strategy, EHRs stand as a fundamental component. The standardized format for EHR exchange is designed to enable citizens to efortlessly obtain and disseminate their medical information among healthcare providers, including when seeking specialized care or confronting medical emergencies throughout the EU. The italian EHR is called “Fascicolo Sanitario Elettronico” (FSE), and was instututed in 2012 by Decree-Law No. 179, with a collaboration 4We did not further explore the impact of such credential leakage, i.e. whether these are related to significant or harmful tasks or are just left over from some obsolete function, i.e., just as a legacy of a bad practice. (a) Uploading malicious data in Patient-Originated (b) Execution example of the stored Cross-Site
Data Scripting between the Agency for Digital Italy (AGID), Ministry of Health and Ministry of Economy, together with the Data Protection Authority and the Regions.
Technically, the italian EHR has a complex structure, ruled by many standards on content (e.g., HL7 CDAR2), interoperability profiles (IHE ITI), and functional requirements (HL7 EHR-S). In practice, the resulting structure today is a big federated data storage. The access to such data is demanded to specific applications such as commercial medical software which are connected through APIs, or to public website provided for free by the public administration to give a free access to citizens and, at times, HCPs.
The implementation of the EHR is demanded to the 20 Italian Regions, giving only the functional requirements defined by the HL7 EHR-S FM specification, so that each region is called to basically implement the same thing in a potential diferent way. Today, the National Recovery and Resilience Plan (PNRR, NextGenerationEU), in its Mission 6, put a specific goal of reaching a 85% of utilization by general practitioners before 2025 causing a certain rush necessary to reach the deadline. In the meanwhile, the new version “2.0” of the Italian EHR is moving its first step with the goal of speeding up and improving the digitalization, adding new features and elements such as validation Gateways and a Central Data Repository.
Code duplication, sensible data, rush, new features: this is a fertile soil for the growth of cybersecurity problems. The Italian Data Protection Authority brought one of the first case to the public’s attention with case number 9883731 on March 23, 2023. The EHR provider for the Autonomous Province of Bolzano was subjected to a fine of €15,000. The penalty was imposed due to the provider’s failure to establish adequate authorization controls within their system. This significant oversight allowed individuals to access their own EHR and then alter the patient_id field in the URL. By inputting another person’s tax code, they could unlawfully view the health data of other individuals.
We spot another insecurity in a diferent implementation of the EHR. Specifically, we analyse a component of EHR called Patient-Originated Data (“Taccuino”). This component is designed for patients to input their own health information, which may stem from personal recollections or notes transcribed from physical documents. Unlike other parts of the EHR, this data is not introduced by a physician or an HCP but is directly entered by the patient, which means by any Italian citizen. This particular feature presents a security risk by potentially allowing the upload of malicious data that could be accessed by physicians. More specifically, it opens the door for stored XSS attacks, especially when combined with the EHR public web interface. Through this method, a patient could upload a file containing malicious “HTML+JavaScript” code, for instance disguised as a standard medical report, as depicted in Figure 5. Any doctor opening such data in their browser will execute the JavaScript code, leading to potential unauthorized actions on the EHR portal, such as data theft, unwanted actions on behalf of the phisician, or credential theft through hardly recognizable XSS-based spear phishing schemes. The issue’s severity is amplified by the shared nature of EHR data, since EHR is not a single software or a single website. It is thus needed a thorough examination of all applications with EHR access to ensure there are safeguards against both the upload and download of malicious data.
The vulnerability was notified to CSIRT for a Coordinated Vulnerability Disclosure and apparently the problem has been resolved after 7 months.
Lessons Learned. The reported incident provided us with two crucial insights. Firstly, we discovered that the resolution times for bugs in the Italian medical landscape can be exceptionally lengthy. Although this phenomenon has been extensively documented in the literature, particularly in many U.S. cases, experiencing and quantifying it firsthand in our national context was enlightening. The prolonged timeframe results from both the inherent dificulty of implementing changes to such sensitive systems in a production environment and the intricate nature of the healthcare ecosystem, involving multiple stakeholders.
Secondly, each Italian region autonomously applied a patch to address the identified vulnerability. Unfortunately, no information was provided regarding how the efectiveness of the patch was verified. Regrettably, due to the lack of authorization for further experiments, we cannot assess whether all regions have correctly implemented an appropriate patch. It’s important to note that type checking in file uploads is a nuanced task, considering the diverse techniques employed by penetration testers to circumvent common defense mechanisms.
In this section we take the freedom to propose three suggestions for improving the security posture of our medical systems.
1. Perform centralized continuous active monitoring with reconnaissance tools.
Reconnaissance is usually the initial step in the Cyber Kill Chain, and numerous commercial
products (e.g., Shodan, Censys, Zoomeye, Fofa, NTI, etc.) exist, which can be used to gather
information about potential data leakage, misconfigured cloud applications, or exposed PACS.
As demonstrated in Section 3, these same tools can also be employed for discovering security
or privacy issues. In fact, such systems do even more. They can also recognize potential
vulnerabilities in medical services, correlating the “banners” with well known CVEs [
2. Changing approach: from prescriptive to supportive. Many of the vulnerabilities identified, such as those in Section 3, have straightforward solutions. An alert from an authority to developers/maintainers would be suficient to implement a quick fix, such as utilizing presigned URLs for open buckets or setting a password to enhance security in the case of exposed PACS. These are instances of specific, concrete cases that warrant direct notification. However, the observed Italian trend is quite the opposite, and we are afraid that there is a risk of drifting towards an overly prescriptive approach. The systematic transferring of any cybersecurity problem directly onto healthcare institutions can be not only overwhelming and very costly, but also inefective in front of a gap in specialized cybersecurity expertise. In addition, most of the current awareness campaigns revolve around generic issues (e.g. phishing). This poses a challenge in information management, as an excess or overly broad array of information can hinder the capacity to focus on pertinent and significant elements. Conversely, stakeholders in the medical domain would benefit of advice tailored to their specific cases, and of comprehensive yet focused information, catering to both managerial and non-technical personnel. This can be achieved partially at a low cost and through automated systems, as demonstrated in Sections 3 and 4. Finally, to assist the public sector, there is a need for cross-departmental technical teams of security experts who can collaborate and test systems alongside developers following modern business practices. This would ensure that cases like the one reported in Section 6 receive an efective fix.
3. Encouraging community involvement. Especially in these times of skill shortage, the active involvement of the cybersecurity community could significantly boost the identification of potential vulnerabilities and threats, and even help ensuring a more comprehensive and efective bug fixing. Indeed, active involvement of volunteers has been already started in several international scenarios. For instance, health portals such as DoctoLib (300,000 HCPs) incentivize with monetary rewards (up to €25,000) those who report a vulnerability, through Bug Bounties. They also ofer the full list of their APIs on their site to facilitate the work of testers, and clearly write the scope and the rules of engagement. Even public organizations such as the WHO ofer incentives for reporting bugs (e.g., publication in a hall of fame), giving details on qualifying vulnerabilities and on reporting rules. In the healthcare sector, which is predominantly public in Italy, there is a need to follow these practices, incentivizing Coordinated Vulnerability Disclosure and bug reporting for example with economic (like DoctoLib) or social credits (like WHO). Public scrutiny and extensive security testing of interfaces and products are arguably the best tools we have to strengthen the defenses of our medical systems. Finally, open source development and community eforts should be promoted, and we commend the Ministry of Health for actively developing part of the “FSE 2.0” on GitHub.
Through this paper, we have presented several experimental examples aimed at highlighting the critical cybersecurity status of the Italian healthcare landscape. A concerning aspect is that most of the security flaws we emphasize can be identified using readily available Internet tools, requiring no specific expertise. While these issues are fixable, we argue that imposing excessive cybersecurity provisions on healthcare institutions can be overwhelming, costly, and inefective, especially given the shortage of specialized expertise. Consequently, we advocate for strategic improvements, such as the centralized adoption of continuous active monitoring tools, and an increased engagement of the cybersecurity community to enhance vulnerability identification and facilitate more comprehensive and efective bug-fixing initiatives.
This work has been partially funded by the Rome Technopole Project (PNRR - NextGenerationEU).
Figure 6a illustrates the number of matches concerning the year of purchase. The result is a detailed presence map of potentially vulnerable devices purchased by italian healthcare facilities. Figure 6b shows the time between the purchase and the publication of a vulnerability of a given device. This exposure window represents the potential time for which we have vulnerable devices in our medical facilities, which is 3.5 years on average. It is interesting to show also the severity of the interested vulnerability expresses with their CVSS Score in Figure 7, depicting a landscape where easy-to-exploit vulnerabilities result in a severe impact on the confidentiality, integrity, and availability of medical devices. Finally, we show in Figure 7b and 7c how such vulnerabilities afect all types of medical devices across the board and involve all MDR risk classes.
(a) According to the year (b) According to the exposure time (a) According to the number of matches (b) According to the device class (c) According to the device EMDN category