Yangquan or Bust

Jennifer

This file is an 32bits elf binary, compiled from go language (i guess ... coded by @nibble_ds ;)

The binary has some debugging symbols, which is very helpful to locate the functions and api calls.

GO source functions:

- main.main

- main.function.001

If the binary is executed with no params, it prints "Nope!", the bad guy message.

~/ncn$ ./inbincible

Nope!

Decompiling the main.main function I saw two things:

1. The Argument validation: Only one 16 bytes long argument is needed, otherwise the execution is finished.

2. The key IF, the decision to dexor and print byte by byte the "Nope!" string OR dexor and print "Yeah!"

The incoming channel will determine the final message.

Dexor and print each byte of the "Nope!" message.

This IF, checks 16 times if the go channel reception value is 0x01, in this case the app show the "Yeah!" message.

Go channels are a kind of thread-safe queue, a channel_send is like a push, and channel_receive is like a pop.

If we fake this IF the 16 times, we got the "Yeah!" message:

(gdb) b *0x8049118
(gdb) commands
>set {char *}0xf7edeef3 = 0x01
>c
>end

(gdb) r 1234567890123456
tarting program: /home/sha0/ncn/inbincible 1234567890123456
...
Yeah!

Ok, but the problem is not in main.main, is main.function.001 who must sent the 0x01 via channel.

This function xors byte by byte the input "1234567890123456" with a byte array xor key, and is compared with another byte array.

=> 0x8049456: xor %ebp,%ecx

This xor, encode the argument with a key byte by byte

The xor key can be dumped from memory but I prefer to use this macro:

(gdb) b *0x8049456
(gdb) commands
>i r ecx
>c
>end
(gdb) c

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x12 18

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x45 69

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x33 51

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x87 135

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x65 101

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x12 18

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x45 69

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x33 51

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x87 135

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x65 101

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x12 18

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x45 69

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x33 51

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x87 135

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x65 101

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x12 18

The result of the xor will compared with another array byte, each byte matched, a 0x01 will be sent.

The cmp of the xored argument byte,
will determine if the channel send 0 or 1

(gdb) b *0x0804946a
(gdb) commands
>i r al
>c
>end

At this point we have the byte array used to xor the argument, and the byte array to be compared with, if we provide an input that xored with the first byte array gets the second byte array, the code will send 0x01 by the channel the 16 times.

Now web have:

xorKey=[0x12,0x45,0x33,0x87,0x65,0x12,0x45,0x33,0x87,0x65,0x12,0x45,0x33,0x87,0x65,0x12]

mustGive=[0x55,0x75,0x44,0xb6,0x0b,0x33,0x06,0x03,0xe9,0x02,0x60,0x71,0x47,0xb2,0x44,0x33]

Xor is reversible, then we can get the input needed to dexor to the expected values in order to send 0x1 bytes through the go channel.

>>> x=''
>>> for i in range(len(xorKey)):
... x+= chr(xorKey[i] ^ mustGive[i])
...
>>> print x

G0w1n!C0ngr4t5!!

And that's the key :) let's try it:

~/ncn$ ./inbincible 'G0w1n!C0ngr4t5!!'
Yeah!

Got it!! thanx @nibble_ds for this funny crackme, programmed in the great go language. I'm also a golang lover.

Related word

Jennifer

In 2019, we published attacks on PDF Signatures and PDF Encryption. During our research and studying the related work, we discovered a lot of blog posts, talks, and papers focusing on malicious PDFs causing some damage. However, there was no systematic analysis of all possible dangerous features supported by PDFs, but only isolated exploits and attack concepts.

We decided to fill this gap and systematize the possibilities to use legitimate PDF features and do bad stuff. We define four attack categories: Denial of Service, Information Disclosure, Data Manipulation, and Code Execution.

Our evaluation reveals 26 of 28 popular PDF processing applications are vulnerable to at least one attack. You can download all malicious PDFs here. You can also find more technical details in our NDSS'21 paper.

This is a joined work of Jens Müller, Dominik Noss, Christian Mainka, Vladislav Mladenov, and Jörg Schwenk.

Dangerous Paths: Overview

