The European Commission’s GDPR review in short

Two years after the GDPR entered into force, the European Commission (EC) issued its first evaluation of the GDPR. According to the EC, the GDPR’s data protection rules have proven that they are fit for the digital age, as they help to foster trust-worthy innovation, empower individuals to have more control over their personal data and guarantee the free flow of personal data within the EU. However, the EC also identified a number of areas for improvement. We have addressed the key points from the EC’s evaluation below.

  • Citizens are more aware of their rights

Individuals are increasingly aware of the GDPR and their GDPR rights. Today, 69% of the population above the age of 16 in the EU have heard about the GDPR and 71% of people heard about their national data protection authority. However, the right to data portability is still not used to its full potential. It is one of the EC’s priorities to increase awareness of the right to data portability, as it believes this right can foster competition and support innovation in many sectors.

  • Data protection authorities do cooperate but there is room for improvement

The GDPR’s cross-border enforcement system – the so called ‘one-stop shop’ mechanism – enhanced cooperation between data protection authorities. However, developing a truly common European data protection culture between data protection authorities is still an on-going process. Data protection authorities have not yet made full use of the cooperation tools the GDPR provides, such as joint operations that could lead to joint investigations. Additionally, further progress is needed to make the handling of cross-border cases more efficient by harmonizing procedural requirements across the EU.

  • Despite harmonised rules, there is still a degree of fragmentation and diverging approaches

As a result of Member States’ policy freedom arising from GDPR, there is still a degree of fragmentation which is notably due to the extensive use of facultative specification clauses. According to the EC, this fragmentation also creates challenges to conducting cross-border business, innovation, in particular as regards new technological developments and cybersecurity solutions. For the effective functioning of the internal market and to avoid unnecessary burden on companies, it is essential that national legislation does not go beyond the margins set by the GDPR, the fundamental rights or introduces additional requirements when there is no margin.

  • The GDPR’s international data transfer toolbox

The EC’s international engagement on harnessing the full potential of international free and safe data transfers has yielded some results. This includes the EU-Japan mutual adequacy decisions, which created the world’s largest area of free and safe data flows. The EC will continue its work on new adequacy decision, notably with the Korean Republic (advanced stage) and a number of other countries in Asia, as well as in Latin America (exploratory talks). The EC will further review the adequacy decisions that were adopted after the Court of Justice’s judgment in the Schrems II case (16 July 2020). Beside its adequacy work, the EC is working on a comprehensive modernisation of standard contractual clauses, to update them in light of new requirements introduced by the GDPR. The EC’s aim is to better reflect the realities of processing operations in the modern digital economy and consider the possible need, including in the light of the new case law of the Schrems II case.

For more information on the Schrems II case, please see this article and the previous blog.

  • Promoting convergence and international cooperation

Over the last two years, the EC has intensified its dialogue in a number of bilateral, regional and multilateral fora to foster a global culture of respect for privacy and develop elements of convergence between different privacy systems. In addition, the EC is also determined to tackle digital protectionism by developing specific horizontal provisions on data flows and data protection in trade agreements, such as forced data localisation requirements.

Furthermore, the EC’s reports that at a time when privacy compliance issues or data security incidents may affect large numbers of individuals simultaneously in several jurisdictions, cooperation ‘on the ground’ between European and international regulators should be further strengthened. In particular, this requires appropriate legal instruments to be developed for closer forms of cooperation and mutual assistance enforcement cooperation agreements with relevant third countries.

  • Final remarks

Besides the current status and the areas of improvement, chances and risks for organizations can be derived from the EC’s GDPR review.

Firstly, as individuals are more aware of their rights, organizations must have an internal governance framework in place to ensure that individuals are able to exercise their rights properly and to avoid enforcement backlash.

Secondly, as privacy is situated at the centre of the public debate the GDPR’s data protection rules are becoming more and more an element of convergence between different privacy systems. We see companies adopting (parts of) the GDPR in their global privacy programs. This also means that the GDPR can create chances for organizations to promote respect for personal data as a competitive differentiator and a selling point on the global marketplace, by offering innovative products and services with novel privacy or data security solutions.

