Exploitation

Exploitation: Techniques To Gain A Foothold: Stack-based Buffer Overflows, Stacks On Stacks, Crossing The Line, Protecting Against Stack-based Buffer Overflows. SQL Injection: Protecting Against SQL Injection, Conclusion. Malicious PDF Files: PDF File Format, Creating Malicious PDF Files, Reducing The Risks Of Malicious PDF File.

​

1 2 6 10 14 16 20 37 38 39 41 45 46 54 56 53 60 61 62

58 l2 22 33 35 26 18 9 48 52

​

61 ccc 16,18

Techniques To Gain A Foothold

Shellcode

​

Shellcode is binary code used as the payload in the exploitation of software vulnerabilities. The name shellcode originates from its initial intentions to spawn a shell within another process but has since evolved to define code that performs any custom tasks within another process.

​

Written in the assembly language, the shellcode passed through an assembler creates the binary machine code that the central processing unit (CPU) can execute. When an attacker exploits a vulnerability in a specific process, the shellcode payload is executed seamlessly, acting as if it were part of the original program

​

To perform a system call, the shellcode issues an interrupt (INT 0x80) with a syscall number to specify which function to perform. 

​

​

Stack-Based Buffer Overflows

overflows are the result of a finite-sized buffer receiving data that are larger than the allocated space. Stack-based buffer overflows are by far the most common type of overflow, as they are generally the easiest to exploit.

​

Stacks upon Stacks

standard computer stack consists of an array of memory bytes that a programmer can access 

randomly or through a series of pop-and-push commands.�

​

​

​

The Intel x86 processor uses two special registers for stack management: the stack pointer (ESP) and the base pointer (EBP). The processor uses the stack pointer to specify the memory address of the last memory pushed onto the stack and the location to use when popping the next datum from the stack. While the size of the datum can be a byte, a word, a 32-bit DWORD, or a 64-bit QWORD value (for 64-bit processors), the most common convention is a DWORD stack access, since pointers and integers are typically 32 bits in size.

2 3 5 6 8 9 10 11 12 13 14 15 16 18 20

22 23 24 26 27 28 29 31 34 36 38 40

41 42 44 45 46 47 48 49 50 51 52 53 56 57 58 59 61 62 63 64 65 66 l1 2 3 4 6 7 8 37

Stack-Based Buffer Overflows

overflows are the result of a finite-sized buffer receiving data that are larger than the allocated space. Stack-based buffer overflows are by far the most common type of overflow, as they are generally the easiest to exploit.

​

Stacks upon Stacks

standard computer stack consists of an array of memory bytes that a programmer can access 

randomly or through a series of pop-and-push commands.�

​

​

​

The Intel x86 processor uses two special registers for stack management: the stack pointer (ESP) and the base pointer (EBP). The processor uses the stack pointer to specify the memory address of the last memory pushed onto the stack and the location to use when popping the next datum from the stack. While the size of the datum can be a byte, a word, a 32-bit DWORD, or a 64-bit QWORD value (for 64-bit processors), the most common convention is a DWORD stack access, since pointers and integers are typically 32 bits in size.

2 3 5 6 8 9 10 11 12 13 14 15 16 18 20

22 23 24 26 27 28 29 31 34 36 38 40

41 42 44 45 46 47 48 49 50 51 52 53 56 57 58 59 61 62 63 64 65 66 l1 2 3 4 6 7 8 37

Controlling the return address is only one part of a successful stack-based buffer overflow

If attackers can get processors to execute malicious code somewhere within the NOP sled, those processors will not jump into the middle of valid instructions that can cause the flow of execution to deviate drastically from the attackers’ original intents. The actual malicious code follows the NOP sleds.

shell code, attackers construct the data sent to the vulnerable buffer such that the first portion of the data contains what attackers call a no-operation-performed (NOP) sled, which is an array of NOP instructions. This portion of the shellcode is optional, but allows attackers to miss their marks when effecting code execution. 

