Overview
Description
Statistics
- 1 Post
Fediverse
đ¨ CVE-2025-67289 (CRITICAL): Frappe Framework v15.89.0 affected by arbitrary file upload flawâunauthenticated attackers can gain code execution via malicious XML files. Restrict uploads & monitor activity ASAP. https://radar.offseq.com/threat/cve-2025-67289-na-46d41f94 #OffSeq #Frappe #Vuln #Cybersecurity
Overview
Description
Statistics
- 1 Post
Fediverse
[Security Advisory] CVE-2025-14269: Credential caching in Headlamp with Helm enabled #devopsish https://groups.google.com/a/kubernetes.io/g/dev/c/5XH9BGiefH0/m/bGd9hkofCgAJ?utm_medium=email&utm_source=footer
Overview
Description
Statistics
- 1 Post
Overview
- Microsoft
- Windows Server 2025 (Server Core installation)
Description
Statistics
- 1 Post
Bluesky
Overview
Description
Statistics
- 1 Post
Overview
Description
Statistics
- 1 Post
Fediverse
â ď¸ CVE-2025-65856 (CRITICAL): Auth bypass in Xiongmai XM530 IP cameras (Firmware V5.00.R02.000807D8.10010.346624.S.ONVIF 21.06) exposes live streams to unauth attackers. Disable ONVIF, restrict access, monitor for fixes. https://radar.offseq.com/threat/cve-2025-65856-na-11fd2d6e #OffSeq #IoTSecurity #Vuln
Overview
Description
Statistics
- 1 Post
Overview
Description
Statistics
- 1 Post
- 1 Interaction
Overview
- Fortinet
- FortiClientWindows
Description
Statistics
- 1 Post
Fediverse
HackerHood di RHC scopre una privilege escalation in FortiClient VPN
Lâanalisi che segue esamina il vettore di attacco relativo alla CVE-2025-47761, una vulnerabilitĂ individuata nel driver kernel Fortips_74.sys utilizzato da FortiClient VPN per Windows. Il cuore della problematica risiede in una IOCTL mal gestita che permette a processi user-mode non privilegiati di interagire con il kernel, abilitando una primitiva di scrittura arbitraria di 4 byte.
La falla è stata individuata il 31 gennaio 2025 da Alex Ghiotto, membro della community di Hackerhood. Sebbene la patch correttiva sia stata integrata già a settembre 2025 con il rilascio della versione 7.4.4,
Fortinet ha formalizzato la vulnerabilitĂ solo il 18 novembre 2025 con la pubblicazione del bollettino ufficiale FG-IR-25-112.
Questo caso studio risulta particolarmente interessante per valutare lâefficacia delle moderne mitigazioni di sistema: lâexploit si basa infatti sul reperimento dellâindirizzo kernel del token di processo, unâoperazione resa complessa a partire da Windows 11 24H2. In questâultima versione, lâaccesso a tali informazioni tramite NtQuerySystemInformation richiede ora il privilegio SeDebugPrivilege, innalzando significativamente i requisiti necessari per un attacco efficace da parte di utenti non amministratori.
Analisi Tecnica della CVE-2025-47761
Fortips_74.sys è un driver kernel utilizzato da alcune soluzioni Fortinet, tra cui FortiClientVPN. Nel corso dellâanalisi del driver è emersa una vulnerabilitĂ successivamente identificata e corretta come CVEâ2025â47761. Lâobiettivo di questo articolo è descrivere il processo di analisi che ha portato alla sua individuazione e comprenderne le principali implicazioni di sicurezza. La vulnerabilitĂ consente una scrittura arbitraria di 4 byte in un indirizzo controllato dallâutente. Questo comportamento può causare un crash del sistema oppure essere sfruttato per ottenere una completa escalation dei privilegi.
Interagire col Driver
Quando si analizza un driver alla ricerca di una potenziale escalation dei privilegi, la prima domanda fondamentale è: chi può interagirci?
Se anche utenti non privilegiati possono aprire un handle, allora vale la pena approfondire.
In questo caso, il primo passo è osservare chi può interagire con Fortips_74.sys.
Usando WinObj, si nota immediatamente che il driver non imposta permessi restrittivi: questo attira subito lâattenzione.
Una vista piÚ tecnica delle DACL è possibile dal kernel tramite WinDBG
Il driver Fortips_74 crea infatti un device kernel senza definire DACL personalizzate, affidandosi al security descriptor di default. In pratica, qualunque processo nel sistema può aprire un handle verso il driver, compresi quelli a basso livello di integrità (come i processi sandboxati dei browser).
(Su questâultimo punto ammetto di non aver effettuato un controllo formale per conferma.)
Analizzando le DACL, risulta che SYSTEM e gli amministratori abbiano accesso completo, ma anche gli altri utenti possono comunque comunicare con il driver, seppur con permessi limitati.
Questo comportamento rende il driver troppo socievole: chiunque può comunicare tramite IOCTL, e in assenza di controlli adeguati il dispatch deve essere gestito in modo estremamente rigoroso per evitare vulnerabilità .
Dispatch delle IOCTL
Prima di entrare nei dettagli specifici del driver Fortips, è utile un breve ripasso.
Le IOCTL (Input/Output Control) permettono ai processi user-mode di inviare comandi specifici ai driver.
In Windows, la funzione DeviceIoControl consente di:
- passare un handle al device
- specificare un codice IOCTL
- fornire buffer di input/output
In sostanza, è il modo per dire:
âEsegui questa operazione con questi dati.â
Analizzando le IOCTL del driver, una in particolare risulta sospetta: 0x12C803.
Questa IOCTL utilizza METHOD_NEITHER, il piĂš pericoloso tra i metodi previsti da Windows: il kernel passa puntatori userâmode direttamente al driver senza alcuna validazione.
Ă quindi responsabilitĂ totale del driver verificare:
- validitĂ del puntatore
- accessibilitĂ
- dimensione prevista
Se queste verifiche mancano, lâattaccante può passare puntatori arbitrari, inducendo il driver a leggere/scrivere memoria a cui non dovrebbe accedere.
Tramite questo tool è possibile confermare che il driver utilizza direttamente la IOCTL di tipo METHOD_NEITHER.
Il driver utilizza direttamente il UserBuffer fornito dal chiamante per scrivere lâoutput, senza alcuna copia o validazione preventiva. Questo significa che un processo userâmode può passare un puntatore arbitrario, che il driver userĂ come destinazione dei dati. Senza controlli adeguati, basta un indirizzo malizioso per trasformare un semplice output in una scrittura arbitraria in kernelâmode, con ovvie implicazioni di sicurezza.
Analisi della funzione vulnerabile
Seguendo il flusso del buffer, la funzione copia il contenuto del buffer user-mode in un buffer locale sullo stack. I primi 24 byte (0x18) vengono interpretati come:
- ULONGLONG Code
- ULONGLONG Size
- ULONGLONG Buffer
Il campo Size non è rilevante in questa catena, mentre Code e Buffer sÏ.
Per raggiungere il ramo vulnerabile, Code deve essere 0x63.
Dopo la copia preliminare in un buffer locale, il driver salta nella condizione interessata.
A questo punto, uVar7 viene impostato a 4.
Qui si trova il cuore della vulnerabilitĂ :
il driver copia 4 byte da un buffer non inizializzato allâindirizzo specificato dallâutente tramite la IOCTL.
Non vi è alcun controllo o sanitizzazione.
PoichÊ la sorgente dei dati è stack-junk, la vulnerabilità si traduce in una arbitrary 4-byte write.
Specificando ad esempio lâindirizzo kernel della struttura _TOKEN, è possibile ottenere una privilege escalation.
Nel mio PoC, ho modificato il token per abilitare il privilegio SeDebugPrivilege, quindi ho avviato un cmd come SYSTEM.
Avvio del driver
Per ridurre lâinterazione necessaria da parte dellâutente, ho analizzato il meccanismo con cui FortiClient avvia il servizio IPSec.
Il processo principale utilizza una Named Pipe per gestire la comunicazione IPC, inviando un buffer alla pipe
\\Device\\NamedPipe\\FC_{6DA09263-AA93-452B-95F3-B7CEC078EB30}.
Allâinterno del buffer sono presenti diversi campi, tra cui il nome del tunnel IPSec da inizializzare.Questa chiamata risulta sufficiente ad avviare il driver, anche senza privilegi amministrativi, condizione essenziale per la vulnerabilitĂ .
Nella versione FortiClient VPN 7.4.3.1790 è inoltre possibile creare un profilo IPSec completamente fittizio, utilizzando parametri arbitrari. Nel mio caso, per la fase di test, ho impostato un gateway remoto come âgoogle.itâ, un comportamento diverso da quanto indicato da Fortinet nel bollettino ufficiale della CVE.
Proof of Concept
Video Player
Restrizioni
Come giĂ accennato, lo sfruttamento di questa vulnerabilitĂ si basa sulla possibilitĂ di ottenere lâindirizzo kernel del token associato al processo, cosĂŹ da poterne manipolare i privilegi. A partire da Windows 11 24H2 questo non è piĂš possibile da un processo con Integrity Level medio tramite la tradizionale chiamata NtQuerySystemInformation, poichĂŠ ora per accedere a tali informazioni è richiesto il privilegio SeDebugPrivilege, normalmente non disponibile agli utenti non amministratori.
Nel mio proof-of-concept ho sfruttato la vulnerabilitĂ [url=https://www.redhotcyber.com/en/cve-details/?cve_id=CVE-2025-53136]CVE-2025-53136[/url], che tramite una race condition consente di ottenere il leak dellâindirizzo del _TOKEN. In questo modo il PoC rimane funzionante fino alla correzione della vulnerabilitĂ prevista per gli aggiornamenti di agosto/settembre 2025.
Al di fuori di questo caso specifico, per sfruttare la vulnerabilitĂ su un sistema completamente aggiornato sarebbe necessario disporre di un ulteriore bug in grado di fornire il leak dellâindirizzo richiesto, poichĂŠ le protezioni introdotte nel nuovo kernel impediscono di ottenerlo direttamente.
Timeline
- 31-01-2025: VulnerabilitĂ segnalata al PSIRT di Fortinet.
- 19-02-2025: VulnerabilitĂ confermata dal PSIRT di Fortinet.
- 09-05-2025: Fortinet dichiara di aver risolto il problema assegnando CVE-2025-47761.
- 18-11-2025: Fortinet pubblica sul PSIRT il bollettino riguardante la CVE.
L'articolo HackerHood di RHC scopre una privilege escalation in FortiClient VPN proviene da Red Hot Cyber.
Overview
- Microsoft
- Windows 10 Version 1809
Description
Statistics
- 1 Post
Fediverse
HackerHood di RHC scopre una privilege escalation in FortiClient VPN
Lâanalisi che segue esamina il vettore di attacco relativo alla CVE-2025-47761, una vulnerabilitĂ individuata nel driver kernel Fortips_74.sys utilizzato da FortiClient VPN per Windows. Il cuore della problematica risiede in una IOCTL mal gestita che permette a processi user-mode non privilegiati di interagire con il kernel, abilitando una primitiva di scrittura arbitraria di 4 byte.
La falla è stata individuata il 31 gennaio 2025 da Alex Ghiotto, membro della community di Hackerhood. Sebbene la patch correttiva sia stata integrata già a settembre 2025 con il rilascio della versione 7.4.4,
Fortinet ha formalizzato la vulnerabilitĂ solo il 18 novembre 2025 con la pubblicazione del bollettino ufficiale FG-IR-25-112.
Questo caso studio risulta particolarmente interessante per valutare lâefficacia delle moderne mitigazioni di sistema: lâexploit si basa infatti sul reperimento dellâindirizzo kernel del token di processo, unâoperazione resa complessa a partire da Windows 11 24H2. In questâultima versione, lâaccesso a tali informazioni tramite NtQuerySystemInformation richiede ora il privilegio SeDebugPrivilege, innalzando significativamente i requisiti necessari per un attacco efficace da parte di utenti non amministratori.
Analisi Tecnica della CVE-2025-47761
Fortips_74.sys è un driver kernel utilizzato da alcune soluzioni Fortinet, tra cui FortiClientVPN. Nel corso dellâanalisi del driver è emersa una vulnerabilitĂ successivamente identificata e corretta come CVEâ2025â47761. Lâobiettivo di questo articolo è descrivere il processo di analisi che ha portato alla sua individuazione e comprenderne le principali implicazioni di sicurezza. La vulnerabilitĂ consente una scrittura arbitraria di 4 byte in un indirizzo controllato dallâutente. Questo comportamento può causare un crash del sistema oppure essere sfruttato per ottenere una completa escalation dei privilegi.
Interagire col Driver
Quando si analizza un driver alla ricerca di una potenziale escalation dei privilegi, la prima domanda fondamentale è: chi può interagirci?
Se anche utenti non privilegiati possono aprire un handle, allora vale la pena approfondire.
In questo caso, il primo passo è osservare chi può interagire con Fortips_74.sys.
Usando WinObj, si nota immediatamente che il driver non imposta permessi restrittivi: questo attira subito lâattenzione.
Una vista piÚ tecnica delle DACL è possibile dal kernel tramite WinDBG
Il driver Fortips_74 crea infatti un device kernel senza definire DACL personalizzate, affidandosi al security descriptor di default. In pratica, qualunque processo nel sistema può aprire un handle verso il driver, compresi quelli a basso livello di integrità (come i processi sandboxati dei browser).
(Su questâultimo punto ammetto di non aver effettuato un controllo formale per conferma.)
Analizzando le DACL, risulta che SYSTEM e gli amministratori abbiano accesso completo, ma anche gli altri utenti possono comunque comunicare con il driver, seppur con permessi limitati.
Questo comportamento rende il driver troppo socievole: chiunque può comunicare tramite IOCTL, e in assenza di controlli adeguati il dispatch deve essere gestito in modo estremamente rigoroso per evitare vulnerabilità .
Dispatch delle IOCTL
Prima di entrare nei dettagli specifici del driver Fortips, è utile un breve ripasso.
Le IOCTL (Input/Output Control) permettono ai processi user-mode di inviare comandi specifici ai driver.
In Windows, la funzione DeviceIoControl consente di:
- passare un handle al device
- specificare un codice IOCTL
- fornire buffer di input/output
In sostanza, è il modo per dire:
âEsegui questa operazione con questi dati.â
Analizzando le IOCTL del driver, una in particolare risulta sospetta: 0x12C803.
Questa IOCTL utilizza METHOD_NEITHER, il piĂš pericoloso tra i metodi previsti da Windows: il kernel passa puntatori userâmode direttamente al driver senza alcuna validazione.
Ă quindi responsabilitĂ totale del driver verificare:
- validitĂ del puntatore
- accessibilitĂ
- dimensione prevista
Se queste verifiche mancano, lâattaccante può passare puntatori arbitrari, inducendo il driver a leggere/scrivere memoria a cui non dovrebbe accedere.
Tramite questo tool è possibile confermare che il driver utilizza direttamente la IOCTL di tipo METHOD_NEITHER.
Il driver utilizza direttamente il UserBuffer fornito dal chiamante per scrivere lâoutput, senza alcuna copia o validazione preventiva. Questo significa che un processo userâmode può passare un puntatore arbitrario, che il driver userĂ come destinazione dei dati. Senza controlli adeguati, basta un indirizzo malizioso per trasformare un semplice output in una scrittura arbitraria in kernelâmode, con ovvie implicazioni di sicurezza.
Analisi della funzione vulnerabile
Seguendo il flusso del buffer, la funzione copia il contenuto del buffer user-mode in un buffer locale sullo stack. I primi 24 byte (0x18) vengono interpretati come:
- ULONGLONG Code
- ULONGLONG Size
- ULONGLONG Buffer
Il campo Size non è rilevante in questa catena, mentre Code e Buffer sÏ.
Per raggiungere il ramo vulnerabile, Code deve essere 0x63.
Dopo la copia preliminare in un buffer locale, il driver salta nella condizione interessata.
A questo punto, uVar7 viene impostato a 4.
Qui si trova il cuore della vulnerabilitĂ :
il driver copia 4 byte da un buffer non inizializzato allâindirizzo specificato dallâutente tramite la IOCTL.
Non vi è alcun controllo o sanitizzazione.
PoichÊ la sorgente dei dati è stack-junk, la vulnerabilità si traduce in una arbitrary 4-byte write.
Specificando ad esempio lâindirizzo kernel della struttura _TOKEN, è possibile ottenere una privilege escalation.
Nel mio PoC, ho modificato il token per abilitare il privilegio SeDebugPrivilege, quindi ho avviato un cmd come SYSTEM.
Avvio del driver
Per ridurre lâinterazione necessaria da parte dellâutente, ho analizzato il meccanismo con cui FortiClient avvia il servizio IPSec.
Il processo principale utilizza una Named Pipe per gestire la comunicazione IPC, inviando un buffer alla pipe
\\Device\\NamedPipe\\FC_{6DA09263-AA93-452B-95F3-B7CEC078EB30}.
Allâinterno del buffer sono presenti diversi campi, tra cui il nome del tunnel IPSec da inizializzare.Questa chiamata risulta sufficiente ad avviare il driver, anche senza privilegi amministrativi, condizione essenziale per la vulnerabilitĂ .
Nella versione FortiClient VPN 7.4.3.1790 è inoltre possibile creare un profilo IPSec completamente fittizio, utilizzando parametri arbitrari. Nel mio caso, per la fase di test, ho impostato un gateway remoto come âgoogle.itâ, un comportamento diverso da quanto indicato da Fortinet nel bollettino ufficiale della CVE.
Proof of Concept
Video Player
Restrizioni
Come giĂ accennato, lo sfruttamento di questa vulnerabilitĂ si basa sulla possibilitĂ di ottenere lâindirizzo kernel del token associato al processo, cosĂŹ da poterne manipolare i privilegi. A partire da Windows 11 24H2 questo non è piĂš possibile da un processo con Integrity Level medio tramite la tradizionale chiamata NtQuerySystemInformation, poichĂŠ ora per accedere a tali informazioni è richiesto il privilegio SeDebugPrivilege, normalmente non disponibile agli utenti non amministratori.
Nel mio proof-of-concept ho sfruttato la vulnerabilitĂ [url=https://www.redhotcyber.com/en/cve-details/?cve_id=CVE-2025-53136]CVE-2025-53136[/url], che tramite una race condition consente di ottenere il leak dellâindirizzo del _TOKEN. In questo modo il PoC rimane funzionante fino alla correzione della vulnerabilitĂ prevista per gli aggiornamenti di agosto/settembre 2025.
Al di fuori di questo caso specifico, per sfruttare la vulnerabilitĂ su un sistema completamente aggiornato sarebbe necessario disporre di un ulteriore bug in grado di fornire il leak dellâindirizzo richiesto, poichĂŠ le protezioni introdotte nel nuovo kernel impediscono di ottenerlo direttamente.
Timeline
- 31-01-2025: VulnerabilitĂ segnalata al PSIRT di Fortinet.
- 19-02-2025: VulnerabilitĂ confermata dal PSIRT di Fortinet.
- 09-05-2025: Fortinet dichiara di aver risolto il problema assegnando CVE-2025-47761.
- 18-11-2025: Fortinet pubblica sul PSIRT il bollettino riguardante la CVE.
L'articolo HackerHood di RHC scopre una privilege escalation in FortiClient VPN proviene da Red Hot Cyber.