Merge branch 'master' into update_MS-RPC_Fuzzer_20250715_182932

Author: carlospolop

searchindex.js

@@ -28,6 +28,7 @@
   - [Enable Nexmon Monitor And Injection On Android](generic-methodologies-and-resources/pentesting-wifi/enable-nexmon-monitor-and-injection-on-android.md)
   - [Evil Twin EAP-TLS](generic-methodologies-and-resources/pentesting-wifi/evil-twin-eap-tls.md)
 - [Phishing Methodology](generic-methodologies-and-resources/phishing-methodology/README.md)
+  - [Clipboard Hijacking](generic-methodologies-and-resources/phishing-methodology/clipboard-hijacking.md)
   - [Clone a Website](generic-methodologies-and-resources/phishing-methodology/clone-a-website.md)
   - [Detecting Phishing](generic-methodologies-and-resources/phishing-methodology/detecting-phising.md)
   - [Discord Invite Hijacking](generic-methodologies-and-resources/phishing-methodology/discord-invite-hijacking.md)
@@ -76,6 +77,7 @@
 # 🧙‍♂️ Generic Hacking
 
 - [Brute Force - CheatSheet](generic-hacking/brute-force.md)
+- [Esim Javacard Exploitation](generic-hacking/esim-javacard-exploitation.md)
 - [Exfiltration](generic-hacking/exfiltration.md)
 - [Reverse Shells (Linux, Windows, MSFVenom)](generic-hacking/reverse-shells/README.md)
   - [MSFVenom - CheatSheet](generic-hacking/reverse-shells/msfvenom.md)

src/SUMMARY.md

@@ -4,35 +4,106 @@
 
 ## Relro
 
-**RELRO** stands for **Relocation Read-Only**, and it's a security feature used in binaries to mitigate the risks associated with **GOT (Global Offset Table)** overwrites. There are two types of **RELRO** protections: (1) **Partial RELRO** and (2) **Full RELRO**. Both of them reorder the **GOT** and **BSS** from ELF files, but with different results and implications. Speciifically, they place the **GOT** section _before_ the **BSS**. That is, **GOT** is at lower addresses than **BSS**, hence making it impossible to overwrite **GOT** entries by overflowing variables in the **BSS** (rembember writing into memory happens from lower toward higher addresses).
+**RELRO** stands for **Relocation Read-Only** and it is a mitigation implemented by the linker (`ld`) that turns a subset of the ELF’s data segments **read-only after all relocations have been applied**.  The goal is to stop an attacker from overwriting entries in the **GOT (Global Offset Table)** or other relocation-related tables that are dereferenced during program execution (e.g. `__fini_array`).
 
-Let's break down the concept into its two distinct types for clarity.
+Modern linkers implement RELRO by **re–ordering** the **GOT** (and a few other sections) so they live **before** the **.bss** and – most importantly – by creating a dedicated `PT_GNU_RELRO` segment that is remapped `R–X` right after the dynamic loader finishes applying relocations.  Consequently, typical buffer overflows in the **.bss** can no longer reach the GOT and arbitrary‐write primitives cannot be used to overwrite function pointers that sit inside a RELRO-protected page.
 
-### **Partial RELRO**
+There are **two levels** of protection that the linker can emit:
 
-**Partial RELRO** takes a simpler approach to enhance security without significantly impacting the binary's performance. Partial RELRO makes **the .got read only (the non-PLT part of the GOT section)**. Bear in mind that the rest of the section (like the .got.plt) is still writeable and, therefore, subject to attacks. This **doesn't prevent the GOT** to be abused **from arbitrary write** vulnerabilities.
+### Partial RELRO
 
-Note: By default, GCC compiles binaries with Partial RELRO.
+* Produced with the flag `-Wl,-z,relro` (or just `-z relro` when invoking `ld` directly).
+* Only the **non-PLT** part of the **GOT** (the part used for data relocations) is put into the read-only segment.  Sections that need to be modified at run-time – most importantly **.got.plt** which supports **lazy binding** – remain writable.
+* Because of that, an **arbitrary write** primitive can still redirect execution flow by overwriting a PLT entry (or by performing **ret2dlresolve**).
+* The performance impact is negligible and therefore **almost every distribution has been shipping packages with at least Partial RELRO for years (it is the GCC/Binutils default as of 2016)**.
 
-### **Full RELRO**
+### Full RELRO
 
