Supply chain attacks – when hackers breach suppliers to laterally invade their client’s IT rather than targeting the client companies directly – are nothing new. In 2013, hackers breached the formidable cyber defenses of mega-retailer Target by first breaching a small HVAC provider, learning their login credentials to Target’s system, then bypassing the security measures en route to costing Target over $300 million. Supply chain attacks may be a familiar threat, but it’s one that’s evolving at a breakneck pace…with sinister implications for the entire cybersecurity community.

After increasing steadily for years, supply chain attacks tripled in 2021. The pandemic explains some of that uptick as hackers exploited the widespread disruption in any and every way possible. But supply chain attackers have also adopted a potent new tactic: breaching software developers and hiding malicious code in their products to infect anyone who uses them. Hackers used this technique (known as software supply chain attacks) in the now infamous SolarWinds attack, as well as Log4J, Kaseya, and others, all of which occurred in 2021. And they will continue to launch supply chain attacks of all kinds for the simple reason that these attacks have proven successful, lucrative, and extremely hard to stop.

Hard but not impossible. The UK’s National Cyber Security Centre (which I have highlighted previously for their impressive efforts) recently issued guidance to help organizations harden themselves against supply chain attacks. At this point, most organizations have at least basic cybersecurity protections in place, but too many ignore the protections their suppliers have in place and leave themselves vulnerable to attacks as a result. Consider that good news, though, because it means that supply chain attacks are neither impossible, expensive, nor especially complicated to prevent. It’s more about due diligence upfront than being on-guard 24/7, and the biggest investment is time rather than money. That’s not to say that defending against supply chain easy is easy but rather to emphasize that anyone has the means to get more resilient. Plus, a clear five-step roadmap to follow courtesy of the NCSC. Here’s a quick outline:

1. Preliminary Actions – Before doing anything else, it’s vital to understand (in-depth) the importance of supply chain security and all the potential consequences for failure. Equally important to understand is how the company quantifies, contextualizes, and manages risk more broadly. Lastly, identify the key stakeholders across departments and the roles that each will play in supply chain security (this isn’t a one-person job).
2. Develop an Approach – Start by identifying mission-critical assets and the level of security each takes to protect. Then, develop a framework to assess whether suppliers can deliver that same level of security (or above). Write up contractual clauses to include in every service contract mandating minimum security standards, and create a plan for non-compliance so that security issues can be resolved (or suppliers replaced) as seamlessly as possible.
3. Vet New Suppliers – Use the framework to asses if new suppliers have the required security, and insert the security clauses throughout the contract life-cycle. Key to this effort is educating all staff, especially everyone in procurement, on why and how to make cybersecurity a priority, both when selecting suppliers and when managing ongoing relationships. Supplier reps have lots of leverage. They should use it to insist that suppliers take cybersecurity seriously and hold them accountable when they don’t.
4. Vet Existing Suppliers – Use the framework to evaluate all existing supplier contracts, considering how each supplier creates risk and mitigates it with specific cyber protections and policies. Start with the biggest or most important suppliers. Negotiate with any supplier found to have inadequate security about resolving the situation. If they’re unwilling or unable to improve security, decide if walking away or making concessions is more appropriate. Vet each existing supplier at least once, but make this an ongoing process in order to understand how supplier security has improved or declined since the previous assessment.
5. Constantly Improve – Evaluate how well the framework is working on a continual basis, making adjustments as necessary. The assessment process can be made more efficient and ineffective over time. Furthermore, it must evolve as supply chains, production demands, and cyber threats evolve as well. Prepare to have an ongoing (and sometimes difficult) conversation with suppliers about where and why their security falls short of standards.

This all sounds sensible enough to me, and I would encourage literally every organization (and individuals too) to follow it in some form. Helpful as this advice may be, however, I feel like the fundamental challenge of stopping supply chain attacks remains: it’s hard to accurately evaluate another company’s cybersecurity. They could have problems they’re not aware of or others they know how to hide. More likely, though, is that suppliers are unwilling to be fully transparent, or else clients don’t have the resources to continually do a thorough assessment. And for that reason, trust will continue to play a big role in supply chains – and attacks, I’m afraid, will continue as well.

#cybersecurity #supplychainattacks #NCSC #Trust #SolarWinds #Log4J

Binding Operational Directive 23-01 – Improving Asset Visibility and Vulnerability Detection on Federal Networks

