PDF Hacking | Breaking Cybersecurity News | The Hacker News

Researchers have disclosed an unpatched security vulnerability in " dompdf ," a PHP-based HTML to PDF converter, that, if successfully exploited, could lead to remote code execution in certain configurations. "By injecting CSS into the data processed by dompdf, it can be tricked into storing a malicious font with a .php file extension in its font cache, which can later be executed by accessing it from the web," Positive Security researchers Maximilian Kirchmeier and Fabian Bräunlein  said  in a report published today. In other words, the flaw  allows  a malicious party to upload font files with a .php extension to the web server, which can then be activated by using an  XSS vulnerability  to inject HTML into a web page before it's rendered as a PDF. This meant that the attacker could potentially navigate to the uploaded .php script, effectively permitting remote code execution on the server. This can have significant consequences on websites that require

Researchers have demonstrated a novel class of attacks that could allow a bad actor to potentially circumvent existing countermeasures and break the integrity protection of digitally signed PDF documents. Called " Shadow attacks " by academics from Ruhr-University Bochum, the technique uses the "enormous flexibility provided by the PDF specification so that shadow documents remain standard-compliant." The findings were presented yesterday at the Network and Distributed System Security Symposium (NDSS), with 16 of the 29 PDF viewers tested — including Adobe Acrobat, Foxit Reader, Perfect PDF, and Okular — found vulnerable to shadow attacks. To carry out the attack, a malicious actor creates a PDF document with two different contents: one which is the content that's expected by the party signing the document, and the other, a piece of hidden content that gets displayed once the PDF is signed. "The signers of the PDF receive the document, review it, and s

Identities now transcend human boundaries. Within each line of code and every API call lies a non-human identity. These entities act as programmatic access keys, enabling authentication and facilitating interactions among systems and services, which are essential for every API call, database query, or storage account access. As we depend on multi-factor authentication and passwords to safeguard human identities, a pressing question arises: How do we guarantee the security and integrity of these non-human counterparts? How do we authenticate, authorize, and regulate access for entities devoid of life but crucial for the functioning of critical systems? Let's break it down. The challenge Imagine a cloud-native application as a bustling metropolis of tiny neighborhoods known as microservices, all neatly packed into containers. These microservices function akin to diligent worker bees, each diligently performing its designated task, be it processing data, verifying credentials, or