{"id":55402,"date":"2022-08-11T09:24:14","date_gmt":"2022-08-11T01:24:14","guid":{"rendered":"https:\/\/version-2.com\/?p=55402"},"modified":"2022-08-19T15:16:53","modified_gmt":"2022-08-19T07:16:53","slug":"exploiting-google-slo-generator-with-python-yaml-deserialization-attack","status":"publish","type":"post","link":"https:\/\/version-2.com\/en\/2022\/08\/exploiting-google-slo-generator-with-python-yaml-deserialization-attack\/","title":{"rendered":"Exploiting Google SLO Generator with Python YAML Deserialization Attack"},"content":{"rendered":"
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

<\/p>\n

Introduction<\/h3>

A patch was released<\/u><\/a> in September of 2021, so users who updated their code won’t be exposed to this attack. Users who have not updated should do so as soon as possible. It is unknown how many of the ~167,000 applications that use this library are running vulnerable versions. The purpose of this exercise is to encourage developers to update to an adequately protected version, detailed throughout this blog.<\/p>

What is SLO Generator?<\/h3>

According to their Github page, SLO Generator is a tool to compute and export Service Level Objectives, Error Budgets and Burn Rates, using Configurations written in YAML or JSON. In layman\u2019s terms, it\u2019s a tool for engineers who wish to track their web API performance. Many Google services, along with other projects wishing to record these metrics, use this tool.<\/p>

SLO Generator Python library can be directly installed from PyPI with pip<\/p>

Figure 1: Installing the SLO Generator Python library<\/em><\/p>

Usage<\/h3>

Once installed, it is easy to generate the SLO report with the command line interface<\/p>

“`slo-generator compute -f slo_config -c shared_config \u2013export“`<\/p>

Here, <\/p>

Compute argument to the slo-generator indicates that we want to generate a SLO report<\/p>

The tool also provides the functionality to migrate older, version 1 configuration to newer, version 2 configuration.<\/p>

“`slo-generator migrate -s old_config\/ -t new_config -b error_budget_policy\/config.yaml “`<\/p>

For a successful migration, the migrate command needs 3 inputs from the user:<\/p>

  1. a directory containing old SLO configurations.<\/li>
  2. a directory containing newer slo configurations<\/li>
  3. a yaml file containing error_budget_policy<\/li><\/ol>

    Exploitation<\/h3>

    There are several techniques to find a potential vulnerability in older versions, such as manually combing through the source code, fuzzing the application, or analyzing recent patches to the application. <\/p>

    Let\u2019s analyze the recent patches first, attempting to discover any potential vulnerabilities. SLO Generator is an open-source tool; this information is all publicly available on their Github repository<\/u><\/a>.<\/p>

    Looking through the release notes of version 2.0.1, we can see that they fixed the yaml loader security issue, meaning older versions of SLO Generator (i.e. v 2.0.0) would have the yaml loader vulnerability.<\/p>

    Figure 2: Version 2.0.1 fixes the yaml loader security issue<\/em><\/p>

    Looking at the changed files, we can see that in the patch, developers have replaced yaml.Loader, which is vulnerable, with yaml.SafeLoader.<\/p>

    Figure 3: Developers replace yaml.Loader with yaml.SafeLoader<\/u><\/em><\/a><\/p>

    Looking at the official documentation for pyyaml, it is mentioned that calling yaml.load on any untrusted data is as dangerous as pickle.load, a common attack path making it possible to provide malicious shellcode as input, causing remote code execution.<\/p>

    This indicates that if we can control the data which is passed to the yaml.load function, we can perform a python deserialization attack to get the code execution on the application.<\/p>

    Looking through the changes, we see there is a function called \u2018ebp_v1tov2\u2019, which is calling the yaml.load function on a variable called \u201cconf\u201d. As we can see on line 262, every file in the variable ebp_paths will be passed through yaml.load as \u201cconf\u201d.<\/p>

    Figure 4: Dissecting code line 264 for yaml.load<\/em><\/p>

    As per line 70, ebp_paths <\/strong>is a list containing files in error_budget_policy_path <\/strong>which we pass to the application.<\/p>

    Figure 5: Code line 70<\/em><\/p>

    Creating the Exploit<\/h3>

    Our first step is to create a malicious python deserialization object that we store in a yaml path. Next, we call the migrate function with error_budget_policy_path <\/strong>pointing to our malicious file. Our malicious file will be loaded by the application and our code will be executed.<\/p>

    As generating a yaml deserialization payload is out of the scope, we will find a common deserialization payload and copy it to our attack yaml file as exploit.yaml.<\/p>

    Figure 6: Deserialization payload with exploit.yaml<\/em><\/p>

    Now, running the following command to exploit the application:<\/p>

    Figure 7: Command to execute payload<\/em><\/p>

    As SLO Generator is a widely used python library, a code execution vulnerability makes it more severe. A typical exploit scenario would be executed in a web application to migrate user-supplied configuration.<\/p>

    Solution<\/h3>

    All instances of SLO Generator should be updated to the latest version. Most applications handle user-supplied yaml data. Yaml data should always be handled correctly. Avoid using unsafe functions such as yaml.load<\/strong>, and replace it with yaml.SafeLoad. <\/strong>At an absolute minimum, it is imperative that all instances be updated past \u2018yaml loader security issue 173<\/u><\/a>\u2019 to protect against this exploit.<\/p>

    Key Takeaways<\/h3>

    This exploit shows the severity of using unsafe functions such as yaml.load. Any application that processes user data directly should always handle data with extreme caution. From an attacker\u2019s perspective, if an application is processing user input directly to a yaml.load function, the application could be vulnerable to the Python YAML deserialization attack.<\/p>

    Best Practices<\/h3>