The IT Nerd

JFrog researchers have discovered unprotected endpoints from older versions of Prometheus event monitoring and alerting solutions. Prometheus, an open-source system monitoring and alerting toolkit, is used to collect and process metrics from different endpoints, enabling easy observation of software metrics such as memory usage, network usage and software-specific denied metrics, such as the number of failed logins to a web application. Large-scale unauthenticated scraping of publicly available and non-secured endpoints could be leveraged to leak sensitive information. Which isn’t good seeing that Prometheus is meant to help protect corporate environments.

Giora Engel, CEO and Cofounder, Neosec:

“Prometheus, like many other systems, are all based on APIs for accessing the data and managing the systems. Those systems are spun up frequently without any supervision, they are typically meant for internal use and are poorly secured, if at all. Being able to discover all the exposed APIs and finding cases of weak security is essential in order to remediate and prevent data loss. You can never rely on what’s known and documented in these cases – being able to monitor actual traffic typically discovers all those unknown services that are poorly configured.”

If you have Prometheus, now would be a very good time to update them. Because now that this is out, you can be sure that someone will try to leverage this.

Earlier this week, Microsoft announced that Microsoft Azure successfully fended off the largest DDoS attack on an Azure cloud customer to date:

The attack itself came from over 70,000 sources. It was orchestrated from multiple Asia-Pacific countries such as Malaysia, Vietnam, Taiwan, Japan, and China, and from the United States. 

The attack vector was a User Datagram Protocol (UDP) reflection attack. The attack lasted over 10 minutes with very short-lived bursts. Each of these bursts ramped up in seconds to terabit volumes. In total, Microsoft saw three main peaks, the first at 2.4 Tbps, the second at 0.55 Tbps, and the third at 1.7 Tbps.

In a UDP reflection attack, the attacker exploits the fact that UDP is a stateless protocol. That means the attackers can create a valid UDP request packet listing the attack target’s IP address as the UDP source IP address. It looks as if the attack is being reflected back and forth within the local network, hence the name. This relies on the UDP request packet’s source Internet Protocol (IP) being spoofed, i.e. falsified. The UDP packet contains the spoofed source IP and is sent by the attacker to a middleman server. The server is tricked into sending its UDP response packets to the targeted victim IP rather than back to the attacker. The middleman machine helps strengthen the attack by generating network traffic that is several times larger than the request packet, thus amplifying the attack traffic.

The fact that Microsoft was able to fend off this attack shows how resilient Microsoft’s defenses are. I got some additional commentary from Tim Grelling, Director of Innovation, Security at Core BTS Jason Barr, Senior Director of Innovation at Core BTS:

“While there’s understandable concern surrounding the cloud during an age of incessant breaches, Azure is the most secure offering on the market, as proven by the platform’s ability to fend off this attack. Over ninety percent of Fortune 500 companies use the Azure suite of services with little issue, and this is a strong example of why. The Azure suite can be highly modified for the security needs of individual clients. This ensures that the fatal “one size fits all” approach to security isn’t an issue for Azure users, resulting in safer storage of data.”

This in my mind makes moving to Azure a viable option for companies moving to the cloud as clearly Azure is capable of defending attacks like this.

New research from Alissa Knight of Knight Ink shows critical flaws found in FHIR APIs which makes them vulnerable to abuse. In the report, Knight examined three FHIR APIs across an app ecosystem of 48 FHIR apps and APIs and aggregated her data from more than 25,000 health care providers and payers. Key findings show:

• Three production FHIR APIs serving an ecosystem of 48 apps and APIs were tested
• The ecosystem covered aggregated EHR data from 25,000 providers and payers
• 4m patient and clinician records could be accessed from 1 single patient login account
• 53% of mobile apps tested had hardcoded API keys and tokens which could be used to attack EHR APIs
• 100% of FHIR APIs tested allowed API access to other patient’s health data using one patient’s credentials.
• 50% of clinical data aggregators did not implement database segmentation allowing access to patient records belonging to other apps developed on their platform for other providers.
• 100 percent of the mobile apps tested did not prevent person-in-the-middle attacks, enabling hackers to harvest credentials and steal or manipulate confidential patient data.

That’s not trivial. And Giora Engel, CEO and Cofounder, Neosec agrees:

“The regulatory requirements to expose healthcare data for patient access and payer interoperability forced a fast pace of digital transformation in many healthcare systems. Part of that transformation exposes inherent security risks. “

“The main problems that we see today are:

1. No API inventory creates a blind spot for the security team. APIs that are not known to the security team can’t be reviewed and protected. 
2. Implementation errors and misconfigurations
3. Abuse of APIs – by authorized users or clients 

Visibility into the API footprint and behavior is an essential part of the digital transformation. “

I got additional commentary on this story. Saryu Nayyar, CEO, Gurucul had this to say: 

   “Healthcare software continues to be a sick child in supporting cybersecurity standards in the US.  Researchers have recently shown that the Fast Healthcare Interoperability Resources (FHIR) healthcare data standard has several flaws that can enable individual users to access many other health records.

While all software can be flawed in terms of security, we need to do a better job with our health care systems. We don’t typically subject health care software to any additional scrutiny, and it’s time that we did.  Software that is safety or security critical needs to be held to a higher standard, and health care is at the top of that list.”

Also, Doug Britton, CEO, Haystack Solutions had this to say:

   “This story highlights the growing and changing attack surface that 3rd party data aggregators bring and the difficulty with balancing security with convenience, access, and openness of data ecosystems. These factors are often fundamentally at odds with each other. Medical records are some of the most complexly regulated and prolific data types. Congressional legislation governing the treatment (e.g. security & handling) and access creates a challenging dynamic. Securing an app ecosystem may not be as straightforward as conceptualizing it may be. Even with design standards in place the very implementation creates the weak points hackers are so good at finding. These findings highlight the need to slow down access until design standards are established and tested. 

   “We also need to continue to invest in the next generation of cyber professionals who are experts at secure system design and development. We have the tools to find them. We need to get them into the fight and secure our critical infrastructure so we may realize the promise of FHIR.”

Seeing as sharing healthcare data is important these days, all parties involved need to do their parts to make sure that health care data remains secure.