A binding operational directive is a compulsory direction to federal, executive branch, departments and agencies for purposes of safeguarding federal information and information systems.

In November 2021, CISA brought us Binding Operational Directive 22-01. Almost a year later, CISA has unveiled their newest installment, BOD 23-01.

BOD 23-01 is an ambitious step towards strengthening the US Federal Government’s cybersecurity posture in accordance with President Biden’s Executive Order 14028. While the previous directive laid out the requirements regarding vulnerability mitigation and reporting for individual agencies, what we see in 23-01 is a centralization and streamlining of cybersecurity for all Federal Civilian Executive Branch Agencies (FCEB).

Ostensibly, the new directive focuses on asset management and vulnerability enumeration within all FCEB agencies. As one could guess, managing the cybersecurity posture of every asset, including roaming and nomadic devices, across a hundred or so individual agencies is an undertaking that requires a single system.

To combat this issue, CISA has laid out a number of required actions to achieve the following goals:

• Maintain an up-to-date inventory of networked assets as defined in the scope of this directive;
• Identify software vulnerabilities, using privileged or client-based means where technically feasible;
• Track how often the agency enumerates its assets, what coverage of its assets it achieves, and how current its vulnerability signatures are; and
• Provide asset and vulnerability information to CISA’s CDM Federal Dashboard.

The scope of these actions encompasses all FCEB unclassified federal information systems (including information systems used or operated by another entity on behalf of an agency). All reportable information technology or operational technology assets fall within the scope. Only assets like containers or third-party SaaS are excluded.

• The required actions are rigorous by government standards.
• Agencies are expected to perform automated asset discovery every 7 days.
• Initiate vulnerability enumeration across all discovered assets (including nomadic and roaming devices), every 14 days using privileged credentials.
• Vulnerability detection signatures need to be updated within 24 hours of their vendor release.
• All vulnerability enumeration results should be set up for automatic ingestion into the CDM Agency Dashboard.
• Have the ability to perform on-demand asset discovery and vulnerability enumeration within 72 hours of a CISA request.

Within six months of the publication of these requirements, all FCEB agencies are required to collect and report their vulnerability data to CISA. By 3 April 2023,

agencies and CISA, through the CDM program, will deploy an updated CDM Dashboard configuration that enables access to object-level vulnerability enumeration data for CISA analysts, as authorized in the Executive Order on Improving the Nation’s Cybersecurity.

If you aren’t aware of what the Continuous Diagnostics and Mitigation (CDM) program is, think of it as a vulnerability management system that encompasses all FCEB agencies. Information flows from assets within individual agencies to an agency-level CDM dashboard. The data from all agencies is then fed to the Federal Dashboard. This upwards accumulation of data allows CISA to provide a status report to the Secretary of Homeland Security, the Director of OMB, and the National Cybersecurity Director. It also enables CISA to monitor agency compliance.

Seems like CISA is cutting out the middleman when it comes to vulnerability reporting and mitigation to create a cybersecurity monolith.

#CISA #Binding_Operational_Directive #CDMprogram #FCEB

Image by DeepMind

Could federal data protection legislation similar to GDPR in Europe be coming to the US? It looks possible.

The American Data Privacy and Protection Act (ADPPA) emerged from the House Energy and Commerce Committee (by 53-2 vote), and versions of the bill are now working through both houses of Congress. Some obstacles stand in the way (more on that later). But this is the most significant piece of federal data protection legislation since 1974, many think it’s already overdue, and there’s clear momentum, not to mention bipartisan support. So it’s probably a matter of when and how more than if.

Let’s take a closer look at a bill that could change the digital landscape as we know it – with implications for every individual and company in America.

What Does ADPPA Do?

Fundamentally, ADPPA does two things. First, update existing data privacy and protection laws (which are quite weak), for a world awash with digital data. These laws have long lagged behind the realities of collecting, storing, and leveraging data on a massive scale. And with the passage of GDPR followed by similar legislation elsewhere, the US approach to data protection looks like an anachronism and a liability. ADPPA updates the law to the 21st century.

The second thing it does is create federal standards for data protection and privacy. Some states currently mandate data protection, but ADPPA would fill in the gaps for the states that don’t and set minimum standards for all states to follow. How state and federal laws will work together is a point of contention, as we shall see, but federal standards are nonetheless important for making data protection a national priority. ADPPA establishes those standards.