1 2 3 4 5 7 9 10 12 14 15 16 17 18 20

22 23 24 25 26 27 28 29 31 32 36 38 40 41

42 45 46 47 49 52 53 54 56 57 58 61 63 64 66 l2 4 5 6 7

The called function normally uses the base pointer to point to the original stack pointer location immediately after the function begins. Known as setting up a stack frame, the function uses the EBP to provide a fixed reference point by which it accesses the stack variables.

​

The EBP becomes critical when using the stack frame, as the ESP floats with each push-and-pop off the stack from subsequent function calls (from the perspective of the original called function). After the function assigns the EBP and the value of ESP immediately after the function begins, the function will adjust ESP to accommodate the necessary memory space for local variables used by the function. This movement of the ESP will place the pointer at the end of the local variable data

​

Once the calling function has completed, the function resets the stack pointer to the original location, as specified by the base pointer. The processor, upon seeing the “return” instruction that terminates the function, pops the return address from the stack, as pointed to by the ESP. The processor uses this address as the location of the next instruction to execute.

​

Crossing the Line

• Stack-based buffer overflows occur when a function passes more data to a stack variable than the variable can hold.
• The objective in writing stack-based buffer overflows is to control the flow of code execution and execute potentially malicious code by adding more data than a variable can hold.
• attack works is by finding a buffer on the stack that is close enough to the return address and attempting to place enough data in the buffer such that the attacker can overwrite the return address

​

​

​

​

​

​

​

Protecting against Stack-Based Buffer Overflows

• the root cause of any stack-based buffer overflow is the lack of bounds checking when accepting input. 
• Buffers allocated on a stack are of finite, predetermined sizes, and as such, it is up to the programmer to ensure that the function copying data into them is within this size constraint.
• Generally, a program should validate any data taken from an external source (external from the perspective of the application) for both size and content; user-supplied data should never be trusted outright.
• Compilers, such as Microsoft’s Visual C++ 2005 and 2008, use a technique known as stack cookies to ensure that overflowed variables in a stack do not result in a processor using an invalid return address.
• The technique consists of placing a randomized 32-bit value immediately before the return address on the stack. Before the function terminates, it compares the value on the stack to the original value from the start of the function. If the two values do not match, the program terminates due to a security violation.
•  the responsibility of the programmer is  to write secure code to prevent stack-based buffer overflows.

​

​

SQL Injection

which result from failing to validate user inputs.

• Attackers often use search engines to identify vulnerable sites, and then use SQL injection to alter the content of the site to include malicious IFrames, or otherwise download malicious code to Web surfers who visit the compromised sites.

​

• SQL injection is fundamentally an input validation error. These vulnerabilities occur when an application that interacts with a database passes data to an SQL query in an unsafe manner. The impact of a successful SQL injection attack can include sensitive data leakage, website defacement, or the destruction of the entire database.

​

SELECT text FROM blog_entries;

SELECT text,user,timestamp FROM blog_entries WHERE user = ‘user1’;

#Get Username

username = getInputFromUser()

#Create SQL Query containing username

sql_query = “SELECT text,user,timestamp FROM blog_entries where user = ‘“ +username + “‘;”#Execute complete query

database.execute(sql_query);

x’; SELECT uname,pwd FROM users; --

The single quote ends the data string, and the semi-colon tells the database to execute the query so far. This probably will not return any information unless there is a user named x. The data-base will then process the rest of the query, which selects the columns “uname” and “pwd” from the table named “users.” This query will return a list of all usernames and passwords in the database. Finally, the string terminates with “--”, which declares the rest of the line as a comment that will not be executed. This SQL injection attack forces the database to return sensitive information (usernames and passwords) rather than the expected blog data.

Protecting against SQL Injection

first method, programmers can try to ensure that the data do not include any special characters such as single quotation marks that might cause the database to treat data as code.

​

The second method involves the use of parameterized queries. Parameterized queries allow the programmer to define a query and pass data into it without performing dangerous string concatenation.

