Blog di AlùK

PART II

Wirelurker for Windows (WinLurker)

Research: Palo Alto Claud Xiao: Wirelurker for Windows

Sample credit: Claud Xiao

PART I

Research: Palo Alto Claud Xiao WIRELURKER: A New Era in iOS and OS X Malware

Palo Alto |Claud Xiao - blog post Wirelurker

Wirelurker Detector https://github.com/PaloAltoNetworks-BD/WireLurkerDetector

Sample credit: Claud Xiao

Download

Download Part I
Download Part II

Email me if you need the password

List of files

List of hashes

Part II

s+«sìÜ 3.4.1.dmg 925cc497f207ec4dbcf8198a1b785dbd

apps.ipa 54d27da968c05d463ad3168285ec6097
WhatsAppMessenger 2.11.7.exe eca91fa7e7350a4d2880d341866adf35
使用说明.txt 3506a0c0199ed747b699ade765c0d0f8
libxml2.dll c86bebc3d50d7964378c15b27b1c2caa
libiconv-2_.dll 9c8170dc4a33631881120a467dc3e8f7
msvcr100.dll bf38660a9125935658cfa3e53fdc7d65
libz_.dll bd3d1f0a3eff8c4dd1e993f57185be75
mfc100u.dll f841f32ad816dbf130f10d86fab99b1a

zlib1.dll c7d4d685a0af2a09cbc21cb474358595

│ apps.ipa
│ σ╛«σìÜ 3.4.1.dmg
│
└───WhatsAppMessenger 2.11.7
libiconv-2_.dll
libxml2.dll
libz_.dll
mfc100u.dll
msvcr100.dll
WhatsAppMessenger 2.11.7.exe
zlib1.dll
使用说明.txt

Part I

BikeBaron 15e8728b410bfffde8d54651a6efd162
CleanApp c9841e34da270d94b35ae3f724160d5e
com.apple.MailServiceAgentHelper dca13b4ff64bcd6876c13bbb4a22f450
com.apple.appstore.PluginHelper c4264b9607a68de8b9bbbe30436f5f28
com.apple.appstore.plughelper.plist 94a933c449948514a3ce634663f9ccf8
com.apple.globalupdate.plist f92640bed6078075b508c9ffaa7f0a78
com.apple.globalupdate.plist f92640bed6078075b508c9ffaa7f0a78
com.apple.itunesupdate.plist 83317c311caa225b17ac14d3d504387d
com.apple.machook_damon.plist 6507f0c41663f6d08f497ab41893d8d9
com.apple.machook_damon.plist 6507f0c41663f6d08f497ab41893d8d9
com.apple.MailServiceAgentHelper.plist e6e6a7845b4e00806da7d5e264eed72b
com.apple.periodic-dd-mm-yy.plist bda470f4568dae8cb12344a346a181d9
com.apple.systemkeychain-helper.plist fd7b1215f03ed1221065ee4508d41de3
com.apple.watchproc.plist af772d9cca45a13ca323f90e7d874c2c
FontMap1.cfg 204b4836a9944d0f19d6df8af3c009d5
foundation 0ff51cd5fe0f88f02213d6612b007a45
globalupdate 9037cf29ed485dae11e22955724a00e7
globalupdate 9037cf29ed485dae11e22955724a00e7
itunesupdate a8dfbd54da805d3c52afc521ab7b354b
libcrypto.1.0.0.dylib 4c5384d667215098badb4e850890127b
libcrypto.1.0.0.dylib 3b533eeb80ee14191893e9a73c017445
libiconv.2.dylib 94f9882f5db1883e7295b44c440eb44c
libiconv.2.dylib fac8ef9dabdb92806ea9b1fde43ad746
libimobiledevice.4.dylib c596adb32c143430240abbf5aff02bc0
libimobiledevice.4.dylib 5b0412e19ec0af5ce375b8ab5a0bc5db
libiodb.dylib bc3aa0142fb15ea65de7833d65a70e36
liblzma.5.dylib 5bdfd2a20123e0893ef59bd813b24105
liblzma.5.dylib 9ebf9c0d25e418c8d0bed2a335aac8bf
libplist.2.dylib 903cbde833c91b197283698b2400fc9b
libplist.2.dylib 109a09389abef9a9388de08f7021b4cf
libssl.1.0.0.dylib 49b937c9ff30a68a0f663828be7ea704
libssl.1.0.0.dylib ab09435c0358b102a5d08f34aae3c244
libusbmuxd.2.dylib e8e0663c7c9d843e0030b15e59eb6f52
libusbmuxd.2.dylib 9efb552097cf4a408ea3bab4aa2bc957
libxml2.2.dylib 34f14463f28d11bd0299f0d7a3985718
libxml2.2.dylib 95506f9240efb416443fcd6d82a024b9
libz.1.dylib 28ef588ba7919f751ae40719cf5cffc6
libz.1.dylib f2b19c7a58e303f0a159a44d08c6df63
libzip.2.dylib 2a42736c8eae3a4915bced2c6df50397
machook 5b43df4fac4cac52412126a6c604853c
machook ecb429951985837513fdf854e49d0682
periodicdate aa6fe189baa355a65e6aafac1e765f41
pphelper 2b79534f22a89f73d4bb45848659b59b
sfbase.dylib bc3aa0142fb15ea65de7833d65a70e36