Subscribe and stay updated
Receive our latest blog posts by email.

Syn/Ack Unique Proactive Protection Technique

McAfee’s Advanced Threat Research team has performed analysis on samples of Syn/Ack ransomware implementing Process Doppelgänging.  For those who are concerned about the potential impact of this ransomware but are currently unable to implement McAfee product protections, we have found a simple but interesting alternative method.  Prior to encryption and ransom, the malware first checks if one of several hardcoded keyboards or languages is installed on the target machine.  If found, the malicious code will terminate, effectively resulting in an extremely simple “patch” of sorts. We have tested the following steps to be effective on several versions of Windows 7 and theoretically on Windows 10 – preventing the malware from encryption and ransom.  These steps can be taken proactively.  Due to limited scope of testing at this time, this technique may not work on all systems, release versions, and configurations.

Windows 7 – Adding Keyboard Layout:

Control Panel > Clock, Language, and Region > Region and Language > Keyboards and Languages

Click the “Change Keyboards” tab

In the Installed Services section click “add”

Select Keyboard – For example: Russian (Russia) > Keyboard > Russian

Click “Ok”

Click “Apply”

Click “Ok”

Here is the list of keyboards layouts you can add – any will suffice:

  • Armenian
  • Azeri, (Cyrillic, Azerbaijan)
  • Belarusian
  • Georgian
  • Kazakh
  • Ukrainian
  • Uzbek (Cryillic, Uzbekistan)
  • Uzbek (Latin,Uzbekistan)
  • Russian
  • Tajik

Windows 10 – Adding Language Support:

Control Panel > Language > Add a language

  • Armenian
  • Azeri, (Cyrillic, Azerbaijan)
  • Belarusian
  • Georgian
  • Kazakh
  • Ukrainian
  • Uzbek (Cryillic, Uzbekistan)
  • Uzbek (Latin,Uzbekistan)
  • Russian
  • Tajik

That’s all it takes!  Please note – this should not be considered a fully effective or long-term strategy.  It is highly likely the malware will change based on this finding; thus, we recommend the McAfee product protections referenced above for best effect.

The post Syn/Ack Unique Proactive Protection Technique appeared first on McAfee Blogs.

Cloud Clustering Vulnerable to Attacks

The authors thank John Fokker and Marcelo CaroVargas for their contributions and insights.

In our upcoming talk at the Cloud Security Alliance Summit at the RSA Conference, we will focus our attention on the insecurity of cloud deployments. We are interested in whether attackers can use compromised cloud infrastructure as viable backup resources as well as for cryptocurrency mining and other illegitimate uses. The use of containers has increased rapidly, especially when it comes to managing the deployment of applications. Our latest market survey found that 83% of organizations worldwide are actively testing or using containers in production. Applications need authentication for load balancing, managing the network between containers, auto-scaling, etc. One solution (called a cluster manager) for the automated installation and orchestration of containers is Kubernetes.

Some key components in the Kubernetes architecture appear below:

High-level Kubernetes architecture.

  • Kubernetes master server: The managing machine oversees one or more nodes
  • Node: A client that runs tasks as delegated by the user and Kubernetes master server
  • Pod: An application (or part of an application) that runs on a node. The smallest unit that can be scheduled to be deployed. Not intended to live long.

For our article, we need to highlight the etcd storage on the master server. This database stores the configuration data of the cluster and represents the overall state of the cluster at a given time. Kubernetes saves these secrets in Base64 strings; before Version 2.1 there was no authentication in etcd.

With that knowledge, security researcher Giovanni Collazo from Puerto Rico started to query the Shodan database for etcd databases connected to the Internet. He discovered many and by executing a query, some of these databases started to reveal a lot of credentials. Beyond leaking credentials from databases and other accounts, what other scenarios are possible?

Leaking Credentials

