Infosec intern assailed eight open source libraries in 11 different ways
Five popular open source libraries used to convert HTML files to PDF documents are vulnerable to server-side request forgery (SSRF), directory traversal, and denial-of-service (DoS) attacks.
Discovered by an intern with just four months’ infosec industry experience, the findings emerged from an ambitious project that tested eight libraries – each written in a different language – against 11 hypotheses.
100% hit rate
Müller, 24, also successfully generated PDFs containing the passwd file, exfiltrated from the server in all five instances by using the XMLHttpRequest object, but failed to replicate the achievement when using the iframe, object, and portal tags.
RELATED Hide and replace: ‘Shadow Attacks’ can manipulate contents of signed PDF docs
The researcher also praised DomPDF for being the only library to provide security recommendations in its documentation, which also references known vulnerabilities.
There is a “plethora of attack scenarios” for exploiting these flaws, Müller tells The Daily Swig. “It really depends on the target’s application/infrastructure.
“A pretty straightforward example is an arbitrary file read, where an adversary could obtain configuration files, PIIs, or even [an] application’s source code. Our experience here at Tempest shows that by having this type of information an attacker usually ends up having a remote code execution.
“A more limited scenario (not less dangerous though) may happen in a cloud environment such as in Amazon AWS,” he adds. “By exploiting a SSRF vulnerability it would be possible to access the AWS EC2 Instance Metadata service, generate temporary tokens, and eventually access other services in AWS.”
He expressed surprise that HTML-PDF conversion could yield so many flaws, and was “astonished” at “how easy it was to read arbitrary files.
“Because of its impacts, it represents a great risk to the application,” he said.
Although the research didn’t surface fixable security vulnerabilities per se, Müller says vendors could still avoid having certain features activated by default, and better document the potential risks of activating them.
They could also “create features that allow the developers to distinguish between data and code”, although “this would require a major redesign and probably break API backward compatibility”.
Müller thanked colleagues who helped him with the project. “They really made the difference,” he says.
Other projects to recently emerge from Tempest’s internship program include the development of Burp Suite extensions that automate failure detection in HTML development, and detect cypher code injection in applications that use Neo4j databases.
YOU MAY LIKE Discord desktop app vulnerable to RCE via chained exploit