CVE-2026-31431 (CVSS 7.8) è un difetto logico nell'interfaccia socket AEAD del kernel Linux (AF_ALG) scoperto nel 2026. La vulnerabilità consente a qualsiasi utente locale non privilegiato di elevare i propri privilegi a root in pochi secondi.

Dettagli Tecnici

• Componente Interessato: modulo kernel algif_aead (interfaccia crittografica AF_ALG)
• Tipo di Vulnerabilità: difetto logico nella gestione delle operazioni di copia
• Vettore di Attacco: Locale
• Privilegi Richiesti: Nessuno (utente non privilegiato)
• Interazione con l'Utente: Nessuna
• Impatto: Compromissione completa del sistema (accesso root)

Sistemi Interessati

Versioni del Kernel: kernel Linux >= 4.10 (rilasciato nel 2017)

Distribuzioni Interessate:

• Red Hat Enterprise Linux 7, 8, 9
• CentOS 7, 8, 9 (e Stream)
• Fedora (tutte le versioni attualmente supportate)
• Ubuntu 17.04 e successive
• Debian 9 (Stretch) e successive
• SUSE Linux Enterprise 12, 15

Nota: Qualsiasi distribuzione Linux con kernel 4.10 o successivo è potenzialmente vulnerabile.

Perché è Importante

Questa vulnerabilità è particolarmente pericolosa perché:

1. Nessun privilegio richiesto - Qualsiasi account utente può sfruttarla
2. Escalation immediata - Accesso root in pochi secondi
3. Impatto diffuso - Interessa 7+ anni di release del kernel
4. Esecuzione locale - Nessun accesso remoto necessario, ma gli attaccanti che ottengono un primo accesso possono immediatamente elevare i privilegi
5. Sfruttamento attivo - Sono disponibili exploit pubblici

Impatto nel Mondo Reale

Una volta che un attaccante ha qualsiasi forma di accesso locale (SSH, web shell, fuga dal container, ecc.), può:

• Ottenere il controllo completo del sistema
• Installare backdoor persistenti
• Accedere a dati sensibili
• Spostarsi verso altri sistemi sulla rete
• Distribuire ransomware o cryptominer

Risoluzioni Disponibili

In attesa delle patch del kernel fornite dai vendor, sono disponibili diverse strategie di mitigazione. cfDr le implementa tutte, con raccomandazioni intelligenti basate sulla configurazione del tuo sistema.

Comprendere i Livelli di Protezione

Non tutte le risoluzioni sono uguali. Ecco cosa devi sapere:

Approccio Consigliato: Difesa in Profondità

Raccomandazione predefinita di cfDr: Flag 3 (Blacklist del Modulo + SELinux)

Questo fornisce due livelli di protezione indipendenti:``` ┌─────────────────────────────────────────────────┐ │ Layer 1: Module Blacklist │ │ • Prevents modprobe algif_aead │ │ • Persists across reboots │ │ • CAN be bypassed by malicious root (insmod) │ ├─────────────────────────────────────────────────┤ │ Layer 2: SELinux Policy │ │ • Blocks AF_ALG socket() at syscall level │ │ • Works even if module is loaded │ │ • CANNOT be bypassed from userspace │ │ • Covers user_t, unconfined_t (majority cases) │ └─────────────────────────────────────────────────┘

Result: If either layer fails, the other still protects

Tuttavia, questo è accettabile perché:

1. La vulnerabilità mira all'escalation dei privilegi (da non privilegiato a root)
2. Se un attaccante ha già i privilegi di root, può sfruttarla direttamente senza caricare il modulo
3. La blacklist dei moduli protegge contro il vettore d'attacco primario

Strategia di Protezione Completa

Per una protezione completa e non aggirabile, è necessario:

Blacklist dei moduli + almeno uno dei seguenti:

• Policy SELinux (consigliata per Enterprise Linux)
• Filtri seccomp di systemd (protezione per singolo servizio)
• Programma eBPF LSM (solo RHEL 9+, a livello di sistema)

Riferimento Flag di Mitigazione

cfDr utilizza flag bitwise per abilitare più mitigazioni:

Calcolo dei flag: 1 (blacklist) + 2 (SELinux) + 4 (seccomp) + 8 (eBPF) = somma

Lacune di Copertura da Tenere Presenti

Protezione SELinux:

• Copre solo i domini specificati nella policy: user_t, unconfined_t, httpd_t, postgresql_t, mysqld_t
• I processi in esecuzione in altri domini SELinux potrebbero non essere protetti
• In pratica, user_t e unconfined_t coprono la stragrande maggioranza degli scenari d'attacco

Protezione seccomp di systemd:

• Protegge solo i servizi configurati esplicitamente
• La configurazione predefinita copre: httpd, nginx, postgresql, mariadb, redis, memcached
• I processi al di fuori di questi servizi non sono protetti

Protezione eBPF LSM:

• Richiede kernel 5.7+ (RHEL 9, Fedora 34+)
• La complessità richiede competenze specifiche per un'implementazione corretta
• Può fornire una protezione completa a livello di sistema se configurata correttamente

Metodologia di Rilevamento

Come cfDr Rileva la Vulnerabilità

cfDr esegue una valutazione completa su più dimensioni:

1. Controllo della Versione del Kernel```bash

