Una hipótesis
Similar al caso de varias empresas (la de las ventanas es la última), y el que se vean obligadas a colaborar con cualquier pedido para "facilitar futuros accesos que puedan ser solicitados" a sus servicios y productos, encontramos que los Linux comerciales que tienen sus empresas creadoras con sede en países que tienen leyes desfavorables para la privacidad de datos podrían estar igual, potencialmente backdoreados.
Muchos creen que no se puede, sin embargo se olvidan que quien controla la infraestructura de actualización de paquetes, controla qué se instala en el sistema operativo.
Los updates "oficiales" de los Linux comerciales se hacen contra un grupo de IPs puntuales, que son el front-end de una infraestructura mayor que brinda updates de paquetes a todo el mundo vía Internet.
En el caso de un Linux no comercial como Debian, los servidores de actualización pueden estar en cualquier IP y país. Si queremos que los updates se hagan eligiendo al azar servers de Brasil, China, Chile, Uruguay, etc. y solamente saltando entre esos servers, se puede hacer fácilmente.
De todos modos, al estar tan replicados los servers de update de Debian a nivel internacional sería muy difícil lograr ubicar un software de backdoor o alguna vulnerabilidad crítica en algun paquete de Debian, sin que eventualmente sea detectado. Como ya pasó antes:
En una infraestructura privada de update de paquetes las cosas son muy diferentes, cada una de las IP de front-end puede redirigir el tráfico hacia cualquier servidor interno de la infraestructura, que puede estar ubicado en cualquier país, inclusive esos que tienen "issues" con la privacidad últimamente, de hecho, muchas infraestructuras privadas de actualización están totalmente localizadas fronteras adentro de estos países con "issues".
Problemas posibles
Una infraestructura privada de actualización de paquetes va a tener problemas para desplegar un software de backdoor a nivel global, ¿cuales? el que casi seguramente dicho acto será detectado en algún momento, por varios motivos técnicos, pero si en cambio se ataca a un solo cliente, a unos cuantos servidores puntuales de entre millones, la chance de ser detectados por comparaciones y análisis - de paquetes, de fechas de update, de conexiones realizadas, de tráfico que atravesó la red en X cantidad, en X fecha, para X IPs hacia Y IPs para unos servers sí, pero para otros no, para una empresa sí, para otra empresa no, etc. - es mínima, casi nula inclusive.
El ataque dirigido
Es decir, tiene mucho más sentido un ataque dirigido, después de todo los Linux comerciales pueden efectivamente tener en algun lugar un código identificador únido (similar a un user id), y se lo puede emparejar con otros datos importantes: Nombre y ubicación del cliente*, IPs usuales desde donde se producen las conexiones a la infraestructura, etc.
* Al hablar de "cliente" aquí, me estoy refiriendo a "Empresa SRL", "Banco de la Región SA", "Ministerio de lo Quesea de la Pcia. de LoQueSea", "Subsecretaría de LoQuesesa", "Administración Federal de Manejo de lo Quesea", etc. y sus datos puntuales: dirección y código postal, teléfono, datos de contacto con el cliente (telefóno directo de un contacto, mail del contacto, horarios de disponibilidad), etc.
[Las IPs de origen de las conexiones suelen ser estáticas, por ser servidores. De todos modos, un identificador único va a permitir asociar un server/workstation que se conecta desde una conexión dinámica a los datos de un cliente específico, por cierto.]
Si se apunta a un cliente específico a backdorear, cuando el cliente se conecta para actualizar su instalación, es redireccionado a un server "especial" de actualización, donde el primer paquete que va a pedir actualizar va a ser el mismo cliente de actualización. Luego de terminar de instalar el nuevo cliente de actualización, este ya contiene un poco del código necesario para hacer que aunque se descargue un software X y sus chequeos de integridad fallen, igualmente se instale, sin informar de ninguna manera al cliente (sin dejar rastros de los fallos de chequeos de integridad de los paquetes a nivel de logs, etc.etc.). Y un componente más: la posibilidad de bajar e instalar un paquete transparentemente, sin que dicha descarga/instalación sea visible de cualquier manera para el usuario, y sin que quede tampoco registro alguno de esa tarea a nivel de logs o interfaces gráficas.
En criollo, el usuario no se va a dar cuenta de nada, a menos que esté monitoreando directamente lo que hay en la memoria del sistema operativo, los procesos activos y al mismo tiempo el tráfico de red, justo en el momento que supuestamente se descarga e instala 2 mb de paquetes (y ocupan 4 mb en storage local), pero en realidad bajan 2.4 mb (y en realidad ocupan 6 mb en storage local).
En criollo, el usuario no se va a dar cuenta de nada, a menos que esté monitoreando directamente lo que hay en la memoria del sistema operativo, los procesos activos y al mismo tiempo el tráfico de red, justo en el momento que supuestamente se descarga e instala 2 mb de paquetes (y ocupan 4 mb en storage local), pero en realidad bajan 2.4 mb (y en realidad ocupan 6 mb en storage local).
Luego de esto, en la siguiente actualización (que va a ser disparada casi de inmediato, o quedará scheduleada para la siguiente iteración de actualizaciones), si este cliente target se conecta, no accederá a ningun servidor estándar de la infraestructura de actualización (que contiene paquetes libres de todo backdoor), sino a un servidor "especial" que puede llegar a contener "actualizaciones" que serán instaladas transparentemente sobre las versiones actuales, inclusive sin llegar a modificar las versiones del software que se puede ver desde las herramientas estándares. Esas "actualizaciones" pueden contener el software que sea, desde un backdoor que habilite un servicio "fantasma" con SSH corriendo en un puerto alternativo (no el 22), hasta un túnel HTTP, DNS, o de cualquier protocolo que tenga comunicación a Internet.
El trabajo
Desde ese punto lograr la comunicación desde Internet hasta dentro del server es trivial y los métodos son comunes: port knocking, que el backdoor solo responda si hay intentos de conexión desde un rango de IPs específico (esto evitaría esos servicios "fantasma" sean visibles para escáneres como Nmap y similares), que los servicios "fantasma" solo se activen (sean arrancados y se carguen a memoria), en un rango horario limitado (de 4 a 5 de la mañana), cada X cantidad de días, y solo si encuentran una respuesta en servers de C&C (comando y control), prosigan con más actividades, etc. etc.
La transferencia - masiva si es necesario - de datos salientes se gestiona igualmente por métodos comunes: en gral. se va a buscar algún protocolo encriptado que tenga tráfico saliente y se lo va a usar, para evitar que los dispositivos de threat management que puedan estar inspeccionando el tráfico de protocolos encriptados, se suele recurrir a técnicas diversas (en gral. esteganografía en lo que haya "en movimiento" en el tráfico: audio, video, documentos, etc.). Eso claro, si es que los mismos dispositivos de threat management no tiene backdoors intercontruídos que simplemente se accedan y permitan desactivar contramedidas y detecciones varias, antes de iniciar el tráfico de datos saliente masivo.
Si hace falta, la transmisión de datos masiva - GBs de datos - se puede realizar por etapas o aleatoriamente, enviando unos pocos GBs de datos de a poco, durante días o semanas, hasta completar el trabajo.
Si el grado de securización de la infraestructura es bajo y/o manejable, ello inclusive podría llegar a acelerar los tiempos prescindiendo de diversas tareas de ocultamiento y prevención de detecciones.
Si hace falta, la transmisión de datos masiva - GBs de datos - se puede realizar por etapas o aleatoriamente, enviando unos pocos GBs de datos de a poco, durante días o semanas, hasta completar el trabajo.
Si el grado de securización de la infraestructura es bajo y/o manejable, ello inclusive podría llegar a acelerar los tiempos prescindiendo de diversas tareas de ocultamiento y prevención de detecciones.
La despedida
Una vez terminado el interés en el objetivo, la misma infraestructura de actualización puede fácilmente devolver a los paquetes instalados a su estado anterior, y dejar efectivamente cero rastro de la intrusión dentro del server. A lo sumo, el tráfico saliente - y en protocolos y puertos totalmente autorizados a hacerlo - del server es lo único podría permitir pinpointear una intrusión de este tipo, luego de eliminado todo rastro de los binarios que la permitieron.
Luego de esto, al revisar el server no se va a detectar ninguna diferencia entre los binarios instalados y los oficiales, son los mismos.
El trabajo puede durar desde pocos minutos a varias semanas, inclusive intercalando ataques con períodos "limpios", offline, donde los servers atacados son limpiados y devueltos a su estado original, para luego ser atacados de vuelta.
El trabajo puede durar desde pocos minutos a varias semanas, inclusive intercalando ataques con períodos "limpios", offline, donde los servers atacados son limpiados y devueltos a su estado original, para luego ser atacados de vuelta.
Contramedidas?
Si hubiera otro tipo de medidas de seguridad para prevenir el uso de binarios alterados, un HIDS (HostIDS), fácilmente podría ser pinpointeado por un componente de software "fantasma" antes de instalar nada más que el update del cliente de actualización que arrancara totalmente autorizado (y no va a disparar ninguna alarma porque es una versión nueva justamente, y es esperable que los nuevos binarios en disco disparen alarmas en el HIDS, que rápidamente van a ser descartadas como "falsas alarmas", si que directamente ya no hay reglas que impiden que el HIDS dispare alarmas cuando se actualiza el cliente de actualización), y luego efectivamente desactivado, inclusive para ello hiciera falta "actualizar" los binarios y librerías del HIDS.
Conclusiones
Es decir, quien controla la infraestructura de actualización y además cuando los servidores de actualización son privados, y no hay acceso público o semipúblico que permita controlar qué hay en esos repositorios en cualquier momento y además controla el código fuente del cliente de actualización, está en perfecta posición para montar una infraestructura de backdoring y troyanización perfectamente efectiva, pudiendo entrar, instalar, borrar y luego salir de cualquier server conectado a Internet, sin que los administradores (de sistemas, redes, seguridad, etc.), a cargo de los servidores lleguen a darse cuenta siquiera de que hubo algún acceso no autorizado.
No hay comentarios:
Publicar un comentario