It’s a big bill, as one would expect, but the biggest changes pertain to how companies disclose their data collection practices. Instead of asking for lump permissions (eg. “accept all cookies), companies will have to disclose what type of monitoring they want to conduct and ask for individual permissions. This will make it more transparent what data companies are collecting and give individuals greater control over what companies can and can’t collect. Individuals will also have the right to access data collected over the last 24 months, the right to correct, delete, or transfer (where feasible) any data, and the right to opt-out of targeted advertising and data sharing with third parties.

The Federal Trade Commission (FTC) will enforce ADPPA violations through civil actions, but states attorney general may do the same, and individuals can also file suit. This bill, if it passes, makes data protection a requirement for every company in America. That means cyber attacks, which are already costly in more ways than one, are about to come with much larger legal consequences. ADPPA hasn’t passed yet – but everyone needs to be prepared for if and when it does.

Who Does ADPPA Apply to?

The short answer is everyone – that’s the point of federal legislation. But the law draws some distinctions that are important to highlight. Rules would apply to all data collectors (most companies) and data processors (companies that move data). Smaller companies would be exempt from certain provisions. Meanwhile, the largest data collectors (like Meta and YouTube) would face additional requirements in other cases.

Some critics have called for stricter requirements on the largest companies, noting that the ADPPA gives them broad latitude to collect and use data provided they don’t share it with third parties. Others have pointed out that data risks are the same at large and small companies, so ADPPA should forego size distinctions altogether. Who knows if or how these criticisms will affect the final form of the bill? The regulatory burden could be less or greater than we expect.

Still, no matter what the final form of the bill looks like, it will drastically raise data protection standards from where they are now and force action on the part of any company planning to keep collecting data. Unfortunately, so much about the timing and details remains up in the air.

What’s Standing in the Way of ADPPA?

The biggest obstacle is the California Consumer Privacy Act (CCPA), currently the most stringent data protection standard at the state level, and more demanding overall than what ADPPA requires. In its present form, ADPPA would supersede the California requirements, effectively lowering the bar and undercutting the (important and often impressive) working being done there.

The solution seems simple enough: change the language of the bill to make the ADPPA the minimum required standards, then let states erect stricter standards on top. But state’s rights issues inspire strange turf wars. And, as a result, the ADPPA is somewhat stuck in limbo. Some resolution is coming – even the most ardent critics of the bill acknowledge that it’s time for federal standards. But when it will arrive and what provisions look like is a guessing game.

I’m personally feeling optimistic about ADPPA passing before the mid-term elections. And even if it doesn’t, the fact that this bill enjoys such rare bipartisan support suggests that no change in the congressional makeup would prevent its passage – but perhaps I’m expecting too much from a governing body mostly known for gridlock.

#ADPPA #GDPR #Congress #DataProtection #DataPrivacy #Legislation

CISA has been taking their Industrial Control System security priority seriously with over 30 advisories released in the last couple months.

The most recent advisories cover Advantech R-SeeNet, a router monitoring application used; and Hitachi Energy APM Edge, an asset performance tracker specifically for power transformers.

These advisories cover a number of CVEs for each application and, in the case of R-SeeNet, involve the usual scumbag known as remote code execution.

ICSA-22-291-01 – R-SeeNet (Advantech)

Affected Critical Infrastructure Sectors: Critical Manufacturing, Energy, Water and Wastewater Systems

Reported by rgod, working with Trend Micro Zero Day Initiative.

Vulnerabilities:

CVE-2022-3387: “Path traversal attack. An unauthorized attacker could remotely exploit vulnerable PHP code to delete .PDF files.”

CVSS v3 score: 6.5

CVE-2022-3386: “Stack-based buffer overflow. An unauthorized attacker can use an outsized filename to overflow the stack buffer and enable remote code execution.”

CVSS v3 score: 9.8

CVE-2022-3385: “Stack-based buffer overflow. An unauthorized attacker can remotely overflow the stack buffer and enable remote code execution.”

CVSS v3 score: 9.8

Mitigation: Update R-SeeNet to Version 2.4.12 or later.

CISA also recommends minimizing network exposure for all control systems and isolating them from the Internet.

ICSA-21-336-06 – APM Edge (Hitachi Energy)

Affected Critical Infrastructure Sectors: Energy

Reported by Hitachi Energy

Vulnerabilities:

