References audit: 50 pages

src/network-services-pentesting/pentesting-web/wsgi.md

@@ -18,7 +18,7 @@ werkzeug.md
 
 ## uWSGI Magic Variables Exploitation
 
-uWSGI provides special "magic variables" that can change how the instance loads and dispatches applications. These variables are not normal HTTP headers — they are uwsgi parameters carried inside the uwsgi/SCGI/FastCGI request from the reverse proxy (nginx, Apache mod_proxy_uwsgi, etc.) to the uWSGI backend. If a proxy configuration maps user-controlled data into uwsgi parameters (for example via `$arg_*`, `$http_*`, or unsafely exposed endpoints that talk the uwsgi protocol), attackers can set these variables and achieve code execution.<sup>[[1]](#references)</sup>
+uWSGI provides special "magic variables" that can change how the instance loads and dispatches applications. These variables are not normal HTTP headers — they are uwsgi parameters carried inside the uwsgi/SCGI/FastCGI request from the reverse proxy (nginx, Apache mod_proxy_uwsgi, etc.) to the uWSGI backend. If a proxy configuration maps user-controlled data into uwsgi parameters (for example via `$arg_*`, `$http_*`, or unsafely exposed endpoints that talk the uwsgi protocol), attackers can set these variables and achieve code execution.<sup>[[1]](#references)[[3]](#references)</sup>
 
 ### Dangerous mappings in front proxies (nginx example)
 
@@ -195,7 +195,7 @@ os.environ['UWSGI_CHEAPER'] = '1'
 
 Deployments that use Apache httpd with `mod_proxy_uwsgi` have faced recent response-splitting/desynchronization bugs that can influence the frontend↔backend translation layer:
 
-- CVE-2023-27522 (Apache httpd 2.4.30–2.4.55; also relevant to uWSGI integration prior to 2.0.22/2.0.26 fixes): crafted origin response headers can cause HTTP response smuggling when `mod_proxy_uwsgi` is in use. Upgrading Apache to ≥2.4.56 mitigates the issue.
+- CVE-2023-27522 (Apache httpd 2.4.30–2.4.55; also relevant to uWSGI integration prior to 2.0.22/2.0.26 fixes): crafted origin response headers can cause HTTP response smuggling when `mod_proxy_uwsgi` is in use. Upgrading Apache to ≥2.4.56 mitigates the issue.<sup>[[6]](#references)</sup>
 - CVE-2024-24795 (fixed in Apache httpd 2.4.59; uWSGI 2.0.26 adjusted its Apache integration): HTTP response splitting in multiple httpd modules could lead to desync when backends inject headers. In uWSGI’s 2.0.26 changelog this appears as “let httpd handle CL/TE for non-http handlers.”<sup>[[5]](#references)</sup>
 
 These do not directly grant RCE in uWSGI, but in edge cases they can be chained with header injection or SSRF to pivot towards the uwsgi backend. During tests, fingerprint the proxy and version and consider desync/smuggling primitives as an entry to backend-only routes and sockets.
@@ -207,5 +207,6 @@ These do not directly grant RCE in uWSGI, but in edge cases they can be chained
 - [3] [uWSGI Security Best Practices](https://uwsgi-docs.readthedocs.io/en/latest/Security.html)
 - [4] [The uwsgi Protocol (spec)](https://uwsgi-docs.readthedocs.io/en/latest/Protocol.html)
 - [5] [uWSGI 2.0.26 changelog mentioning CVE-2024-24795 adjustments](https://uwsgi-docs.readthedocs.io/en/latest/Changelog-2.0.26.html)
+- [6] [CVE-2023-27522 — Apache HTTP Server mod_proxy_uwsgi HTTP Response Smuggling](https://nvd.nist.gov/vuln/detail/CVE-2023-27522)
 
 {{#include ../../banners/hacktricks-training.md}}

src/network-services-pentesting/pentesting-web/zabbix.md

@@ -20,7 +20,7 @@ Recent Zabbix versions compute the cookie like:
 - sign: HMAC-SHA256(key=session_key, data=JSON string of data sorted by keys and compact separators)
 - Final cookie: Base64(JSON_with_sign)
 
-If you can recover the global session_key and a valid admin sessionid, you can forge a valid Admin cookie offline and authenticate to the UI.
+If you can recover the global session_key and a valid admin sessionid, you can forge a valid Admin cookie offline and authenticate to the UI.<sup>[[1]](#references)</sup>
 
 ## CVE-2024-22120 — Time-based blind SQLi in Zabbix Server audit log
 

src/network-services-pentesting/pentesting-web/zoneminder-motioneye-motion.md

@@ -15,7 +15,7 @@ After host access, the most interesting files are commonly:
 
 - **`/etc/motioneye/motioneye.conf`**
 - **`/etc/motioneye/*.conf`**
-- ZoneMinder web sources / config revealing the DB name, tables, and auth model
+- ZoneMinder web sources / config revealing the DB name, tables, and auth model<sup>[[1]](#references)</sup>
 
 ## ZoneMinder
 
@@ -35,7 +35,7 @@ In vulnerable ZoneMinder **`1.37.* <= 1.37.64`**, the **`tid`** parameter in:
 /zm/index.php?view=request&request=event&action=removetag&tid=1
 ```
 
-can reach code that safely uses **`$_REQUEST['tid']`** in one query and then later concatenates it into:
+can reach code that safely uses **`$_REQUEST['tid']`** in one query and then later concatenates it into:<sup>[[1]](#references)</sup>
 
 ```php
 $sql = "SELECT * FROM Events_Tags WHERE TagId = $tagId";
@@ -132,7 +132,7 @@ This is useful when the UI blocks characters such as **`$`**, but the backend st
 
 In vulnerable motionEye / Motion setups, fields such as **`image_file_name`** or **`picture_filename`** are written into Motion configuration and later propagated into shell-executed hooks such as **`on_picture_save ... %f`**.<sup>[[1]](#references)</sup>
 
-If the saved filename contains shell substitution like **`$(...)`**, the shell expands it before the hook runs.
+If the saved filename contains shell substitution like **`$(...)`**, the shell expands it before the hook runs.<sup>[[1]](#references)</sup>
 
 Probe payloads:
 
@@ -146,7 +146,7 @@ If the Motion process or hook executes as **root**, this becomes **root RCE**.
 
 ### Unauthenticated localhost Motion webcontrol
 
-If Motion webcontrol is reachable and unauthenticated, test it directly:
+If Motion webcontrol is reachable and unauthenticated, test it directly:<sup>[[1]](#references)</sup>
 
 ```bash
 curl -s http://127.0.0.1:7999/
@@ -170,7 +170,7 @@ Why this works:
 
 ### Stored SHA1 hash accepted as a login secret
 
-If you can read **`@admin_password`** from motionEye config, do not assume you must crack it first.
+If you can read **`@admin_password`** from motionEye config, do not assume you must crack it first.<sup>[[1]](#references)</sup>
 
 Some motionEye builds store:
 

src/pentesting-web/2fa-bypass.md

@@ -6,31 +6,31 @@
 
 ### **Direct Endpoint Access**
 
-To bypass 2FA, access the subsequent endpoint directly, knowing the path is crucial. If unsuccessful, alter the **Referrer header** to mimic navigation from the 2FA verification page.
+To bypass 2FA, access the subsequent endpoint directly, knowing the path is crucial. If unsuccessful, alter the **Referrer header** to mimic navigation from the 2FA verification page.<sup>[[2]](#references)</sup>
 
 ### **Token Reuse**
 
-Reutilizing previously used tokens for authentication within an account can be effective.
+Reutilizing previously used tokens for authentication within an account can be effective.<sup>[[2]](#references)</sup>
 
 ### **Utilization of Unused Tokens**
 
-Extracting a token from one's own account to bypass 2FA in another account can be attempted.
+Extracting a token from one's own account to bypass 2FA in another account can be attempted.<sup>[[2]](#references)</sup>
 
 ### **Exposure of Token**
 
-Investigate whether the token is disclosed in a response from the web application.
+Investigate whether the token is disclosed in a response from the web application.<sup>[[2]](#references)</sup>
 
 ### **Verification Link Exploitation**
 
-Using the **email verification link sent upon account creation** can allow profile access without 2FA, as highlighted in a detailed [post](https://srahulceh.medium.com/behind-the-scenes-of-a-security-bug-the-perils-of-2fa-cookie-generation-496d9519771b).<sup>[[4]](#references)</sup>
+Using the **email verification link sent upon account creation** can allow profile access without 2FA, as highlighted in a detailed [post](https://srahulceh.medium.com/behind-the-scenes-of-a-security-bug-the-perils-of-2fa-cookie-generation-496d9519771b).<sup>[[3]](#references)</sup>
 
 ### **Session Manipulation**
 
 Initiating sessions for both the user's and a victim's account, and completing 2FA for the user's account without proceeding, allows an attempt to access the next step in the victim's account flow, exploiting backend session management limitations.
 
 ### **Password Reset Mechanism**
 
-Investigating the password reset function, which logs a user into the application post-reset, for its potential to allow multiple resets using the same link is crucial. Logging in with the newly reset credentials might bypass 2FA.
+Investigating the password reset function, which logs a user into the application post-reset, for its potential to allow multiple resets using the same link is crucial. Logging in with the newly reset credentials might bypass 2FA.<sup>[[2]](#references)</sup>
 
 ### **OAuth Platform Compromise**
 
@@ -40,51 +40,51 @@ Compromising a user's account on a trusted **OAuth** platform (e.g., Google, Fac
 
 #### **Rate Limit Absence**
 
-The lack of a limit on the number of code attempts allows for brute force attacks, though potential silent rate limiting should be considered.
+The lack of a limit on the number of code attempts allows for brute force attacks, though potential silent rate limiting should be considered.<sup>[[1]](#references)[[2]](#references)</sup>
 
-Note that even if a rate limit is in place you should try to see if the response is different when the valid OTP is sent. In [**this post**](https://mokhansec.medium.com/the-2-200-ato-most-bug-hunters-overlooked-by-closing-intruder-too-soon-505f21d56732), the bug hunter discovered that even if a rate limit is triggered after 20 unsuccessful attempts by responding with 401, if the valid one was sent a 200 response was received.<sup>[[5]](#references)</sup>
+Note that even if a rate limit is in place you should try to see if the response is different when the valid OTP is sent. In [**this post**](https://mokhansec.medium.com/the-2-200-ato-most-bug-hunters-overlooked-by-closing-intruder-too-soon-505f21d56732), the bug hunter discovered that even if a rate limit is triggered after 20 unsuccessful attempts by responding with 401, if the valid one was sent a 200 response was received.<sup>[[4]](#references)</sup>
 
 #### **Slow Brute Force**
 
-A slow brute force attack is viable where flow rate limits exist without an overarching rate limit.
+A slow brute force attack is viable where flow rate limits exist without an overarching rate limit.<sup>[[1]](#references)</sup>
 
 #### **Code Resend Limit Reset**
 
-Resending the code resets the rate limit, facilitating continued brute force attempts.
+Resending the code resets the rate limit, facilitating continued brute force attempts.<sup>[[1]](#references)</sup>
 
 #### **Client-Side Rate Limit Circumvention**
 
 A document details techniques for bypassing client-side rate limiting.
 
 #### **Internal Actions Lack Rate Limit**
 
-Rate limits may protect login attempts but not internal account actions.
+Rate limits may protect login attempts but not internal account actions.<sup>[[1]](#references)</sup>
 
 #### **SMS Code Resend Costs**
 
 Excessive resending of codes via SMS incurs costs to the company, though it does not bypass 2FA.
 
 #### **Infinite OTP Regeneration**
 
-Endless OTP generation with simple codes allows brute force by retrying a small set of codes.
+Endless OTP generation with simple codes allows brute force by retrying a small set of codes.<sup>[[1]](#references)</sup>
 
 ### **Race Condition Exploitation**
 
 Exploiting race conditions for 2FA bypass can be found in a specific document.
 
 ### **CSRF/Clickjacking Vulnerabilities**
 
-Exploring CSRF or Clickjacking vulnerabilities to disable 2FA is a viable strategy.
+Exploring CSRF or Clickjacking vulnerabilities to disable 2FA is a viable strategy.<sup>[[1]](#references)[[2]](#references)</sup>
 
 ### **"Remember Me" Feature Exploits**
 
 #### **Predictable Cookie Values**
 
-Guessing the "remember me" cookie value can bypass restrictions.
+Guessing the "remember me" cookie value can bypass restrictions.<sup>[[1]](#references)</sup>
 
 #### **IP Address Impersonation**
 
-Impersonating the victim's IP address through the **X-Forwarded-For** header can bypass restrictions.
+Impersonating the victim's IP address through the **X-Forwarded-For** header can bypass restrictions.<sup>[[1]](#references)</sup>
 
 ### **Utilizing Older Versions**
 
@@ -94,23 +94,23 @@ Testing subdomains may use outdated versions lacking 2FA support or contain vuln
 
 #### **API Endpoints**
 
-Older API versions, indicated by /v\*/ directory paths, may be vulnerable to 2FA bypass methods.
+Older API versions, indicated by /v\*/ directory paths, may be vulnerable to 2FA bypass methods.<sup>[[1]](#references)</sup>
 
 ### **Handling of Previous Sessions**
 
-Terminating existing sessions upon 2FA activation secures accounts against unauthorized access from compromised sessions.
+Terminating existing sessions upon 2FA activation secures accounts against unauthorized access from compromised sessions.<sup>[[1]](#references)</sup>
 
 ### **Access Control Flaws with Backup Codes**
 
-Immediate generation and potential unauthorized retrieval of backup codes upon 2FA activation, especially with CORS misconfigurations/XSS vulnerabilities, poses a risk.
+Immediate generation and potential unauthorized retrieval of backup codes upon 2FA activation, especially with CORS misconfigurations/XSS vulnerabilities, poses a risk.<sup>[[1]](#references)[[2]](#references)</sup>
 
 ### **Information Disclosure on 2FA Page**
 
-Sensitive information disclosure (e.g., phone number) on the 2FA verification page is a concern.
+Sensitive information disclosure (e.g., phone number) on the 2FA verification page is a concern.<sup>[[1]](#references)</sup>
 
 ### **Password Reset Disabling 2FA**
 
-A process demonstrating a potential bypass method involves account creation, 2FA activation, password reset, and subsequent login without the 2FA requirement.
+A process demonstrating a potential bypass method involves account creation, 2FA activation, password reset, and subsequent login without the 2FA requirement.<sup>[[2]](#references)</sup>
 
 ### **Decoy Requests**
 
@@ -122,15 +122,10 @@ In case the OTP is created based on data the user already has or that is sending
 
 ## References
 
-- [1] [Two-Factor Authentication Security Testing and Possible Bypasses](https://medium.com/@ISecMax/two-factor-authentication-security-testing-and-possible-bypasses-f65650412b35)
+- [1] [Two-Factor Authentication: Security Testing and Possible Bypasses](https://medium.com/@ISecMax/two-factor-authentication-security-testing-and-possible-bypasses-f65650412b35)
 - [2] [2 Factor Authentication Bypass](https://azwi.medium.com/2-factor-authentication-bypass-3b2bbd907718)
-- [3] [https://getpocket.com/read/aM7dap2bTo21bg6fRDAV2c5thng5T48b3f0Pd1geW2u186eafibdXj7aA78Ip116_1d0f6ce59992222b0812b7cab19a4bce](https://getpocket.com/read/aM7dap2bTo21bg6fRDAV2c5thng5T48b3f0Pd1geW2u186eafibdXj7aA78Ip116_1d0f6ce59992222b0812b7cab19a4bce)
-- [4] [Behind the Scenes of a Security Bug: The Perils of 2FA Cookie Generation](https://srahulceh.medium.com/behind-the-scenes-of-a-security-bug-the-perils-of-2fa-cookie-generation-496d9519771b)
-- [5] [The $2,200 ATO Most Bug Hunters Overlooked by Closing Intruder Too Soon](https://mokhansec.medium.com/the-2-200-ato-most-bug-hunters-overlooked-by-closing-intruder-too-soon-505f21d56732)
-
-P
+- [3] [Behind the Scenes of a Security Bug: The Perils of 2FA Cookie Generation](https://srahulceh.medium.com/behind-the-scenes-of-a-security-bug-the-perils-of-2fa-cookie-generation-496d9519771b)
+- [4] [The $2,200 ATO Most Bug Hunters Overlooked by Closing Intruder Too Soon](https://mokhansec.medium.com/the-2-200-ato-most-bug-hunters-overlooked-by-closing-intruder-too-soon-505f21d56732)
+- [5] [https://getpocket.com/read/aM7dap2bTo21bg6fRDAV2c5thng5T48b3f0Pd1geW2u186eafibdXj7aA78Ip116_1d0f6ce59992222b0812b7cab19a4bce](https://getpocket.com/read/aM7dap2bTo21bg6fRDAV2c5thng5T48b3f0Pd1geW2u186eafibdXj7aA78Ip116_1d0f6ce59992222b0812b7cab19a4bce)
 
 {{#include ../banners/hacktricks-training.md}}
-
-
-