There are several ways that we can acquire credentials for cloud services without hacking into panels or services. By “creatively” searching public sites and repositories, we can find plenty of them. For example, when we searched on GitHub, we found more than 380,000 results for certain credentials. Let’s assume that half of them are useful: We would have 190,000 potentially valid credentials. As Collazo did for etcd, one can also use the Shodan search engine to query for other databases. By creating the right query for Django databases, for example, we were able to identify more cloud credentials. Amazon’s security team proactively scans GitHub for AWS credentials and informs their customers if they find credentials.

Regarding Kubernetes: Leaked credentials, complete configurations of the DNS, load balancers, and service accounts offer several possible scenarios. These include exfiltrating data, rerouting traffic, or even creating malicious containers in different nodes (if the service accounts have enough privileges to execute changes in the master server).

Creating malicious containers.

One of the biggest risks concerning leaked credentials is the abuse of your cloud resources for cryptomining. The adversaries can order multiple servers under your account to start cryptomining, enriching their bank accounts while you pay for the computing power “you” ordered.

Open Buckets

We have heard a lot about incidents in which companies have not secured their Amazon S3 buckets. A number of tools can scan for “open” buckets and download the content. Attackers would be most interested in write-enabled rights on a bucket. For our Cloud Security Alliance keynote address at RSA, we created a list of Fortune 1000 companies and looked for readable buckets. We discovered quite a few. That is no surprise, but if you combine the read-only buckets information with the ease of harvesting credentials, the story changes. With open and writable buckets, the adversaries have plenty of opportunities: storing and injecting malware, exfiltrating and manipulating data, etc.

McAfee cloud researchers offer an audit tool that, among other things, verifies the rights of buckets. As we write this post, more than 1,200 writable buckets belonging to a multitude of companies, are accessible to the public. One of the largest ad networks in the world had a publicly writable bucket. If adversaries could access that network, they could easily inject malicious code into advertisements. (As part of our responsible disclosure process, we reported the issue, which was fixed within hours.) You can read an extensive post on McAfee cloud research and how the analysts exposed possible man-in-the-middle attacks leveraging writable buckets.

Clustering the Techniques

To combat ransomware, many organizations use the cloud to back up and protect their data. In our talk we will approach the cloud as an attack vector for spreading ransomware. With the leaked credentials we discovered from various sources, the open and writable buckets created a groundwork for storing and spreading our ransomware. With attackers having a multitude of credentials and storage places such as buckets, databases, and containers, defenders would have difficulty keeping up. We all need to pay attention to where we store our credentials and how well we monitor and secure our cloud environments.

The post Cloud Clustering Vulnerable to Attacks appeared first on McAfee Blogs.

McAfee Researchers Find Poor Security Exposes Medical Data to Cybercriminals

The nonperishable nature of medical data makes an irresistible target for cybercriminals. The art of hacking requires significant time and effort, encouraging experienced cybercriminals to plot their attacks based on the return they will see from their investment. Those who have successfully gained access to medical data have been well rewarded for their efforts. One seller stated in an interview that “someone wanted to buy all the … records specifically,” claiming that the effort had netted US$100,000.

While at a doctor’s appointment with my wife watching a beautiful 4D ultrasound of our unborn child, I noticed the words “saving data to image” flash on the screen. Although this phrase would not catch the attention of most people, given my research on how cybercriminals are targeting the health care industry, I quickly began to wonder why an ultrasound of our child would not instead save to a file. Intrigued, I decided to dig into the world of medical imaging and its possible security risks. The results were disturbing; ultimately, we were able to combine attack vectors to reconstruct body parts from the images and make a three-dimensional model.


Most hospitals or medical research facilities use PACS, for picture archiving and communication system, so that images such as ultrasounds, mammograms, MRIs, etc. can be accessed from the various systems within their facility, or through the cloud.

A PACS setup contains multiple components, including a workstation, imaging device, acquisition gateway, PACS controller, database, and archiving—as illustrated in the following graphic:

The basic elements of PACS infrastructure.

The imaging device creates a picture, such as an ultrasound or MRI, which is uploaded to an acquisition gateway. Because much of the imaging equipment in use by medical facilities does not align with security best practices, acquisition gateways are placed in the network to enable the digital exchange of the images. The acquisition gateway also often acts as the server connecting to the hospital’s information system (using the HL7 protocol) to enrich images with patient data.

