Abdullah Abdulwaheed’s Post

Lab 5 Completed on File Path Traversal: Validate Start of Path ✅ Another intriguing lab completed! This time, I bypassed a flawed validation mechanism intended to enforce safe file paths. Here's a breakdown of how I solved it: 1️⃣ Analyzed Input Validation: Tested various inputs and noticed the server only validated the start of the file path. 2️⃣ Identified the Weakness: Realized the application was not validating the entire file path but only the initial prefix. 3️⃣ Crafted a Payload: Used a traversal sequence such as /safe-folder/../../etc/passwd to navigate out of the restricted directory and access sensitive files. 4️⃣ Verified Exploitation: Successfully retrieved the /etc/passwd file, proving the server’s validation mechanism was inadequate. 5️⃣ Completed the Challenge: Extracted the required data to complete the lab. This lab emphasized the importance of properly validating file paths, including their entirety, to prevent directory traversal attacks. A great reminder to implement robust server-side input handling mechanisms!

Lab 3 Completed on File Path Traversal: Non-Recursive Sequence Stripping ✅ I just completed another challenging lab, this time tackling file path traversal with non-recursive sequence stripping. Here's how I successfully exploited the vulnerability: 1️⃣ Investigated the server's behavior by sending payloads like ../ and observing how the application stripped traversal sequences. 2️⃣ Noticed that the server removed traversal patterns but did so non-recursively, leaving opportunities for exploitation. 3️⃣ Constructed a payload using repeated traversal sequences like ....//, bypassing the server's defense mechanism. 4️⃣ Successfully accessed the sensitive /etc/passwd file, confirming the flaw in the sanitization logic. 5️⃣ Extracted the required information to complete the lab. This exercise demonstrated how improper sequence handling can still leave systems vulnerable to traversal attacks. It’s a reminder that security defenses must account for all potential edge cases in input sanitization!

Lab 2 Completed on File Path Traversal: Absolute Path Bypass ✅ Just finished another interesting lab on file path traversal, where I learned how to bypass path traversal defenses using absolute file paths. Here’s a summary of my approach: 1️⃣ Analyzed the application to understand its file processing mechanism and locate potential vulnerabilities. 2️⃣ Tested standard traversal payloads like ../, but they were blocked by input sanitization. 3️⃣ Shifted focus to absolute paths, bypassing restrictions by directly specifying /etc/passwd. 4️⃣ Successfully retrieved the sensitive passwd file, confirming that the server's input validation was inadequate. 5️⃣ Extracted the required data and completed the challenge. This lab highlighted how partial defenses, like blocking relative paths, can still leave applications vulnerable. Proper input validation and restricting file access to a safe directory are critical!

Lab 6 Completed on File Path Traversal: Null Byte Bypass ✅ Just completed another fascinating lab! This time, I bypassed a flawed file extension validation mechanism using a null byte injection. Here's a breakdown of my approach: 1️⃣ Analyzed File Extension Validation: Observed that the server restricted file uploads or access to specific extensions like .png or .jpg. 2️⃣ Identified the Weakness: Found that the application only checked the file extension at the end of the input, without properly sanitizing the entire path. 3️⃣ Exploited with Null Byte Injection: Appended a null byte (%00) after a malicious payload, such as /etc/passwd%00.png, to bypass the file extension check. 4️⃣ Verified Exploitation: Successfully retrieved the sensitive /etc/passwd file, confirming the vulnerability. 5️⃣ Completed the Challenge: Extracted the required data to complete the lab. This lab underscored the dangers of incomplete input validation, especially when relying solely on file extensions for security. A key takeaway is to implement stricter checks at the server level, ensuring all inputs are sanitized and validated comprehensively!

🎯 Lab Challenge: File Path Traversal with Superfluous URL-Decode This week, I explored a critical vulnerability through the PortSwigger Web Security Academy lab: File path traversal with traversal sequences stripped via superfluous URL-decoding. URL encoding, the ../ characters. This results in %2e%2e%2f and %252e%252e%252f respectively For Burp Suite Professional users, Burp Intruder provides the predefined payload list Fuzzing - path traversal. This contains some encoded path traversal sequences that you can try. GET /image?filename=..%252f..%252f..%252fetc/passwd HTTP/2

The module shared nice tips, especially on performing XXE attacks through SVG images and bypassing whitelisting/blacklisting for file extensions and content types. A good dive into practical File upload exploitation techniques and their implications. #HTB_Academy #File_Upload_Attacks

In this lab I learn how to bypass a whitelist-based input filter I learn how to gather information from the server error massages and understand where it block me and how go another way . also I learn that sometimes when you try to use "http://username#@example.com" it will read the first part(http://username#) as the url insted the real url "Example.com" for that not to happen you need to encode the '#' and see the respond if it still not work encode it again.In the end it was a fun lab to do

⛑️ Format String Bug in fgfmd https://lnkd.in/e-JtnHMQ

Lnk files used to gain persistence via VS Code. https://lnkd.in/gmf3k_eb

Systemd v256 is going to release with a new feature called run0 which trying to be a replacement of sudo due to Systemd developer believes the security risk is quite high in anything with setuid. @hackerfantastic wrote an oldsk00l PoC to demonstrate the new fancy feature run0 only make the LPE (local privilege escalationhe) easier ("Goodbye, Hardware mitigatherion!"). The funny part is run0 utilized polkit which is another malware/exploit writer's favorable component. Well, the problem is any proposed solution from systemd always ends up badly as shooting the user's own foot. Just reminder of that the chaotic dependency of systemd-notify just make xz/lzma backdoor target OpenSSH easily and that was just disclosured not a long ago. Systemd v256 is set to release with a new feature called run0, which aims to replace sudo. The Systemd developers believe that anything to do with setuid poses a high security risk which is not true. However, @hackerfantastic has written a neat 0lskool proof-of-concept (PoC) demonstrating that the new feature run0 actually makes local privilege escalation (LPE) easier ("Goodbye, Hardware mitigatherion!") by hijacking the pty between run0 and systemd-run. Please noted that run0 utilizes polkit, a component favored by malware/exploit writers. Any proposed solution from systemd always ends up badly as shooting the user's own foot. Just reminder of that the chaotic dependency of systemd-notify just make xz/lzma backdoor target OpenSSH easily and that was just disclosured not a long ago. Good news is it's not hard to take hardening measures for the future systemd. Just dwarf the executable binary as baseline! https://lnkd.in/gfriAh8W https://lnkd.in/gV-x869c https://lnkd.in/gJQ4CgTZ