-**Full RELRO** steps up the protection by **making the entire GOT (both .got and .got.plt) and .fini_array** section completely **read-only.** Once the binary starts all the function addresses are resolved and loaded in the GOT, then, GOT is marked as read-only, effectively preventing any modifications to it during runtime.
+* Produced with **both** flags `-Wl,-z,relro,-z,now` (a.k.a. `-z relro -z now`).  `-z now` forces the dynamic loader to resolve **all** symbols up-front (eager binding) so that **.got.plt** never needs to be written again and can safely be mapped read-only.
+* The entire **GOT**, **.got.plt**, **.fini_array**, **.init_array**, **.preinit_array** and a few additional internal glibc tables end up inside a read-only `PT_GNU_RELRO` segment.
+* Adds measurable start-up overhead (all dynamic relocations are processed at launch) but **no run-time overhead**.
 
-However, the trade-off with Full RELRO is in terms of performance and startup time. Because it needs to resolve all dynamic symbols at startup before marking the GOT as read-only, **binaries with Full RELRO enabled may experience longer load times**. This additional startup overhead is why Full RELRO is not enabled by default in all binaries.
+Since 2023 several mainstream distributions have switched to compiling the **system tool-chain** (and most packages) with **Full RELRO by default** – e.g. **Debian 12 “bookworm” (dpkg-buildflags 13.0.0)** and **Fedora 35+**.  As a pentester you should therefore expect to encounter binaries where **every GOT entry is read-only**.
 
-It's possible to see if Full RELRO is **enabled** in a binary with:
+---
+
+## How to Check the RELRO status of a binary
 
 ```bash
-readelf -l /proc/ID_PROC/exe | grep BIND_NOW
+$ checksec --file ./vuln
+[*] '/tmp/vuln'
+    Arch:     amd64-64-little
+    RELRO:    Full
+    Stack:    Canary found
+    NX:       NX enabled
+    PIE:      No PIE (0x400000)
 ```
 