The PACS controller is the central unit coordinating all traffic among the different components. The final component in the PACS infrastructure is the database and archiving system. The system ensures that all images are correctly stored and labeled for either short- or long-term storage.

Larger implementations might have multiple imaging devices and acquisition gateways in various locations, connected over the Internet. During our investigation, we noticed many small medical practices around the world using free, open-source PACS software, which was not always securely implemented.

To determine how many PACS servers are connected depends on on how you search using Shodan, a search engine for finding specific types of computers connected to the Internet. Some servers connect over TCP 104; others use HTTP TCP 80 or HTTPS TCP 443. A quick search revealed more than 1,100 PACS directly connected to the Internet, not behind a recommended layer of network security measures or virtual private networks (VPNs).

PACS systems connected to the Internet. Darker colors represent more systems.

Our eyebrows began to rise very early in our research, as we came across “IE 6 support only” messages or ActiveX controls and old Java support; many of these products are vulnerable to a plethora of exploits. For example, one of the PACS generated an error page when we changed one parameter. This is a very basic common way of testing if the application developers did proper input sanitation check to prevent attackers inserting code or generating failures that could reveal data about the application and can give clues to compromise the system.

A stack-trace error.

The stack-trace dump revealed the use of Apache Tomcat Version 7.0.13, which has more than 40 vulnerabilities.

When communicating with the DICOM (digital imaging and communications in medicine) port, TCP 104, it is possible to grab the banner of a server and get a response. As we queried, we recorded different responses. Let’s look at one:

\x02\x00\x00\x00\x00\xbe\x00\x01\x00\x00ANY-SCP         FINDSCU         \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x10\x00\x00\x151.2.840.10008.!\x00\x00\x1b\x01\x00\x00\[email protected]\x00\x00\x131.2.840.10008.1.2.1P\x00\x00>Q\x00\x00\x04\x00\[email protected]\x00R\x00\x00"1.2.826.0.1.3680043.2.135.1066.101U\x00\x00\x0c1.4.16/WIN32


The FINDSCU string refers to the findscu tool, which can be used to query a PACS system. The DICOM standard defines three data models for the query/retrieve service. Each data model has been assigned with one unique ID for the C-FIND, one for the C-MOVE, and one for C-GET; so all together there are nine unique IDs, three for each model. In the preceding banner, we retrieved two of those IDs:

  • 2.840.10008.1.2.1: A transfer unique ID that defines the value “Explicit VR Little Endian” for data transfer
  • 2.826.0.1.3680043.2.135.1066.101: A value referring to the implementation class

Another value in the banner, “1.4.16/WIN32,” refers to the implementation version. In the context of the medical servers, this refers to the version of XAMPP, aka Apache with MariaDB, PHP, and Perl. This server was running Apache 2.4.9, which is publicly known to contain nine vulnerabilities.

In other cases, there was no need to search for vulnerabilities. The management interface was wide open and could be accessed without credentials.

A PACS interface.

What does this mean? It is possible to access the images.


In addition to expensive commercial PACS systems, open-source or small-fee PACS are available for small health care institutions or practices. As we investigated these systems, we found that our fears were well founded. One web server/client setup used the defaults “admin/password” as credentials without enforcing a change when the server is started for the first time. We found more problems:

  • Unencrypted traffic between client and server
  • Click jacking
  • Cross-site scripting (reflected)
  • Cross-site scripting stored as cross-site request forgery
  • Document object model–based link manipulation
  • Remote creation of admin accounts
  • Disclosure of information

Many of these are ranked on the list of OWASP Top 10 Most Critical Web Application Security Risks list, which highlights severe flaws that should be addressed in any product delivered to a customer.

We have reported the vulnerabilities we discovered to these vendors following our responsible disclosure process. They cooperated with us in investigating the vulnerabilities and taking appropriate actions to fix the issues.

But why should we spend so much time and effort in researching vulnerabilities when there are many other ways to retrieve medical images from the Internet?