Reliance on Uncontrolled Component (CWE-1357): Because APM Edge uses a number of open-source software components, a successful exploitation could cause the product to become inaccessible.

29 total vulnerabilities are involved in this advisory, with the worst case given a CVSS v3 score of 8.2.

Mitigation: update APM Edge to v4.0.

Hitachi also recommends certain security practices and firewall configurations that can be found on the CISA advisory page (linked above) and Hitachi’s advisory that can be downloaded as a PDF from CISA’s advisory page as well.

Image by American Public Power Association

#CISA #Advisory #Industrial_Control_Systems

As one of the most popular languages, Python has a wide presence in any large-scale development project. As per a survey in 2021, 48.07% chose Python as their favorite programming language. Along with it being a favorite language amongst developers, there is also a thriving community. The Python Package Index (PyPI) is a repository hosting over 10TB of packages that programmers use to build their products.

Once published on PyPI, packages are available for anyone to install. This makes it critical for developers to ensure their packages are secure because if a package is vulnerable, every application that integrates it becomes vulnerable. In this blog, I will illustrate the risk of a vulnerable package called “yacmmal”, walk through the process of exploit development, and develop the zero-day exploit for the package, as well as provide a solution for mitigating the risk.

What is yacmmal?

Yet Another Config Manager for Machine Learning (yacmmal) automatically loads configuration files for machine learning projects (and removes the hassle). Yacmmal is built on top of pydantic. The package automatically creates dataclasses from various file formats such as YAML, JSON and CSV.

Installation

As we are targeting the latest version of yacmmal, we will install the latest package from PyPI with pip

“` pip install yacmmal “`

Vulnerability

Now, to find the vulnerability, we will analyze the publicly available source code on their repository. https://github.com/juselara1/yacmmal

Figure 1: yacmmal Github repository

Here, yacmmal contains the main logic

Figure 2: Inside the yacmmal folder

The load folder contains the logic for loading various file types. Here, yaml.py looks interesting as it is very common for python developers to configure serialization and deserialization on yaml files incorrectly.

Figure 3: Inside the load folder

Taking a look at the file, we can see that it imports yaml and has defined class YAMLLoader which is a loader for yaml files and a base path to the yaml file which needs to be loaded.

Figure 4: Yaml file code

The YAMLLoader class has two functions defined: init and load.

The load function takes the path to the yaml file and a data class to use as arguments and returns the loaded model.

Taking a closer look, we can see that the load function unsafely loads the yaml file with yaml.load without the safe loader. So, it is vulnerable to a YAML deserialization attack and can grant remote command execution to an attacker.

Implementation

To analyze the vulnerability, we will exploit a program that uses the yacmmal package.

This example program can be found in the example directory of yacmmal github repository.

Our example program loads two configuration files, hp_file and ep_file, from the config directory and loads them to generate a model.

Vulnerability Test

First, we need to create a basic yaml exploit to check if the vulnerability exists or not.

According to the pyyaml documentation, the yaml.dump function accepts a Python object and produces a YAML document.

So, opening the python interpreter, we import the yaml package and test. 

We pass a string (AAAA) to the yaml.dump function which generates a yaml document and we print it.

In the same way, we can pass a function to dump. Here, “!!python/object/apply:builtins.range” is the serialized object and 1,4,1 are the arguments passed to the function.

Same way, we can modify the serialized object for sleep function instead of range. The second line takes 4 seconds before finishing the execution. We will use the time.sleep payload to test if our Yacmmal application is vulnerable.

As our application takes hp_file.yaml configuration from the config directory, we will modify the hp_file.yaml to contain our basic exploit.

As we can see, the program takes 4 seconds before throwing us an error, which means our basic exploit was successful and now we can modify our exploit to get the command execution.

Command Execution

From our basic exploit (!!python/object/apply:time.sleep [4]) we replace time.sleep function with os.system and pass our command as argument.

So now our final exploit would be:

!!python/object/apply:os.system [“id;whoami”]

Running the exploit, we can see that we get successful command execution.

Solution

As this exploit is not known and no patches are available for Yaccmal, the usage of the package should be avoided until any patches are public. If the usage of the package is necessary, the following change should be made:

For the file yacmmal/load/yaml.py, 

Replace line 37 

data = yaml.load(f, Loader=yaml.Loader)

With 

data = yaml.load(f, Loader=yaml.SafeLoader)

#NCSAM #exploit #yacmmal #research #zeroday #vicarius_blog