sfbase.dylib bc3aa0142fb15ea65de7833d65a70e36
sfbase_v4000.dylib 582fcd682f0f520e95af1d0713639864
sfbase_v4001.dylib e40de392c613cd2f9e1e93c6ffd05246
start e3a61139735301b866d8d109d715f102
start e3a61139735301b866d8d109d715f102
start.sh 3fa4e5fec53dfc9fc88ced651aa858c6
stty5.11.pl dea26a823839b1b3a810d5e731d76aa2
stty5.11.pl dea26a823839b1b3a810d5e731d76aa2
systemkeychain-helper e03402006332a6e17c36e569178d2097
watch.sh 358c48414219fdbbbbcff90c97295dff
WatchProc a72fdbacfd5be14631437d0ab21ff960
7b9e685e89b8c7e11f554b05cdd6819a 7b9e685e89b8c7e11f554b05cdd6819a
update 93658b52b0f538c4f3e17fdf3860778c
start.sh 9adfd4344092826ca39bbc441a9eb96f

File listing

├───databases

│ foundation

│

├───dropped

│ ├───version_A

│ │ │ com.apple.globalupdate.plist

│ │ │ com.apple.machook_damon.plist

│ │ │ globalupdate

│ │ │ machook

│ │ │ sfbase.dylib

│ │ │ watch.sh

│ │ │

│ │ ├───dylib

│ │ │ libcrypto.1.0.0.dylib

│ │ │ libiconv.2.dylib

│ │ │ libimobiledevice.4.dylib

│ │ │ liblzma.5.dylib

│ │ │ libplist.2.dylib

│ │ │ libssl.1.0.0.dylib

│ │ │ libusbmuxd.2.dylib

│ │ │ libxml2.2.dylib

│ │ │ libz.1.dylib

│ │ │

│ │ ├───log

│ │ └───update

│ ├───version_B

│ │ com.apple.globalupdate.plist

│ │ com.apple.itunesupdate.plist

│ │ com.apple.machook_damon.plist

│ │ com.apple.watchproc.plist

│ │ globalupdate

│ │ itunesupdate

│ │ machook

│ │ start

│ │ WatchProc

│ │

│ └───version_C

│ │ com.apple.appstore.plughelper.plist

│ │ com.apple.appstore.PluginHelper

│ │ com.apple.MailServiceAgentHelper

│ │ com.apple.MailServiceAgentHelper.plist

│ │ com.apple.periodic-dd-mm-yy.plist

│ │ com.apple.systemkeychain-helper.plist

│ │ periodicdate

│ │ stty5.11.pl

│ │ systemkeychain-helper

│ │

│ └───manpath.d

│ libcrypto.1.0.0.dylib

│ libiconv.2.dylib

│ libimobiledevice.4.dylib

│ libiodb.dylib

│ liblzma.5.dylib

│ libplist.2.dylib

│ libssl.1.0.0.dylib

│ libusbmuxd.2.dylib

│ libxml2.2.dylib

│ libz.1.dylib

│ libzip.2.dylib

│

├───iOS

│ sfbase.dylib

│ sfbase_v4000.dylib

│ sfbase_v4001.dylib

│ start

│ stty5.11.pl

│

├───IPAs

│ 7b9e685e89b8c7e11f554b05cdd6819a

│ pphelper

│

├───original

│ BikeBaron

│ CleanApp

│ FontMap1.cfg

│ start.sh

│

└───update

start.sh

update

Forms. PDF forms allow user input in a predefined mask, such as a text field, a radio button, or a selection box. Facilities, such as the administration, usually use forms to create PDF documents with predefined areas which are intended to be filled out by users. The user input is, however, limited to the defined form fields and cannot change other content within the PDF.

Annotations. Annotations introduce a different method for a user input by allowing a user to put remarks in a PDF document like text highlighting, strikeouts, or sticky notes. Annotations are not limited to predefined places within the PDF and can be applied everywhere within the document.