Medical Image Formats

The medical world uses several image formats for different purposes. Each format has different requirements and works with different equipment, protocols, etc. A few format examples:

  • NifTi Neuroimaging Informatics Technology Initiative
  • Dicom Digital Imaging and Communications in Medicine
  • MINC Medical Imaging NetCDF
  • NRRD Nearly Raw Raster Data

Searching open directories and FTP servers while using several search engines, we gathered thousands of images—some of them complete MRI scans, mostly in DICOM format. One example:

An open directory of images.

The DICOM format originated in the 1980s, before cybersecurity was a key component. The standard format contains a detailed list of tags such as patient name, station name, hospital, etc. All are included as metadata with the image.

Opening an image with a text editor presents the following screen:

An example of the DICOM file format.

The file begins with the prefix DICM, an indicator that we are dealing with a DICOM file.  Other (now obscured) strings in this example include the hospital’s name, city, patient name, and more.

The Health Insurance Portability and Accountability Act requires a secure medical imaging workflow, which includes the removal or anonymizing of metadata in DICOM files. Researching the retrieved files from open sources and directories, we discovered most of the images still contained this metadata, such as in the following example, from which we extracted (obscured) personally identifiable information (PII).

Metadata discovered in a DICOM file.

Combining Vulnerabilities and Metadata

We combined possible vulnerabilities and the metadata to create a test scenario, installing information from a dummy patient, including an x-ray picture of a knee, to the vulnerable PACS server.

Our test patient record, followed by an x-ray of a knee. 

Using vulnerability information gathered in an earlier phase of research, we launched an attack to gain access to the PACS server. Once we had access, we downloaded the image from our dummy patient and altered the metadata of the image series, changing all references of “knee” to “elbow.”

Altered metadata of the test patient image.

We then saved the picture and uploaded it to the server. Checking the records of our dummy patient, we found our changes were successful.

Changes successfully updated.

Reconstructing Body Parts

In the medical imaging world, a large array of software can investigate and visualize images in different ways, for example, in 3D. We took our collection of images, and using a demo version of 3D software, we reconstructed complete 3D models of vertebrae, pelvis, knees, etc. and, in one case, we reconstructed a partial face.

Because we firmly believe in protecting privacy, the following example—a series of images from a pelvis—comes from a demo file that accompanies the software.

An example of a series of images.

After selecting areas of interest and adjusting the levels, we generated a 3D model of the pelvis:

A 3D model of the pelvis.

The application that generated the 3D model has a feature that allowed us to export the model in several data formats to be used by other 3D drawing programs. After the export, we imported the data into a 3D drawing program and converted the file to STL, a popular format for 3D objects and printers.

In short, we began with files from open directories, transformed them into a 3D model, and printed a tangible model using a 3D printer:

Our 3D model of a pelvis.


When we began our investigation into the security status of medical imaging systems, we never expected we would conclude by reconstructing body parts. The amount of old software used in implementations of PACS servers and the amount of vulnerabilities discovered within the software itself are concerning. We investigated relatively few open-source vendors, but it begs the question: What more could we have found if we had access to professional hardware and software?

Default accounts, cross-site scripting, or vulnerabilities in the web server could lead to access to the systems. Our research demonstrates that once inside the systems, the data and pictures can be permanently altered.

In May 2017, one report claimed that through artificial intelligence pictures could be studied to determine how long a person will live. What if criminals could obtain that information and use it for extortion?

We understand the need for quickly sharing medical data for diagnosis and treatment and for storing medical images. We advise health care organizations to be careful when sharing images on open directories for research purposes and to at least scrape the PII data from the images.

For organizations using a PACS, ask your vendor about its security features. Employ a proper network design in which the sharing systems are properly secured. Think not only about internal security but also about the use of VPNs and two-factor authentication when connecting with external systems.


For more on the health care industry follow @McAfee_Labs and catch up on all threats statistics from Q417 in the March Threats Report.

The post McAfee Researchers Find Poor Security Exposes Medical Data to Cybercriminals appeared first on McAfee Blogs.