#Get Username

username = getInputFromUser()

#Create the Parameterized Query using the %s format string.

sql_query = “SELECT text,user,timestamp FROM blog_entries where user = %s;”

#Execute the parameterized query, specifying the data separately

database.execute(sql_query, (username));

​

With parameterized queries, the database is aware of what is code and what is data and can avoid SQL injection based on that knowledge.When organizations lack the ability or resources to audit and test for SQL injection vulnerabilities in their Web applications, a Web Application Firewall (WAF) may be an alternate solution. ModSecurity is an open source WAF that can act as a reverse proxy, sitting between a Web server and the Internet to filter incoming requests for SQL injection and other types of attacks A list of commercial and open source WAFs is available from the Open Web Application Security Project (OWASP)

​

https://en.wikipedia.org/wiki/Web_application_firewall

https://owasp.org/www-community/Web_Application_Firewall

​

​

first method, programmers can try to ensure that the data do not include any special characters such as single quotation marks that might cause the database to treat data as code.

​

The second method involves the use of parameterized queries. Parameterized queries allow the programmer to define a query and pass data into it without performing dangerous string concatenation.

Malicious PDF Files

• The PDF file format is risky because many users have vulnerable PDF viewers installed that attackers can exploit to install malicious code.
• Multiple previously unknown or unpatched PDF vulnerabilities have allowed attackers to launch targeted attacks against high-priority victims as of 2009.
• Web browsers load PDF files automatically, so a malicious PDF file can exploit a user’s computer without any interaction once the user visits a malicious website

​

• Attackers commonly use JavaScript because the instructions can allocate large blocks of memory (heap spraying), which allows an attacker to reliably jump to certain addresses upon gaining control of execution through a vulnerability. Attackers also rely on JavaScript to hide the intent of their code because they can use eval() or similar functions to dynamically execute statements when the JavaScript code runs.

https://linuxsecurityblog.com/2018/11/12/payload-in-pdf/

https://www.adlice.com/infected-pdf-extract-payload/

​

Each object has attribute tags that describe its purpose. The obj, endobj, stream, and endstream tags correspond with the beginning and end of each section, and each attribute starts with “/”. The cross-reference (xref) table contains entries corresponding to the file offset for each object. One common attribute for data in PDF files is the / FlateDecode attribute, which the viewer decompresses with the zlib library;

To instruct the PDF viewer to execute the JavaScript code upon opening the file, the author must also assign an action to the object similar to one of the following examples:

<</Type/Action/S/JavaScript/JS 14 0 R >>

<</OpenAction <</JS (this.wBx9J6Zzf7\(\))

/S /JavaScript

​

The Action attribute specifies that the PDF reader should execute the JavaScript code in object 14. The /OpenAction attribute can call the JavaScript function wBx9J6Zzf7(), which the PDF file defines in a different object.

1 2 6 8 9 12 13 15 17 19 21 22 23

25 26 27 28 30 35 37 38 39 40 41

46 47 48 49 50 52 54 53 51 59 60

61 62 63 64 66

Le 1 2 5 6

The PDF file format also allows incremental changes without modifying the original file. For each modification, the application appends a changes section, xref section, and trailer section. As a result, a PDF file may grow large if the author repeatedly updates it.

​

​

The Adobe JavaScript engine exposes several PDF-specific objects, including app, doc, dbg, console, global, util, dialog, security, SOAP, search, ADBC, and event objects.21 It also exposes some online

collaboration commands for review, markup, and approval. These exposed objects are often the areas of vulnerability that attackers have exploited in the past.

Creating Malicious PDF Files

All of these vulnerabilities commonly use JavaScript exploits to execute arbitrary code. Exactly how attackers build these malicious PDF files is unknown

The origami framework can modify an existing PDF file by injecting custom JavaScript code that executes when users open the PDF file. PDF tools like make-pdf, pdf-parse, and pdf-id are also available and have similar functionality