Proof of Concept: Repetier Server =<v.1.4.10 – Multiple Vulnerabilities (LFI, CSRF, Disclosure of Credentials, etc.)

Research by Ken Pyle, Exploit Developer and Partner @ CYBIR

Repetier Server – Local File Include and SYSTEM Rights to Endpoint Compromise (Windows PoC provided).


Local File Inclusion (LFI) is a type of web application vulnerability that allows an attacker to include files on the web server by exploiting the input validation of the application. LFI vulnerabilities occur when a web application integrates attacker controlled input without sanitizing abusive input, allowing an attacker to traverse the file system and read arbitrary files on the server.

This can include sensitive files such as configuration files, password files, or executable files that can be leveraged to obtain code execution. LFI attacks are dangerous as they can allow an attacker to gain access to sensitive information or execute malicious code on the server.

In the following PoC, the file traversal / inclusion vulnerability is used to download sensitive files (SQL) containing authentication information (password hash, API keys, username). This allows for theft of credentials and compromise of the application and server / operating system.

curl -i -s -k -X $’GET’ \

    -H $’Host: cybirpoc.com’ -H $’Connection: close’ -H $’Content-Length: 2′ \

    –data-binary $’\x0d\x0a’ \

    $’http://cybirpoc.com:3344/views..%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5cProgramData%5cRepetier-Server%5cdatabase%5cuser.sql%20/base/connectionLost.php’

Disclosure of Credentials / Sensitive files via LFI (user.sql shown)

The service executes as SYSTEM, providing the web server with excessive rights. This can allow an attacker to read sensitive, protected content from the operating system, resulting in full compromise. (seen above)

PoC request for LFI

Lack of CSRF Controls & Host Header Injection

CSRF (Cross-Site Request Forgery) is a type of web security vulnerability that allows an attacker to trick a user into performing an action they did not intend to on a website. In a CSRF attack, the attacker sends a specially crafted request to a website on behalf of the victim, which can result in the victim unknowingly performing an action such as making a payment or changing their password. This type of attack can be prevented by implementing measures such as using anti-CSRF tokens, checking the origin of the request, and limiting the use of cookies.

Host header injection is a web security vulnerability that allows an attacker to manipulate the host header value in an HTTP request to bypass security controls or perform attacks such as phishing or cookie theft. The host header is a part of the HTTP request that specifies the domain name of the website being accessed.

An attacker can exploit this vulnerability by injecting a modified host header value in the HTTP request, which may allow them to trick the server into processing the request in unintended ways or accessing resources on a different domain. For example, an attacker may modify the host header value to point to a different website that they control, allowing them to intercept traffic and steal sensitive information such as user credentials or session cookies. This can also be used to bypass firewall rules and deliver attack code through DNS manipulation.

Host Header Injection / Lack of CSRF Controls

Plaintext Transmission of Passwords / Credentials via HTTP GET Request

When a user logs into a website using a password, the password is typically transmitted from the user’s computer to the website’s server using the HTTP protocol. This transmission of password data over HTTP is risky because HTTP is an unencrypted protocol, which means that the password can be intercepted and read by anyone who has access to the network traffic. This can include attackers who are able to intercept the traffic, such as through a man-in-the-middle attack.

As a result, sending passwords over HTTP is considered insecure and can put users at risk of having their accounts compromised. To address this issue, websites should use HTTPS, which encrypts the traffic between the user’s computer and the website’s server, making it much more difficult for an attacker to intercept and read the password. Additionally, websites should also implement secure password storage practices, such as hashing and salting passwords, to protect user passwords even in the event of a data breach.

Sending passwords via the HTTP GET method is considered insecure because the password is transmitted in clear text in the URL, which can be easily intercepted and read by anyone who has access to the network traffic. This can include attackers who are able to intercept the traffic, such as through a man-in-the-middle attack or by accessing the browser history.

Additionally, URLs with passwords in them may also be cached in web browser history or saved in browser bookmarks, which can expose the password to unauthorized users who have access to the user’s computer.

As a result, sending passwords via the HTTP GET method is not recommended. Instead, passwords should be sent via the HTTP POST method or via HTTPS, which encrypts the traffic between the user’s computer and the website’s server, making it much more difficult for an attacker to intercept and read the password.

Missing XSS Filtering Headers & Sanitization Controls

XSS (Cross-Site Scripting) is a web security vulnerability that allows an attacker to inject malicious scripts into a web page viewed by other users. A common defense against XSS attacks is to use an XSS filter, which is a feature implemented in modern web browsers that helps detect and prevent the execution of malicious scripts.

The application is vulnerable to XSS and arbitrary content injection through undisclosed vectors.

The lack of an XSS filter header means that the web server is not instructing the web browser to enable an XSS filter. This can potentially leave the website vulnerable to XSS attacks, as the browser may not be configured to detect and prevent malicious scripts.