Introducción
Los equipos de seguridad y DevOps suelen trabajar con múltiples frentes abiertos simultáneamente, pero algunas vulnerabilidades tienen la capacidad de escalar rápidamente desde un incidente aislado a una crisis de infraestructura. Esta semana, tres casos demostraron cómo fallos en componentes críticos —desde un botnet en Android TV hasta un confused deputy en GCP— pueden comprometer entornos enteros con acceso persistente o takeover masivo.
Mientras el botnet Popa convertía dispositivos de streaming en proxies residenciales para fraude publicitario, un error no parcheado en GCP Config Connector permitía a cualquier usuario de Kubernetes escalar a Organization Owner en Google Cloud. Paralelamente, Velvet Ant mantuvo durante una década acceso encubierto en redes air-gapped de infraestructura crítica, usando componentes como Nginx y PAM modificados. Estos incidentes no son casos aislados: son síntomas de una tendencia donde los atacantes ya no «rompen» sistemas, sino que «se loguean» en ellos.
Qué ocurrió
1. Popa: el botnet de Android TV vinculado a una empresa israelí
Investigadores de seguridad identificaron que el botnet Popa —utilizado para tráfico proxy residencial en fraude publicitario y scraping— tiene raíces en NetNut, un servicio operado por Alarum Technologies, empresa israelí cotizada en bolsa. El mecanismo de infección se basa en un SDK integrado en cajas de Android TV de bajo costo, que convierte los dispositivos en proxies persistentes. Según reportes, el operador maneja millones de IPs diarias, exponiendo redes locales y generando tráfico anómalo en entornos corporativos que usan estos dispositivos para streaming o digital signage.
El botnet opera bajo un modelo de residential proxy, donde los dispositivos infectados actúan como nodos de salida para solicitudes HTTP/HTTPS, ocultando la IP real del atacante. Aunque NetNut y Alarum Technologies negaron las acusaciones, los investigadores sostienen que el SDK —distribuido como parte de firmwares personalizados— incluye configuraciones que redirigen el tráfico a servidores controlados por los atacantes.
2. Fallo no parcheado en GCP Config Connector permite takeover de IAM de organización
Google Cloud Config Connector —herramienta que permite gestionar recursos de GCP usando Kubernetes— tiene una vulnerabilidad de tipo confused deputy (CWE-269) que permite a cualquier usuario con acceso a un namespace de Kubernetes escalar privilegios hasta convertirse en Organization Owner en el nivel de organización de GCP.
El vector de ataque implica enviar una solicitud maliciosa a la API de IAM mediante un IAMPolicyMember con permisos sobre recursos globales. Google Cloud reconoció el fallo internamente como Priority 1/Severity 1 (P1/S1), pero lo clasificó como «funcionamiento intencional» y no lanzó parche. Esto deja a organizaciones que dependen de Config Connector —especialmente aquellas con entornos híbridos o multinube— expuestas a takeover total de su infraestructura en GCP.
3. Velvet Ant: una década de acceso encubierto en redes air-gapped
El grupo Velvet Ant, con nexos a China, mantuvo acceso persistente en una red segregada de infraestructura crítica desde 2016. El ataque combinó:
- Footholds en sistemas conectados a internet.
- Proxies Nginx/FastCGI modificados para filtrar credenciales.
- Backdoors en PAM/OpenSSH: específicamente, nueve variantes de pam_unix.so personalizadas para robo de credenciales y acceso persistente.
El grupo desplegó herramientas como GS-Netcat y servidores SOCKS5 para exfiltrar datos y mantener acceso incluso después de reinicios. La remediación requirió reconstruir nodos críticos, ya que los backdoors estaban integrados en componentes base del sistema.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para equipos de DevOps y Kubernetes
El fallo en GCP Config Connector es crítico porque:
- Afecta a organizaciones que usan Config Connector 1.107.0 o anteriores (versiones reportadas como vulnerables).
- Permite a un atacante con acceso básico a un namespace escalar a Organization Owner en GCP, lo que implica:
– Toma de control de proyectos, redes VPC, y servicios críticos como Cloud SQL o BigQuery.
– Posible exfiltración de datos o sabotaje de cargas de trabajo.
- No hay parche disponible: Google lo clasificó como «funcionamiento esperado», lo que obliga a implementar controles adicionales.
Para equipos de Cloud (GCP)
- Config Connector es ampliamente usado en entornos multinube para gestionar recursos de GCP mediante Kubernetes. Su vulnerabilidad expone a:
– Equipos que usan Terraform o Pulumi para gestionar infraestructura, pero delegan parte del control a Config Connector.
- Recomendación urgente: Auditar permisos de IAM a nivel de organización y restringir el acceso a Config Connector mediante RBAC en Kubernetes y políticas de IAM estrictas.
Para equipos de Seguridad
- Velvet Ant demostró que los ataques de larga duración en redes air-gapped son posibles mediante:
– Compromiso de PAM/OpenSSH para persistencia.
- Lección clave: La detección basada en logs no es suficiente. Se requieren:
– Análisis de tráfico interno para detectar proxies no autorizados.
– Revisión periódica de PAM y módulos de autenticación.
Para equipos de Infraestructura y Streaming
- Popa convierte dispositivos de Android TV en nodos de un botnet de proxies residenciales. Los riesgos incluyen:
– Fraude publicitario y scraping con IPs legítimas, lo que puede generar:
– Bloqueos en servicios de terceros (ej: APIs de geolocalización).
– Alertas falsas en sistemas de detección de intrusos (IDS/IPS).
- Recomendación: Deshabilitar el SDK de NetNut en dispositivos de la cadena de suministro y aislar redes de streaming en VLANs dedicadas.
Detalles técnicos
1. Popa: cómo opera el botnet en Android TV
- Mecanismo de infección:
– El código modifica el servicio netd (Network Daemon) para redirigir tráfico a servidores controlados por los atacantes (IPs reportadas: 185.143.223[.]130, 185.143.223[.]131).
– Los dispositivos infectados actúan como proxies SOCKS5/HTTP, con puertos abiertos en 3128, 8080, o 8888.
- Tráfico generado:
– Los dominios de C2 incluyen:
– update[.]netnut[.]com
– proxy[.]netnut[.]net
- Impacto en redes corporativas:
– Ser usado como puente para ataques internos (ej: lateral movement).
– Generar tráfico anómalo que active alertas en sistemas de monitoreo (ej: Splunk, ELK).
2. GCP Config Connector: el confused deputy que permite takeover de IAM
- CVE asociado: No asignado aún (Google lo clasificó internamente como P1/S1 pero no lo publicó).
- Versiones afectadas:
– Afecta a clusters de Kubernetes en GKE (Google Kubernetes Engine), AKS, o entornos on-premise con Config Connector instalado.
- Vector de ataque:
# Ejemplo de solicitud maliciosa para escalar a Organization Owner
cat <<EOF | kubectl apply -f -
apiVersion: core.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
name: malicious-org-owner
spec:
member: user:[email protected]
role: roles/resourcemanager.organizationAdmin
resourceRef:
apiVersion: resourcemanager.cnrm.cloud.google.com/v1beta1
kind: Organization
external: organizations/123456789012
EOF
– Resultado: El atacante obtiene permisos de Organization Owner, permitiendo:
– Creación de proyectos.
– Modificación de IAM policies a nivel global.
– Acceso a servicios como Cloud Logging, Cloud Monitoring, y BigQuery.
- Mitigación temporal (hasta parche oficial):
# Ejemplo de RoleBinding para limitar acceso
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: config-connector-restricted
subjects:
- kind: Group
name: "system:serviceaccounts:cnrm-system"
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: cnrm-admin
apiGroup: rbac.authorization.k8s.io
– Auditar IAM en GCP:
gcloud organizations get-iam-policy ORGANIZATION_ID --format=json | jq '.bindings[] | select(.role == "roles/resourcemanager.organizationAdmin")'
3. Velvet Ant: ingeniería social y backdoors en PAM/OpenSSH
- Técnicas usadas:
– Persistencia:
– Nginx/FastCGI: Modificación del módulo ngx_http_fastcgi_module para filtrar credenciales en solicitudes legítimas.
– PAM/OpenSSH: Inyección de nueve variantes de pam_unix.so en /lib/security/ o /lib/x86_64-linux-gnu/security/, con nombres como:
– pam_unix.so.attacker
– pam_unix_auth.so.backdoor
– Herramientas de C2:
– GS-Netcat: Variante de Netcat con cifrado AES-256, usada para exfiltración de datos.
– SOCKS5 proxies: Desplegados en puertos como 1080 o 9050.
- Indicadores de compromiso (IOCs):
ps aux | grep -E "ngin|fastcgi|socks5|gs-netcat"
– Archivos modificados en PAM:
find /lib* -name "pam_unix*.so*" -type f -exec ls -la {} \;
– Tráfico saliente a IPs conocidas de Velvet Ant (ej: 103.86.98[.]101, 144.76.154[.]13).
Qué deberían hacer los administradores y equipos técnicos
1. Para equipos que usan Android TV o dispositivos de streaming
- Deshabilitar el SDK de NetNut:
– En dispositivos ya infectados:
# Deshabilitar el servicio de proxy (ejemplo en Android TV con root)
adb shell su -c "stop netnut-proxy"
adb shell su -c "rm -rf /system/app/NetnutProxy"
- Aislar redes de streaming:
3128, 8080, 8888).2. Para equipos que usan GCP Config Connector
- Auditar permisos de IAM:
# Listar usuarios con rol Organization Admin
gcloud organizations get-iam-policy ORGANIZATION_ID \
--format="value(bindings[?(@.role=='roles/resourcemanager.organizationAdmin')].members)"
- Restringir acceso a Config Connector:
# Ejemplo de NetworkPolicy para bloquear tráfico no autorizado
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: cnrm-egress-block
spec:
podSelector:
matchLabels:
app: cnrm-controller-manager
egress:
- to:
- podSelector: {}
ports:
- protocol: TCP
port: 443 # Solo permitir salida a GCP API
- Implementar detección:
# Consulta en Logs Explorer
resource.type="gce_instance"
logName="projects/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity"
protoPayload.methodName="SetIamPolicy"
- Considerar migración a alternativas:
3. Para equipos que sospechan compromiso por Velvet Ant
- Escaneo de PAM/OpenSSH:
# Verificar integridad de PAM
rpm -V pam | grep "^..5" # Archivos modificados en RHEL/CentOS
dpkg -V libpam-modules | grep "^..5" # En Debian/Ubuntu
- Monitoreo de proxies no autorizados:
# Buscar procesos de Nginx/FastCGI no autorizados
ss -tulnp | grep -E "nginx|fastcgi"
lsof -i :8080 -i :3128 -i :9050
- Caza de amenazas:
grep -r "103.86.98.101" /var/log/ 2>/dev/null
– Analizar tráfico de red con Zeek (antes Bro) para detectar patrones de exfiltración:
zeek -r /path/to/pcap 'http' | grep -i "password\|credential\|token"
Conclusión
Esta semana dejó claro que los equipos de DevOps y seguridad deben priorizar tres frentes:
- Hardening de dispositivos de IoT/streaming: Los botnets como Popa no solo son un problema de consumidor final; pueden exponer redes corporativas si los dispositivos están mal aislados.
- Mitigación de fallos en herramientas de infraestructura: Config Connector es un ejemplo de cómo un componente crítico puede convertirse en un vector de takeover total. La ausencia de parche obliga a implementar controles compensatorios inmediatos.
- Detección de amenazas de larga duración: Velvet Ant demostró que los backdoors en PAM/OpenSSH y proxies modificados pueden operar durante años sin ser detectados. La clave está en monitorear integridad de archivos, tráfico interno y patrones de autenticación anómalos.
La tendencia es clara: los atacantes ya no buscan explotar vulnerabilidades en el perímetro, sino aprovechar permisos legítimos o integrarse en la cadena de suministro. Equipos de DevOps y seguridad deben adoptar un enfoque de «confianza cero por defecto», donde cada componente —desde un dispositivo de streaming hasta un módulo de Kubernetes— sea auditado y restringido según el principio de mínimo privilegio.
Fuentes
- SecurityWeek: In Other News: Apple Patches Beats Eavesdropping Flaw, DOT Closes Delta CrowdStrike Probe, AWS Continuum
- Malwarebytes: Android TV botnet Popa linked to Israeli firm
- Pulumi: GCP Config Connector Vulnerability Analysis