uname -r

• Verifica se il modulo algif_aead esiste nel kernel
• Controlla la posizione del modulo e i relativi metadati

3. Stato di caricamento del modulo```bash

lsmod | grep algif_aead

• Identifica socket AF_ALG attivi
• Indica una potenziale sfruttamento attivo

5. Rilevamento delle Mitigazioni Esistenti

Blacklist dei Moduli:```bash grep -E "blacklist algif_aead|install algif_aead" /etc/modprobe.d/*.conf

systemd seccomp:```bash systemctl show | grep RestrictAddressFamilies

Come funziona cfDr

Architettura

cfDr è costruito come un moderno ruolo Ansible con più punti di ingresso per playbook:``` cfDr/ ├── roles/ │ └── cve_2026_31431/ # Main role │ ├── tasks/ │ │ ├── main.yml # Role orchestration │ │ ├── assessment.yml # Vulnerability detection │ │ ├── remediation_module_blacklist.yml │ │ ├── remediation_selinux.yml │ │ ├── remediation_seccomp.yml │ │ ├── remediation_ebpf.yml │ │ ├── reporting.yml # Status reporting │ │ └── inventory_update.yml # Inventory generation │ ├── templates/ # Config file templates │ ├── defaults/ # Default variables │ └── handlers/ # Service restarts, etc. ├── quickstart.yml # Simplest usage ├── sample_playbook.yml # Multiple examples └── cve_2026_31431_playbook.yml # Full-featured playbook

Modalità di Remediation (apply_remediation=true)```

1-8. [Same as Assessment Mode] ↓ 9. Apply Module Blacklist (if flag 1) • Unload module if loaded • Create blacklist config • Update initramfs/initrd • Verify blacklist works ↓ 10. Apply SELinux Policy (if flag 2) • Install policy packages • Compile policy module • Install policy • Verify policy active ↓ 11. Apply systemd seccomp (if flag 4) • Create drop-in files • Reload systemd • Restart services • Verify filters active ↓ 12. Apply eBPF LSM (if flag 8) • Compile eBPF program • Load into kernel • Verify program attached ↓ 13. Re-assess protection status ↓ 14. Generate reports ↓ 15. Create summary

3. Aggiorna initramfs/initrd per persistere tra i riavvii:
   • Debian/Ubuntu: update-initramfs -u
   • RHEL/Fedora: dracut -f
4. Verifica che il modulo non possa essere caricato tramite modprobe

Protezione: Immediata, nessun riavvio richiesto Persistenza: Sopravvive a riavvii e aggiornamenti del kernel

Politica SELinux (Flag 2)

Cosa fa:

1. Installa i pacchetti richiesti:
   • policycoreutils
   • policycoreutils-python-utils
   • selinux-policy-devel
   • checkpolicy
2. Crea un modulo di politica SELinux che nega la creazione di socket AF_ALG
3. Compila la politica utilizzando il sistema di build SELinux
4. Installa il modulo di politica: semodule -i cve_2026_31431_af_alg_deny.pp
5. Verifica che la politica sia attiva

Domini protetti (predefiniti):

• user_t - Processi utente regolari
• unconfined_t - Processi non confinati
• httpd_t - Server web Apache
• postgresql_t - Database PostgreSQL
• mysqld_t - Database MySQL/MariaDB

Protezione: Blocca a livello LSM, non può essere aggirata Persistenza: La politica sopravvive ai riavvii

systemd seccomp (Flag 4)

Cosa fa:

1. Crea file drop-in di systemd: /etc/systemd/system/<service>.service.d/90-cve-2026-31431-block-af-alg.conf
2. Aggiunge la direttiva RestrictAddressFamilies=~AF_ALG
3. Ricarica il daemon di systemd
4. Riavvia i servizi interessati
5. Verifica che i filtri siano attivi

Servizi protetti (predefiniti):

• httpd, nginx - Server web
• postgresql, mariadb - Database
• redis, memcached - Server cache

Protezione: Blocca la creazione di socket a livello di syscall per servizio Persistenza: Sopravvive a riavvii e aggiornamenti dei servizi

eBPF LSM (Flag 8)

Cosa fa:

1. Compila un programma eBPF per bloccare la creazione di socket AF_ALG
2. Carica il programma nel kernel
3. Lo collega agli hook LSM
4. Verifica che il programma sia attivo

Requisiti:

• Kernel 5.7+ con CONFIG_BPF_LSM=y
• RHEL 9, Fedora 34+, o kernel compilato personalizzato

Protezione: Politica dinamica e programmabile a livello di sistema Persistenza: Richiede un servizio di sistema per il ricaricamento all'avvio

Generazione dell'inventario

cfDr può generare file di inventario pronti all'uso contenenti solo host vulnerabili:

File generati:``` inventory_output/ ├── vulnerable_hosts.yml # YAML inventory ├── vulnerable_hosts.ini # INI inventory ├── group_vars_vulnerable_hosts.yml # Group variables └── host_vars/ ├── host1.yml # Per-host details └── host2.yml

Cosa Potrebbe Essere Interessato (Casi Limite Rari)

Secondo l'analisi di R-fx Networks:

"Per la maggior parte degli ambienti HPC, questo non romperà nulla – AF_ALG è una porta d'ingresso a livello utente per la crittografia del kernel che quasi nessuno usa realmente."

Solo queste configurazioni estremamente rare potrebbero essere interessate:

1. OpenSSL con Motore afalg Esplicitamente Abilitato

NON predefinito su RHEL. Il motore afalg deve essere configurato esplicitamente:```bash

Check if afalg engine is enabled (rare)

openssl engine afalg

If this returns "afalg is not available", you're safe

Risultato atteso: Tutti i servizi continuano a funzionare normalmente.

Consenso della Comunità Professionale di Sicurezza

Numerose organizzazioni di sicurezza autorevoli confermano la nostra valutazione:

CERT-EU (30 aprile 2026):

"Le build predefinite di dm-crypt / LUKS, kTLS, IPsec, SSH e OpenSSL / GnuTLS non dipendono da AF_ALG"

Sysdig (29 aprile 2026):

Documenta che le operazioni crittografiche standard utilizzano API in-kernel, non socket AF_ALG

R-fx Networks (2 maggio 2026):

"I carichi di lavoro di hosting non utilizzano legittimamente AF_ALG, rendendone sicura la disabilitazione come mitigazione senza impattare i servizi di produzione"

HPCsec (30 aprile 2026):

"Per la maggior parte degli ambienti HPC, questo non romperà nulla – AF_ALG è una porta d'ingresso userspace alla crittografia del kernel che quasi nessuno usa realmente"

Raccomandazione per la Distribuzione in Produzione

Per Ambienti RHEL/CentOS/Fedora Standard:

1. ✅ Distribuire il Flag 3 di cfDr immediatamente - Zero impatto operativo
2. ✅ Tutti i servizi critici continueranno a funzionare - Verificato dalla community di sicurezza
3. ✅ Nessuna modifica alle applicazioni richiesta - I percorsi crittografici standard non sono interessati
4. ✅ Monitorare Red Hat per le patch del kernel - Ma non aspettare per mitigare
5. ✅ Mantenere la difesa in profondità dopo la patch - Livello di sicurezza aggiuntivo senza costi

Matrice Decisionale:

Riepilogo

Le remediation di cfDr sono sicure per tutte le distribuzioni RHEL standard. Il modulo algif_aead e l'interfaccia socket AF_ALG non sono utilizzati da alcuna crittografia di sistema critica sui sistemi Enterprise Linux.

Cosa significa:

• ✅ La tua crittografia del disco (LUKS) continua a funzionare
• ✅ Le tue VPN (IPsec) continuano a funzionare
• ✅ Le tue connessioni SSH continuano a funzionare
• ✅ I tuoi server web (HTTPS) continuano a funzionare
• ✅ I tuoi database continuano a funzionare
• ✅ Tutti i sistemi di autenticazione continuano a funzionare

L'unico rischio teorico riguarda applicazioni personalizzate programmate esplicitamente per utilizzare socket AF_ALG - uno scenario così raro che molteplici organizzazioni di sicurezza hanno confermato indipendentemente che è sicuro bloccare AF_ALG negli ambienti enterprise.

Flusso di Lavoro Raccomandato

Flusso di Lavoro Enterprise Standard

Questo flusso di lavoro bilancia completezza e sicurezza operativa:

Passo 1: Valutazione Iniziale (Sola Lettura)```bash

Scan all hosts without making changes

ansible-playbook -i inventory quickstart.yml

Passaggio 2: Generare l'inventario delle vulnerabilità```bash

Create inventory of vulnerable hosts with recommendations

ansible-playbook -i inventory quickstart.yml -e generate_inventory=true -e inventory_output_dir=./vulnerable_hosts

Passaggio 3: Testare la correzione in un ambiente non di produzione```bash

Apply to test/dev hosts first

ansible-playbook -i vulnerable_hosts/vulnerable_hosts.yml cve_2026_31431_playbook.yml
-e apply_remediation=true
--limit 'dev*:test*'

Applicazioni di test:

• Verificare che i servizi critici funzionino
• Controllare la funzionalità delle applicazioni
• Monitorare i log per individuare problemi

Passaggio 4: Rimedio in Produzione (Per Fasi)```bash

Apply to production in stages

Stage 1: Web tier

ansible-playbook -i vulnerable_hosts/vulnerable_hosts.yml cve_2026_31431_playbook.yml
-e apply_remediation=true
--limit 'web*'

Stage 2: Application tier

ansible-playbook -i vulnerable_hosts/vulnerable_hosts.yml cve_2026_31431_playbook.yml
-e apply_remediation=true
--limit 'app*'

Stage 3: Database tier (most critical)

ansible-playbook -i vulnerable_hosts/vulnerable_hosts.yml cve_2026_31431_playbook.yml
-e apply_remediation=true
--limit 'db*'

Documento:

• Registra quali host sono stati corretti
• Annota eventuali problemi riscontrati
• Aggiorna i registri di change management

Risultato finale previsto:``` CVE-2026-31431 Summary Report

Total hosts scanned: 50 Vulnerable hosts: 0

All hosts protected with defense-in-depth mitigations

Utilizzare questo approccio quando:

• Rilevata un’attività di sfruttamento attiva
• Sistemi critici a rischio immediato
• Il tempo è più critico del processo

Attenzione: Questa operazione applica le mitigazioni a TUTTI gli host vulnerabili contemporaneamente. Monitorare attentamente.

Flusso di lavoro per il monitoraggio continuo

Per la conformità continua e il rilevamento di nuovi sistemi:```bash

Weekly automated scan

0 2 * * 0 ansible-playbook -i inventory quickstart.yml -e generate_inventory=true

Alert on new vulnerabilities

(integrate with monitoring system)

Workflow di verifica

Dopo la correzione, verifica la protezione:```bash

On remediated host:

sudo lsmod | grep algif_aead

Should return nothing (module not loaded)

sudo modprobe algif_aead

Should fail: "modprobe: ERROR: could not insert 'algif_aead'"

cat /etc/modprobe.d/blacklist-algif_aead-cve-2026-31431.conf

Should show blacklist configuration

Check SELinux policy

sudo semodule -l | grep cve_2026_31431

Should show: cve_2026_31431_af_alg_deny

Check seccomp (for services)

systemctl show httpd | grep RestrictAddressFamilies

Should show: RestrictAddressFamilies=~AF_ALG

Utilizzo con Inventario Personalizzato```bash

Assess with your inventory

ansible-playbook -i /path/to/your/inventory quickstart.yml

Remediate vulnerable hosts

ansible-playbook -i /path/to/your/inventory quickstart.yml
--limit vulnerable_hosts
-e apply_remediation=true

Configurazione Avanzata

Personalizzazione dei Flag di Mitigazione

Sovrascrivi le mitigazioni predefinite per ogni esecuzione del playbook:```bash

Module blacklist only

ansible-playbook quickstart.yml -e apply_remediation=true -e mitigation_flags=1

SELinux only

ansible-playbook quickstart.yml -e apply_remediation=true -e mitigation_flags=2

Module blacklist + SELinux (default recommended)

ansible-playbook quickstart.yml -e apply_remediation=true -e mitigation_flags=3

Enhanced: Blacklist + SELinux + seccomp

ansible-playbook quickstart.yml -e apply_remediation=true -e mitigation_flags=7

Maximum: All mitigations (RHEL 9+ only)

ansible-playbook quickstart.yml -e apply_remediation=true -e mitigation_flags=15

Personalizzazione dei servizi seccomp

Modifica roles/cve_2026_31431/defaults/main.yml:```yaml

Add additional services to protect

seccomp_protected_services:

• httpd
• nginx
• postgresql
• mariadb
• redis
• memcached
• your-custom-service # Your service

Utilizzo dei Modelli di Playbook di Esempio

Il file sample_playbook.yml contiene diversi esempi:```yaml

Example 1: Assessment only

• hosts: all roles:
  • cve_2026_31431

Example 2: Module blacklist only

• hosts: all vars: apply_remediation: true mitigation_flags: 1 roles:
  • cve_2026_31431

Example 3: Recommended (Blacklist + SELinux)

• hosts: all vars: apply_remediation: true mitigation_flags: 3 roles:
  • cve_2026_31431

4. Monitoraggio Automatico: ```bash

   Install Red Hat Security Advisories plugin for yum

   sudo yum install yum-plugin-security

   Check for security updates

   sudo yum updateinfo list security

   Check specifically for kernel updates

   sudo yum updateinfo list security kernel

   root@kitploit:~

Cosa cercare:

• RHSA (Red Hat Security Advisory) per il kernel
• Titolo dell'avviso contenente "CVE-2026-31431"
• Versioni RHEL interessate corrispondenti al tuo ambiente

Esempio di formato dell'avviso:``` RHSA-2026:XXXX - Important: kernel security update Severity: Important CVEs: CVE-2026-31431 Affected Products: RHEL 7, 8, 9

Ubuntu

Fonte primaria: Avvisi di sicurezza Ubuntu

• Database USN: https://ubuntu.com/security/notices
• Tracker CVE: https://ubuntu.com/security/CVE-2026-31431

Metodi di notifica:```bash

Subscribe to security announcements

Visit: https://lists.ubuntu.com/mailman/listinfo/ubuntu-security-announce

Check for security updates

sudo apt update sudo apt list --upgradable | grep security

Ubuntu Security Notices tool

sudo apt install ubuntu-security-tools usn list --cve CVE-2026-31431

SUSE / openSUSE

Fonte primaria: SUSE Security

• Aggiornamenti di sicurezza: https://www.suse.com/support/update/
• Database CVE: https://www.suse.com/security/cve/CVE-2026-31431.html

Metodi di notifica:```bash

Check for security patches

sudo zypper list-patches --category security

Specific CVE check

sudo zypper info --cve CVE-2026-31431

Script di Monitoraggio Automatico delle Patch

Crea uno script di monitoraggio per il tuo ambiente:```bash #!/bin/bash

check-cve-2026-31431-patch.sh

Monitors for CVE-2026-31431 kernel patches

DISTRO=$(grep ^ID= /etc/os-release | cut -d= -f2 | tr -d '"')

case $DISTRO in rhel|centos|rocky|alma) yum updateinfo list security kernel 2>/dev/null | grep -i CVE-2026-31431 ;; fedora) dnf updateinfo list security kernel 2>/dev/null | grep -i CVE-2026-31431 ;; ubuntu|debian) apt-get update -qq apt-cache show linux-image-$(uname -r) | grep CVE-2026-31431 ;; sles|opensuse*) zypper info --cve CVE-2026-31431 kernel-default ;; esac

Check Red Hat Security Data API

curl -s "https://access.redhat.com/labs/securitydataapi/cve/CVE-2026-31431.json" |
jq -r '.affected_release[] | select(.package | startswith("kernel")) | "(.product_name): (.advisory) - (.package)"'

Cosa fare quando vengono rilasciate le patch

1. Verifica la disponibilità della patch: ```bash

   Check your distribution's update mechanism

   sudo yum check-update kernel # RHEL/CentOS/Fedora sudo apt update && apt list --upgradable linux-image-* # Ubuntu/Debian

   root@kitploit:~

2. Rivedi le note di rilascio:

   • Leggi l'avviso del fornitore per le istruzioni di installazione
   • Controlla eventuali problemi noti o prerequisiti
   • Verifica i numeri di versione del kernel

3. Testa in ambiente non di produzione: ```bash

   Apply kernel update to test systems first

   sudo yum update kernel # RHEL/CentOS/Fedora sudo apt upgrade linux-image-* # Ubuntu/Debian sudo reboot

   root@kitploit:~

4. Verificare l'efficacia della patch: ```bash

   After reboot, verify kernel version

   uname -r

   Run cfDr assessment to confirm patch

   ansible-playbook -i inventory quickstart.yml

   root@kitploit:~

5. Pianificare il rollout in produzione:

   • Pianificare le finestre di manutenzione
   • Distribuire gli aggiornamenti del kernel in fasi
   • Pianificare riavvii/reboot dei servizi

6. Rimuovere le mitigazioni temporanee (opzionale): ```bash

   After patching, temporary mitigations can be removed

   However, defense-in-depth recommends keeping them

   If you choose to remove:

   sudo rm /etc/modprobe.d/blacklist-algif_aead-cve-2026-31431.conf sudo semodule -r cve_2026_31431_af_alg_deny # SELinux policy

   Remove seccomp drop-in files

   Update initramfs/initrd

   root@kitploit:~

Raccomandazione: Anche dopo l'applicazione della patch al kernel, considera di mantenere attive le mitigazioni di difesa in profondità come protezione contro vulnerabilità future.

Supporto e Contributi

Segnalazione di Problemi

Hai trovato un bug o desideri richiedere una funzionalità?

1. Controlla i problemi esistenti: https://github.com/parmstro/cfDr/issues
2. Crea un nuovo problema: Includi:
   • Versione di cfDr
   • Versione di Ansible
   • Sistema operativo di destinazione e versione
   • Messaggi di errore completi
   • Passaggi per riprodurre il problema

Contribuire

Accogliamo con piacere i contributi! Consulta docs/CONTRIBUTORS.md per:

• Come contribuire al codice
• Miglioramenti alla documentazione
• Test e segnalazioni di bug
• Suggerimenti di funzionalità

Assistenza

• Problemi: https://github.com/parmstro/cfDr/issues
• Discussioni: https://github.com/parmstro/cfDr/discussions

Collaboratori

cfDr si basa sulla competenza collettiva dei professionisti della sicurezza:

• Paul Armstrong (@parmstro) - Responsabile del progetto, implementazioni di blacklist dei moduli e seccomp
• Anthony Green (@atgreen) - Implementazione della mitigazione eBPF LSM
• Greg Procunier (@gprocunier) - Implementazione della mitigazione tramite policy SELinux
• Claude Sonnet 4.5 - Assistenza allo sviluppo, documentazione e ricerca

Consulta docs/CONTRIBUTORS.md per i dettagli completi sui contributi.

Licenza

Questo progetto è fornito sotto la Licenza MIT per scopi di valutazione delle vulnerabilità e remediation.

Consulta LICENSE per i dettagli.

Dichiarazione di Esclusione di Responsabilità

IMPORTANTE: Questo strumento fornisce mitigazioni temporanee in attesa delle patch del kernel fornite dal vendor. Queste mitigazioni riducono significativamente il rischio ma potrebbero non fornire una protezione completa in tutti gli scenari.

cfDr è fornito "così com'è" senza garanzia. Ricorda sempre di:

• Testare prima in ambienti non di produzione
• Comprendere la copertura e le lacune della protezione
• Monitorare i canali del vendor per le patch ufficiali
• Applicare le patch del vendor quando disponibili
• Mantenere la difesa in profondità anche dopo l'applicazione delle patch

I collaboratori e i manutentori di cfDr non sono responsabili per eventuali danni o perdite di dati derivanti dall'uso di questo strumento.

Ultimo aggiornamento: 2026-05-02T23:30:00Z