To identify attack vectors, we systematically surveyed which potentially dangerous features exist in the PDF specification. We created a comprehensive list with all PDF Actions that can be called. This list contains 18 different actions that we carefully studied.

We selected eight actions – the ones that directly or indirectly allow access to a file handle and may therefore be abused for dangerous features such as URL invocation or writing to files. Having a list of security-sensitive actions, we proceeded by investigating all objects and related events that can trigger these actions.

We identified four PDF objects which allow calling arbitrary actions (Page, Annotation, Field, and Catalog). Most objects offer multiple alternatives for this purpose. For example, the Catalog object, defines the OpenAction or additional actions (AA) events. Each event can launch any sequence of PDF actions, for example, Launch, Thread, etc. JavaScript actions can be embedded within documents. It opens a new area for attacks, for example, new annotations can be created that can have actions which once again lead to accessing file handles.

Denial of Service

The goal of the denial of service class of attacks is enforcing to process PDF applications in consuming all available resources (i.e., computing time or memory) or causes them to crash by opening a specially crafted PDF document. We identified two variants: Infinite Loop and Deflate Bomb.

Infinite Loop

This variant induces an endless loop causing the program execution to get stuck. The PDF standard allows various elements of the document structure to reference to themselves, or to other elements of the same type.

Action loop: PDF actions allow to specify a Next action to be performed, thereby resulting in "action cycles".

ObjStm loop: Object streams may extend other object streams allows the crafting of a document with cycles.

Outline loop: PDF documents may contain an outline. Its entries, however, can refer to themselves or each other.

Calculations: PDF defines "Type 4" calculator functions, for example, to transform colors. Processing hard-to-solve mathematical formulas may lead to high demands of CPU.

JavaScript: Finally, in case the PDF application processes scripts within documents, infinite loops can be induced.

Deflate Bomb

Data amplification attacks based on malicious zip archives are well-known. The first publicly documented DoS attack using a "zip bomb" was conducted in 1996 against a Fidonet BBS administrator. However, not only zip files but also stream objects within PDF documents can be compressed using various algorithms such as Deflate to reduce the overall file size.

Information Disclosure

The goal of this class of attacks is to track the usage of a document by silently invoking a connection to the attacker's server once the file is opened, or to leak PDF document form data, local files, or NTLM credentials to the attacker.

URL Invocation

PDF documents that silently "phone home" should be considered as privacy-invasive. They can be used, for example, to deanonymize reviewers, journalists, or activists behind a shared mailbox. The attack's goal is to open a backchannel to an attacker-controlled server once the PDF file is opened by the victim.

The possibility of malicious URI resolving in PDF documents has been introduced by Hamon [1] who gave an evaluation for URI and SubmitForm actions in Acrobat Reader. We extend their analysis to all standard PDF features that allow opening a URL, such as ImportData, Launch, GoToR, and JavaScript.

Form Data Leakage

Documents can contain forms to be filled out by the user – a feature introduced with PDF version 1.2 in 1996 and used on a daily basis for routine offices tasks, such as travel authorization or vacation requests. The idea of this attack is as follows: The victim downloads a form – a PDF document which contains form fields – from an attacker controlled source and fills it out on the screen, for example, in order to print it. The form is manipulated by the attacker in such a way that it silently send input data to the attacker's server.

Local File Leakage

The PDF standard defines various methods to embed external files into a document or otherwise access files on the host's file system, as documented below.

External streams: Documents can contain stream objects (e.g., images) to be included from external files on disk.
Reference XObjects: This feature allows a document to import content from another (external) PDF document.
Open Prepress Interface: Before printing a document, local files can be defined as low-resolution placeholders.
Forms Data Format (FDF): Interactive form data can be stored in, and auto-imported from, external FDF files.
JavaScript functions: The Adobe JavaScript reference enables documents to read data from or import local files.

If a malicious document managed to firstly read files from the victim's disk and secondly, send them back to the attacker, such behavior would arguably be critical.

Credential Theft