-## Bypass
+`checksec` (part of [pwntools](https://github.com/pwncollege/pwntools) and many distributions) parses `ELF` headers and prints the protection level.  If you cannot use `checksec`, rely on `readelf`:
 
-If Full RELRO is enabled, the only way to bypass it is to find another way that doesn't need to write in the GOT table to get arbitrary execution.
+```bash
+# Partial RELRO → PT_GNU_RELRO is present but BIND_NOW is *absent*
+$ readelf -l ./vuln | grep -E "GNU_RELRO|BIND_NOW"
+    GNU_RELRO      0x0000000000600e20 0x0000000000600e20
+```
 
-Note that **LIBC's GOT is usually Partial RELRO**, so it can be modified with an arbitrary write. More information in [Targetting libc GOT entries](https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md#1---targetting-libc-got-entries)**.**
+```bash
+# Full RELRO → PT_GNU_RELRO *and* the DF_BIND_NOW flag
+$ readelf -d ./vuln | grep BIND_NOW
+ 0x0000000000000010 (FLAGS)              FLAGS: BIND_NOW
+```
 
-{{#include ../../banners/hacktricks-training.md}}
+If the binary is running (e.g. a set-uid root helper), you can still inspect the executable **via `/proc/$PID/exe`**:
+
+```bash
+readelf -l /proc/$(pgrep helper)/exe | grep GNU_RELRO
+```
+
+---
+
+## Enabling RELRO when compiling your own code
+
+```bash
+# GCC example – create a PIE with Full RELRO and other common hardenings
+$ gcc -fPIE -pie -z relro -z now -Wl,--as-needed -D_FORTIFY_SOURCE=2 main.c -o secure
+```
 
+`-z relro -z now` works for both **GCC/clang** (passed after `-Wl,`) and **ld** directly.  When using **CMake 3.18+** you can request Full RELRO with the built-in preset:
 
+```cmake
+set(CMAKE_INTERPROCEDURAL_OPTIMIZATION ON) # LTO
+set(CMAKE_ENABLE_EXPORTS OFF)
+set(CMAKE_BUILD_RPATH_USE_ORIGIN ON)
+set(CMAKE_EXE_LINKER_FLAGS "-Wl,-z,relro,-z,now")
+```
+
+---
+
+## Bypass Techniques
+
+| RELRO level | Typical primitive | Possible exploitation techniques |
+|-------------|-------------------|----------------------------------|
+| None / Partial | Arbitrary write | 1. Overwrite **.got.plt** entry and pivot execution.<br>2. **ret2dlresolve** – craft fake `Elf64_Rela` & `Elf64_Sym` in a writable segment and call `_dl_runtime_resolve`.<br>3. Overwrite function pointers in **.fini_array** / **atexit()** list. |
+| Full | GOT is read-only | 1. Look for **other writable code pointers** (C++ vtables, `__malloc_hook` < glibc 2.34, `__free_hook`, callbacks in custom `.data` sections, JIT pages).<br>2. Abuse *relative read* primitives to leak libc and perform **SROP/ROP into libc**.<br>3. Inject a rogue shared object via **DT_RPATH**/`LD_PRELOAD` (if environment is attacker-controlled) or **`ld_audit`**.<br>4. Exploit **format-string** or partial pointer overwrite to divert control-flow without touching the GOT. |
+
+> 💡 Even with Full RELRO the **GOT of loaded shared libraries (e.g. libc itself)** is **only Partial RELRO** because those objects are already mapped when the loader applies relocations.  If you gain an **arbitrary write** primitive that can target another shared object’s pages you can still pivot execution by overwriting libc’s GOT entries or the `__rtld_global` stack, a technique regularly exploited in modern CTF challenges.
+
+### Real-world bypass example (2024 CTF – *pwn.college “enlightened”*)
+
+The challenge shipped with Full RELRO.  The exploit used an **off-by-one** to corrupt the size of a heap chunk, leaked libc with `tcache poisoning`, and finally overwrote `__free_hook` (outside of the RELRO segment) with a one-gadget to get code execution.  No GOT write was required.
 
+---
+
+## Recent research & vulnerabilities (2022-2025)
+
+* **glibc 2.40 de-precates `__malloc_hook` / `__free_hook` (2025)** – Most modern heap exploits that abused these symbols must now pivot to alternative vectors such as **`rtld_global._dl_load_jump`** or C++ exception tables.  Because hooks live **outside** of RELRO their removal increases the difficulty of Full-RELRO bypasses.
+* **Binutils 2.41 “max-page-size” fix (2024)** – A bug allowed the last few bytes of the RELRO segment to share a page with writable data on some ARM64 builds, leaving a tiny **RELRO gap** that could be written after `mprotect`.  Upstream now aligns `PT_GNU_RELRO` to page boundaries, eliminating that edge-case.
+
+---
+
+## References
+
+* Binutils documentation – *`-z relro`, `-z now` and `PT_GNU_RELRO`*  
+* *“RELRO – Full, Partial and Bypass Techniques”* – blog post @ wolfslittlered 2023
+
+{{#include ../../banners/hacktricks-training.md}}

src/binary-exploitation/common-binary-protections-and-bypasses/relro.md

@@ -0,0 +1,89 @@
+# eSIM / Java Card VM Exploitation
+
+{{#include ../banners/hacktricks-training.md}}
+
+## Overview
+Embedded SIMs (eSIMs) are implemented as **Embedded UICC (eUICC)** smart-cards that run a **Java Card Virtual Machine (JC VM)** on top of a secure element.  
+Because profiles and applets can be provisioned *over-the-air* (OTA) via Remote SIM Provisioning (RSP), any memory-safety flaw inside the JC VM instantly becomes a remote code-execution primitive **inside the most privileged component of the handset**.
+
+This page describes a real-world full compromise of Kigen’s eUICC (Infineon SLC37 ESA1M2, ARM SC300) caused by missing type-safety checks in the `getfield` and `putfield` bytecodes.  The same technique can be re-used against other vendors that omit on-card byte-code verification.
+
+## Attack Surface
+1. **Remote Application Management (RAM)**  
+   eSIM profiles may embed arbitrary Java Card applets.  Provisioning is performed with standard APDUs that can be tunnelled through SMS-PP (Short Message Service Point-to-Point) or HTTPS.  If an attacker owns (or steals) the **RAM keys** for a profile, they can `INSTALL`/`LOAD` a malicious applet remotely.
+2. **Java Card byte-code execution**  
+   After installation, the applet executes inside the VM.  Missing run-time checks allow memory corruption.
+
+## The Type-Confusion Primitive
+`getfield` / `putfield` are supposed to operate only on **object references**.  In Kigen eUICC the instructions never validate whether the operand on the stack is an *object* or an *array* reference.  Because an `array.length` word lives at the exact same offset as the first instance field of a normal object, an attacker can:
+
+1. Create a byte-array `byte[] buf = new byte[0x100];`
+2. Cast it to `Object o = (Object)buf;`
+3. Use `putfield` to overwrite *any* 16-bit value inside an adjacent object (including VTABLE / ptr translation entries).  
+4. Use `getfield` to read *arbitrary* memory once internal pointers are hijacked.
+
+```java
+// Pseudo-bytecode sequence executed by the malicious applet
+// buf = newarray byte 0x100
+// o   = (Object) buf            // illegal but not verified
+// putfield <victimObject+offset>, 0xCAFE // arbitrary write
+// ... set up read-what-where gadgets ...
+```
+The primitive provides **arbitrary read / write** in the eUICC address space – enough to dump the device-unique ECC private key that authenticates the card to the GSMA ecosystem.
+
+## End-to-End Exploitation Workflow
+1. **Enumerate firmware** – Use undocumented `GET DATA` item `DF1F`:
+   ```
+   80 CA DF 1F 00   // → "ECu10.13" (vulnerable)
+   ```
+2. **Install malicious applet OTA** – Abuse publicly-known keys of the TS.48 Generic Test Profile and push SMS-PP fragments that transport the CAP file (`LOAD`) followed by an `INSTALL`:
+   ```
+   // simplified APDU chain
+   80 E6 02 00 <data>   // LOAD (block n)
+   80 E6 0C 00 <data>   // INSTALL for load
+   ```
+3. **Trigger type-confusion** – When the applet is selected it performs the write-what-where to hijack a pointer table and leak memory through normal APDU responses.
+4. **Extract GSMA certificate key** – Private EC key is copied to the applet’s RAM and returned in chunks.
+5. **Impersonate the eUICC** – The stolen key pair + certificates let the attacker authenticate to *any* RSP server as a legitimate card (EID binding may still be required for some operators).
+6. **Download and modify profiles** – Plaintext profiles contain highly sensitive fields such as `OPc`, `AMF`, OTA keys and even additional applets.  The attacker can:
+   * Clone a profile to a second eUICC (voice/SMS hijack);
+   * Patch Java Card applications (e.g. insert STK spyware) before re-uploading;
+   * Extract operator secrets for large-scale abuse.
+
+## Cloning / Hijacking Demonstration
+Installing the same profile on **PHONE A** and **PHONE B** results in the Mobile Switching Centre routing incoming traffic to whichever device most recently registered.  One session of Gmail 2FA SMS interception is enough to bypass MFA for the victim.
+
+## Automated Test & Exploit Toolkit
+The researchers released an internal tool with a `bsc` (*Basic Security Check*) command that immediately shows whether a Java Card VM is vulnerable:
+```
+scard> bsc
+- castcheck        [arbitrary int/obj casts]
+- ptrgranularity   [pointer granularity/tr table presence]
+- locvaraccess     [local variable access]
+- stkframeaccess   [stack frame access]
+- instfieldaccess  [instance field access]
+- objarrconfusion  [object/array size field confusion]
+```
+Modules shipped with the framework:
+* `introspector` – full VM and memory explorer (~1.7 MB Java)
+* `security-test` – generic verification bypass applet (~150 KB)
+* `exploit`       – 100 % reliable Kigen eUICC compromise (~72 KB)
+
+## Mitigations
+1. **On-card byte-code verification** – enforce full control-flow & data-flow type tracking instead of stack-top only.
+2. **Hide array header** – place `length` outside of overlapping object fields.
+3. **Harden RAM keys policy** – never ship profiles with public keys; disable `INSTALL` in test profiles (addressed in GSMA TS.48 v7).
+4. **RSP server side heuristics** – rate-limit profile downloads per EID, monitor geographic anomalies, validate certificate freshness.
+
+## Quick Checklist for Pentesters
+* Query `GET DATA DF1F` – vulnerable firmware string `ECu10.13` indicates Kigen.
+* Check if RAM keys are known ‑> attempt OTA `INSTALL`/`LOAD`.
+* After applet installation, brute-force simple cast primitive (`objarrconfusion`).
+* Try to read Security Domain private keys – success = full compromise.
+
+## References
+- [Security Explorations – eSIM security](https://security-explorations.com/esim-security.html)
+- [GSMA TS.48 Generic Test Profile v7.0](https://www.gsma.com/get-involved/working-groups/gsma_resources/ts-48-v7-0-generic-euicc-test-profile-for-device-testing/)
+- [Java Card VM Specification 3.1](https://docs.oracle.com/en/java/javacard/3.1/jc-vm-spec/F12650_05.pdf)
+
+{{#include ../banners/hacktricks-training.md}}

src/generic-hacking/esim-javacard-exploitation.md

@@ -458,6 +458,14 @@ You can **buy a ___domain with a very similar name** to the victims ___domain **and/or
 
 Use [**Phishious** ](https://github.com/Rices/Phishious)to evaluate if your email is going to end in the spam folder or if it's going to be blocked or successful.
 
+## Clipboard Hijacking / Pastejacking
+
+Attackers can silently copy malicious commands into the victim’s clipboard from a compromised or typosquatted web page and then trick the user to paste them inside **Win + R**, **Win + X** or a terminal window, executing arbitrary code without any download or attachment.
+
+{{#ref}}
+clipboard-hijacking.md
+{{#endref}}
+
 ## References
 
 - [https://zeltser.com/___domain-name-variations-in-phishing/](https://zeltser.com/___domain-name-variations-in-phishing/)