Incremental Update

An Incremental Update introduces a possibility to extend a PDF by appending new information at the end of the file, see Inc. Update 1 in the figure above. In this way, the original document stays unmodified and a revision history of all document changes is kept. Each Incremental Update defines new objects, a new xref table, and a new trailer. An example of an Incremental Update is the inclusion of an certification, signature, annotation, or the filling out forms within a PDF.

User Interface (UI) Layers

The UI in many PDF viewing applications can be divided into three layers that are important for the verification of the certification.

UI-Layer 1: Top Bar Validation Status. UI-Layer 1 is usually displayed immediately after opening. Typical applications use a clearly visible bar on top of the PDF content. The status of the certification and signatures validation is provided as a text (e.g., valid/invalid), often combined with green, blue or red background colors, cf. figures in EAA and SSA sections.

UI-Layer 2: Detailed Validation and Information. UI-Layer 2 provides detailed information about the certification and the signatures applied to the PDF. It can be implemented by the viewer in numerous ways, but viewers typically do not show this information automatically once the PDF file is opened. Instead, it must be opened manually by clicking a certain button. For example, this button can be placed on the topbar (UI-Layer 1). Some viewers use sidebars which provide detailed information regarding the certified document, other use popup windows.

UI-Layer 3: PDF Annotations. UI-Layer 3 is another UI element that shows all PDF annotations. Typically, a sidebar is used for this purpose. This layer is of particular importance for certified documents, since for some documents, adding and changing PDF annotations is allowed. Without this layer, some annotations (e.g., text blocks) would be indistinguishable from regular PDF text content.

Difference between Signed and Certified Documents

Signed Documents
By signing a PDF document, a Signature object is created. This object contains the trusted public keys to verify the document, the signature value, the range of bytes that are protected by the signature, and a userfriendly information regarding the signer of the document. The Signature object is usually added to the PDF document by using an Incremental Update.

Certified Documents

Certifications have two main differences to signatures. First, each PDF can have only one certification and must be the first in the document. Second, certifications define permissions that allow certain changes to the certified document. As depicted in the table above, certifications define a more flexible way to handle Incremental Updates, and allowed Incremental Update do not lead to a warning. The certifier chooses between three different permission levels (P) to allow different modifications.

P1: No modifications on the document are allowed.

P2: Filling out forms, digitally signing the document are allowed, and instantiate page templates.
P3: In addition to P2, annotations are also allowed.

The allowed modifications are defined within the DocMDP Transformation parameter contained in the certification object. With respect to the integrity protection of the PDF, the PDF application must execute the following steps. First, it must verify if an Incremental Update was applied after the PDF was certified. Second, it must verify if the defined changes are legitimate according to the given permissions.

Evil Annotation Attack (EAA)

The idea of the Evil Annotation Attack (EAA) is to show arbitrary content in a certified document by abusing annotations for this purpose. Since P3 certified document allow to add annotations, EAA breaks the integrity of the certification.

Evaluating Permission P3. According to the specification, the following changes in a certified document with P3 are allowed: 1) adding/removing/modifying annotations, 2) fillingout forms, 3) and signing the document. We started with an in-depth analysis of all annotations and their features. We evaluated 28 different annotations and classified these with respect to their capabilities and danger level. The results are depicted in the Table on the right side and will be further explained.

Danger Level of Annotations. We determined three annotations with a danger level high capable to hide and add text and images: FreeText, Redact, and Stamp. All three can be used to stealthily modify a certified document and inject malicious content. In addition, 11 out of 28 annotations are classified as medium since an attacker can hide content within the certified document. The danger level of the remaining annotations is classified as low or none since such annotations are either quite limited or not allowed in certified documents.

Attacking with Annotations. According to our attacker model, the attacker possesses a validly certified document allowing the insertion of annotations. To execute the attack, the attacker modifies a certified document by including the annotation with the malicious content at a position of attacker's choice. Then, the attacker sends the modified file to the victim who verifies the digital signature. The victim could detect the attack if it manually opens UI-Layer 3 or clicks on the annotation. However, none of the tested PDF applications opened UI-Layer 3 automatically. Additionally, the attacker can lock an annotation to disable clicking on it.

Improving the stealthiness of EAA

To improve the attack, we elaborated techniques to prevent the annotation's visualization, so that it does not appear in UI-Layer 3. Surprisingly, we found a generic and simple bypass that can be applied to all annotations. PDF viewers identify annotations by their specified /Subtype. This /Subtype is also used by the viewer to assign the various editing tools, such as a text editor for FreeText comments. If the value of /Subtype is either missing or set to an unspecified value, whereby both cases are not prohibited according to the specification, the PDF viewer is unable to assign the annotation. As depicted in the figure below, the annotation is not listed in UI-Layer 3. In summary, the annotation is indistinguishable from the original content.