In 1997, Aaron Spangler posted a vulnerability in Windows NT on the Bugtraq mailing list [2]: Any client program can trigger a connection to a rogue SMB server. If the server requests authentication, Windows will automatically try to log in with a hash of the user's credentials. Such captured NTLM hashes allow for efficient offline cracking and can be re-used by applying pass-the-hash or relay attacks to authenticate under the user's identity. In April 2018, Check Point Research [3] showed that similar attacks can be performed with malicious PDF files. They found that the target of GoToR and GoToE actions can be set to \\attacker.com\dummyfile, thereby leaking credentials in the form of NTLM hashes.

Data Manipulation

This attack class deals with the capabilities of malicious documents to silently modify form data, to write to local files on the host's file system, or to show a different content based on the application that is used to open the document.

Form Modification

The idea of this attack is as follows: Similar to Form Data Leakage attacks, the victim obtains a harmlessly looking PDF document from an attacker controlled source, for example, a remittance slip or a tax form. The goal of the attacker is to dynamically, and without knowledge of the victim, manipulate form field data.

File Write Access

The PDF standard enables documents to submit form data to external webservers. Technically the webserver's URL is defined using a PDF File Specification. This ambiguity in the standard may be interpreted by implementations in such a way that they enable documents to submit PDF form data to a local file, thereby writing to this file.

Content Masking

The goal of this attack is to craft a document that renders differently, depending on the applied PDF interpreter. This can be used, for example, to show different content to different reviewers, to trick content filters (AI-based machines as well as human content moderators), plagiarism detection software, or search engines, which index a different text than the one shown to users when opening the document.

Stream confusion: It is unclear how content streams are parsed if their Length value does not match the offset of the endstream marker, or if syntax errors are introduced.
Object confusion: An object can overlay another object. The second object may not be processed if it has a duplicate object number, if it is not listed in the XRef table, or if other structural syntax errors are introduced.
Document confusion: A PDF file can contain yet another document (e.g., as embedded file), multiple XRef tables, etc., which results in ambiguities on the structural level.
PDF confusion: Objects before the PDF header or after an EOF marker may be processed by implementations, introducing ambiguities in the outer document structure.

Code Execution

The goal of this attack is to execute attacker-controlled code. This can be achieved by silently launching an executable file, embedded within the document, to infect the host with malware. The PDF specification defines the Launch action, which allows documents to launch arbitrary applications. The file to be launched can either be specified by a local path, a network share, a URL, or a file embedded within the PDF document itself.

Evaluation

Out of 28 tested applications, 26 are vulnerable to at least one attack.

Authors of this Post

Jens Müller

Dominik Noss
Christian Mainka

Vladislav Mladenov

Jörg Schwenk

Sources

1] V. Hamon. "Malicious URI resolving in PDF documents". In: Journal of Computer Virology and Hacking Techniques 9.2 (2013), pp. 65–76.

[2] Aaron Spangler. WinNT/Win95 Automatic Authentication Vulnerability (IE Bug #4). https://insecure.org/sploits/winnt.automatic.authentication.html. Mar. 1997.

[3] Check Point Research. NTLM Credentials Theft via PDF Files. https://research.checkpoint.com/ntlm-credentials-theft-via-pdf-files/. 2018.

Continue reading

Jennifer

Download Now

The Live HTML Editor program lets you write your HTML pages while viewing dynamically what changes are happening to your HTML page. The main purpose of this tool is to help HTML learners learn HTML quickly and easily while keeping an eye on what they are doing with their HTML page. It also helps developers in writing quick HTML lines to see how it will affect their HTML page.

This program can also help you visualize your inline and embedded CSS styles on fly. You can apply CSS styles and see them dynamically change the look and feel of your HTML page. Developers can test different inline and embedded CSS styles to make sure what will look good on their website.

Some of the features of this program are:

Live HTML preview of whatever HTML you type.
Supports HTML Syntax Highlighting.
Supports opening an HTML file and Live Preview editing of that file.
Supports Saving files.
Support for inline and embedded CSS.

However this program does not support Javascript and it also doesn't support separate CSS files. This program is still in development phase and we might see support for Javascript and separate CSS files in the future.

If you are a student and want to learn HTML without having to install a bulky software that takes a lot of time to open and function, then this is a good option.

The Live HTML Editor is Free and Opensource project and has been written in Python with QT interface you can check out source from sourceforge.

Related posts