CSRF in Plesk API enabled server takeover

Bugs in programming interfaces of web hosting admin tool patched

The REST API of Plesk was vulnerable to client-side request forgery (CSRF), which could lead to multiple potential attacks, including malicious file upload and the takeover of the server.

Plesk is a very popular administration tool for web hosting and data center providers. Users usually use its web interface to administer their websites and file servers. This interface has been exhaustively tested and patched against security holes.

However, according to the findings of Adrian Tiron, a security researcher at Fortbridge, the REST API that allows third-party programs access to Plesk’s functionality was not as sturdy as its web user interface counterpart.

Client-side request forgery

While investigating Plesk during a project for one of his clients, Tiron discovered that when the REST API is called from the browser of a logged-in administrator, there are no defences against CSRF. This shortcoming meant that if an attacker lures the Plesk admin to visit a malicious page, they could stage cookieless CSRF attacks against the server.

Catch up with the latest security research news and analysis

Several API endpoints could be attacked through the cookieless CSRF exploit. The most interesting, said Tiron, was an endpoint that supported different commands, including changing the administrator’s password. Using this endpoint, the researcher was able to hijack the admin user account and gain full control of the host.

“Admin access in Plesk is very powerful. It’s identical to having root [access] because Plesk is used to fully manage hosts via the web interface,” Tiron told The Daily Swig.

Other minor bugs

Other endpoints could be exploited through other CSRF attacks, including exploits that allowed the creation of MySQL and FTP users on the Plesk server.

Since the MySQL port is blocked externally by default, adding a database user would have a limited impact.

“However, if [MySQL] is misconfigured, it can give RCE [remote code execution] on the server as a limited user – we estimate this would be a rare scenario,” Tiron said.

The FTP user would give the attacker “RCE as a limited user (at least) because the attacker can upload a web shell,” he added.

What went wrong?

Plesk’s web interface uses the Authorization header, which prevents unauthenticated access to the pages of the administration tool. Once a user enters their credentials, the browser automatically adds appropriate headers to the requests, enabling the server to distinguish authenticated users.

Authorization headers also prevented random unauthenticated access to the REST API endpoints. But all this can potentially be circumvented through HTML-based CSRF attacks.

“The developers probably thought that they’re protected against the CSRF because they’re using the Authorization header,” Tiron said. “While this is true for requests created with XHR (the attacker would need to know this header to add it to the request), this is not true if you’re using HTML forms – in this case, the browser attaches the Authorization header automatically, by design.”

Plesk has patched the bug. According to the company, 98.4% of Plesk servers have been automatically updated and were therefore not impacted.

Tiron recommended that developers make sure that all POST requests that change the server state implement CSRF mitigation using either the synchronizer token pattern or the double submit cookie pattern. “Based on our experience we recommend the first,” Tiron concluded.

RELATED Prototype pollution bug exposed Ember.js applications to XSS