Special Modifications

For some annotations, such as FreeText or Stamp, the editing tools of appropriate PDF applications can be easily used to completely design the visible content of a certified document. This is not the case for other annotations, which are classified as suitable for hiding text and images. The Underline annotation, for example, only creates a small line below the selected text. For hiding the text that is located below this line, the PDF object must be manually edited. By using a text editor, the thickness of the line can be adjusted within the annotation's appearance (parameter: /N) to hide the whole text. It is also possible to define the coordinates of an annotation to hide a particular area on a page. A special feature among the annotations is Redact. It allows new text to be placed over existing text. If the user moves the mouse over the text, the new text is displayed and hides the original text. To display this new text permanently, it is sufficient to redirect the object number (parameter: /N) to the object with the new text. Summarized, the specification does not restrict the size, color or characteristics of annotations and offers arbitrary possibilities to change the displayed content.

Sneaky Signature Attack (SSA)

The idea of the Sneaky Signature Attack (SSA) is to manipulate the appearance of arbitrary content within the PDF by adding overlaying signature elements to a PDF document that is certified at level P2.

Evaluating Permission P2. According to the specification, the following changes in a certified document with P2 are allowed: filling-out forms, and signing the document. We started the analysis of forms as depicted in the table on the right side and evaluated their capabilities.

Danger Level of Forms. According to our analysis, the danger level was none because the insertion of new form elements, customizing the font size and appearance, and removing form elements is prohibited. The only permitted change is on the value stored in the field. Thus, an attacker is not able to create forms which hide arbitrary content within the PDF document. Surprisingly, these restrictions are not valid for the signature field. By inserting a signature field, the signer can define the exact position of the field, and additionally its appearance and content. This flexibility is necessary since each new signature could contain the signer's information. The information can be a graphic, a text, or a combination of both. Nevertheless, the attacker can misuse the flexibility to stealthy manipulate the document and insert new content.

Attacking with Forms: SSA. The attacker modifies a certified document by including a signature field with the malicious content at a position of attacker's choice. The attacker then needs to sign the document, but he does not need to possess a trusted key. A self-signed certificate for SSA is sufficient. The only restriction is that the attacker needs to sign the document to insert the malicious signature field. This signing information can be seen by opening the PDF document and showing detailed information of the signature validation. In this case, the victim opening the file can get suspicious and refuse to accept the document, even though the certification is valid.

Improving the stealthiness of SSA

To circumvent this limitation, we found a bypass to hide this information in UI-Layer 2. Thus, the victim is not able to determine the attacker's manipulations (see the figure on the left side). Basically, we have three tasks to improve the attack execution: 1) hide the signature information in the signature panel on UI-Layer 2 , 2) skip the validation of attacker's signature, and 3) make the signature field read-only to make it indistinguishable from the text content. To solve all tasks, we need to adjust one object – the one responsible for the appearance of the signature. It contains three relevant parameters: /P, /V, and /Ff. The /P is a reference to the page where signature should be displayed. We found out that if this reference is not valid, the signature disappears from the signature panel on UI-Layer 2, but the malicious content is still shown on the page. A signature added to a PDF document is usually verified by processing its referenced signature data. If the stored cryptographic values are correct and the document is not manipulated within the signed area, the signature is technically valid. The /V parameter references the signature value which needs to be validated. We found out that if this reference is also invalid, the signature validation is skipped. Finally, we set the parameter /Ff to 1 which means that the content is read-only. If a certified document is opened in a common PDF application, signatures can only be added to free signature fields provided by the certifier. Adding empty signature fields is normally no longer possible within the application. However, the specification does not prohibit adding empty signature fields to a certified document. By using frameworks like Apache PDFBox, empty signature fields can be placed anywhere in the document and filled with arbitrary content.

Evaluation

We evaluated all 26 PDF applications on each of the three UI-Layers against EAA and SSA attacks. We used two different types of exploits for this purpose: 1) exploits that are compliant to the PDF specification and 2) exploits that improved the stealthiness of the attacks by abusing implementation flaws, for example, by parsing errors. We have evaluated the latest (at the time of evaluation) available versions of the applications on all supported desktop platforms: Windows, macOS, and Linux. The results are depicted in the table below.

Authors of this Post

Simon Rohlmann
Vladislav Mladenov
Christian Mainka
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 articles