Intrusión con una puerta trasera incrustada en otra puerta trasera — otro dominio de $20, más gobiernos

 (labs.watchtowr.com)
1 puntos por GN⁺ 2025-01-13 | 1 comentarios | Compartir por WhatsApp
  • watchTowr Labs volvió a registrar dominios vencidos y abandonados para interceptar callbacks de puertas traseras dentro de webshells, y observó tráfico reportado por más de 4,000 puertas traseras activas y únicas
  • Si una webshell tiene una función oculta que envía su ubicación de despliegue o contraseña al dominio del autor original, tras el vencimiento del dominio el nuevo propietario puede recibir los logs de callback
  • Entre los objetivos observados hubo sistemas gubernamentales de Bangladesh, China y Nigeria, así como universidades e instituciones de educación superior de Thailand, China y South Korea, y los logs acumularon más de 300 MB
  • Tras registrar más de 40 dominios, los investigadores configuraron AWS Route53, certificados TLS wildcard y un servidor Apache de registro, registraron las solicitudes y devolvieron solo respuestas 404
  • La infraestructura abandonada puede convertirse en una ruta de acceso real no solo para la validación TLS/SSL CA, sino también dentro del ecosistema de webshells usado por atacantes, y The Shadowserver Foundation asumirá los dominios relacionados para tratarlos como sinkhole

La infraestructura vencida se convierte en ruta de acceso para puertas traseras

  • En su investigación de .MOBI de 2024, watchTowr Labs mostró que los dominios no registrados podían afectar el proceso de validación de propiedad de dominio de las TLS/SSL CA, y luego Google pidió al CAB Forum eliminar la validación de propiedad basada en WHOIS
  • Esta vez, la investigación aplica la misma clase de problema, infraestructura vencida y abandonada, al ecosistema de webshells y puertas traseras
  • Los investigadores volvieron a registrar dominios vencidos de los que dependía otra puerta trasera incluida dentro de una puerta trasera, para observar el tráfico enviado por hosts infectados
  • En teoría, este método podría crear una posición desde la cual tomar y controlar hosts comprometidos, pero los investigadores ofuscaron la mayoría de los nombres de host para no generar riesgos adicionales para los sistemas
  • Hasta ahora se han observado más de 4,000 puertas traseras activas y únicas, y la cifra sigue aumentando

Las webshells son mecanismos de control remoto dejados tras una intrusión

  • Una webshell es código desplegado tras comprometer un servidor web, y funciona como una puerta trasera que permite al atacante realizar acciones posteriores
  • Una forma simple es código en PHP como <?php system($_GET['exec']);?>, que ejecuta comandos
  • Entre las formas más complejas están webshells como c99shell, r57shell y China Chopper, que pueden incluir funciones como:
    • ejecución de comandos
    • borrado, modificación, carga, movimiento y cambio de nombre de archivos
    • ejecución de código
    • autoeliminación
    • despliegue de puertas traseras adicionales como connect-back y bindshell
    • fuerza bruta por FTP
    • cliente SQL
  • c99shell y r57shell se presentan como webshells de uso ampliamente extendido en el pasado

La ubicación se filtra hacia el creador de la webshell

  • r57shell incluía código para cargar una imagen de 0 bytes desde rst.void.ru, y en apariencia parecía enviar información sobre la versión actual del shell
  • En realidad, la ubicación de la webshell recién desplegada quedaba expuesta al propietario de rst.void.ru mediante el encabezado Referer de la solicitud HTTP
  • Es decir, aunque el atacante comprometiera un objetivo e instalara la webshell, el creador de la webshell podía recibir esa ubicación
  • En el caso de c99shell, las credenciales están hardcodeadas, pero la llamada @extract($_REQUEST["c99shcook"]) puede sobrescribir variables del alcance actual
  • extract no es seguro con datos no confiables, y un atacante puede poner valores md5_pass y login en el parámetro de solicitud c99shcook para reemplazar las variables de autenticación existentes y pasar la validación

Más de 40 dominios para registrar solo callbacks

  • Los investigadores reunieron webshells de varios lenguajes, objetivos y antigüedades, desofuscaron código oculto con base64 y otros métodos, y extrajeron dominios no registrados que parecían usarse para callbacks
  • Luego registraron en masa más de 40 dominios mediante la API de AWS Route53
  • Entre los dominios de ejemplo están aljazeera7.com, alturks.com, caspian-pirates.org, h0ld-up.info, w2img.com, odayexp.com y nettekiadres.com
  • Configuraron certificados TLS wildcard y un servidor web Apache, y apuntaron los nuevos dominios al servidor de registro
  • El servidor de registro solo guardó las solicitudes entrantes y devolvió 404; los investigadores recibieron únicamente las solicitudes enviadas de forma voluntaria por los sistemas y no respondieron de forma que ejecutara código

Callbacks de webshells que parecen herramientas de Lazarus

  • Se observaron miles de solicitudes para obtener imágenes .gif hacia dominios de la familia w2img.com
  • Los investigadores encontraron una muestra de puerta trasera que generaba esas solicitudes y concluyeron que era similar a una versión atribuida al uso de Lazarus en 2020
  • Al eliminar la ofuscación, aparece código con la forma background:url(...) de CSS que carga un archivo .gif desde img2.w2img.com
  • Cuando el navegador solicita la imagen, el log del servidor guarda la solicitud junto con el Referer, lo que permite conocer la ubicación donde se desplegó la webshell
  • Solo esta puerta trasera permitió observar más de 3,900 dominios comprometidos únicos
  • Los navegadores modernos ahora exponen solo el dominio en el Referer, pero hubo casos de atacantes con navegadores antiguos que enviaron la URL completa de la webshell

También aparecen dominios gubernamentales e instituciones de educación superior

  • Al buscar dominios .gov en los Referer de los logs, aparecieron varios dominios relacionados con gobiernos
  • Los ejemplos confirmados son:
    • fhc.gov.ng: Nigeria Federal High Court
    • dominios bajo gov.cn
    • dominios bajo gov.bd
    • dominios bajo court.gov.cn
  • En el caso de Nigeria Federal High Court, cuatro puertas traseras distintas enviaron información, y cada una apuntaba a un dominio diferente que recibía las solicitudes
  • Los investigadores resumen que, entre los más de 4,000 sistemas comprometidos, cuatro sistemas .gov estaban involucrados
  • También se observaron como objetivos comprometidos universidades e instituciones de educación superior de Thailand, China y South Korea

Webshells que envían contraseñas en texto plano

  • Otro tipo de puerta trasera no depende de la carga de imágenes ni del Referer, sino que envía directamente la URL y cierta información como parámetros
  • Las solicitudes dirigidas a odayexp.com incluían un parámetro url junto con un parámetro p
  • En el código de la webshell ASP, el valor p correspondía a la variable UserPass, es decir, la contraseña necesaria para iniciar sesión en la webshell
  • El atacante protegió la webshell con una contraseña, pero esa contraseña se transmitía en texto plano a odayexp.com
  • Cuando watchTowr obtuvo la propiedad de ese dominio, la ubicación de la webshell y la contraseña comenzaron a enviarse al servidor de registro de los investigadores
  • En los logs también quedaron solicitudes con localhost, IP privadas y rutas de prueba, lo que sugiere rastros de alguien modificando o probando esa función

Límites de interpretación y pasos posteriores

  • Las shells observadas estaban sesgadas hacia objetivos en China, pero los investigadores creen que esto podría reflejar los datos de muestra
  • Las IP de origen son poco fiables como evidencia porque es fácil usar proxies, pero las solicitudes que parecían tráfico de atacantes o tráfico con una administración inusual mostraban un fuerte sesgo hacia rangos IP de Hong Kong y China
  • El uso de webshells abiertas, dominios vencidos y software con puertas traseras incrustadas muestra que los atacantes también cometen errores, igual que los defensores
  • Igual que en la investigación previa sobre .MOBI, si los dominios vuelven a vencer el mismo problema puede repetirse, así que sigue habiendo una cuestión de responsabilidad
  • The Shadowserver Foundation asumirá los dominios relacionados con esta investigación para tratarlos como sinkhole

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-01-13
Opiniones en Hacker News

  • No me animaría a intentarlo directamente por miedo a la CFAA, pero este trabajo es genial. En especial me da risa que un dominio gubernamental tuviera 4 backdoors parasitarios pegados
    Me pregunto si los script kiddies, cuando toman control de un sistema, no borran los backdoors de otros script kiddies para quedárselo en exclusiva
    Ojalá entre todos dejáramos de usar expresiones como “comprar” o “poseer” para los dominios. “Arrendar” o “alquilar” es más correcto, y si fuera algo que realmente se pudiera comprar, no habría vuelto a quedar disponible como pasó aquí

    • En este contexto, tampoco queda claro qué significa exactamente “comprar”. Incluso es difícil decir que un país “posee” su propio ccTLD, aunque ICANN ha elaborado con bastante cuidado una política de que “los ccTLD deben tratarse como si pertenecieran al país correspondiente” para evitar tensiones en el espacio de nombres de Internet
      Por eso, la mayoría de las reglas de los gTLD no se aplican a los ccTLD. Puede decirse que un país lo “posee” solo en el sentido de que podría defender con fuerza militar el uso de su ccTLD si ICANN o los servidores de root-servers.net dejaran de resolver correctamente el TLD
    • Visto de una forma muy oblicua, toda propiedad física y digital también podría considerarse arrendada
    • Es la naturaleza humana y una “función” del inglés. La gente dice “mi auto” o “mi número” aunque el auto esté en leasing o el número telefónico sea asignado, y dice “mi casa” aunque tenga una hipoteca casi sin capital propio
      Es una abreviación conceptual en la que la realidad incómoda se da por sentada o se considera irrelevante para el punto

  • El artículo me pareció realmente bueno. Se lee con ligereza, pero es consciente del impacto que podría tener publicarlo; todo está fundamentado y, aun así, no se toma a sí mismo con demasiada solemnidad
    Es entretenido de leer y al mismo tiempo trata bien un problema de seguridad serio

    • Sentí lo mismo con este artículo y con el anterior sobre .mobi. Tiene suficiente contexto, buenas explicaciones, es ligero y cool sin abusar de palabras de moda ni esforzarse por parecerlo
      El contenido es sólido y va al grano, algo refrescante frente a muchos posts de blogs o análisis de seguridad que suelen fallar en esos puntos
    • También me gustó que apareciera WordArt, aunque me decepcionó que no usaran el efecto arcoíris

  • Me da curiosidad qué pasaría si se aprovechara este backdoor de web shell en sentido inverso para borrar el web shell

  • No sé si entendí bien esta parte. Se explica que el CSS hace que se cargue una imagen de fondo desde una URL específica, por lo que el navegador solicita un archivo .gif de w2img.com, y también que los navegadores recientes solo exponen el dominio en el referente, pero que un atacante con un navegador antiguo enviaba la URL completa del shell
    Pero eso de que “el atacante usa un navegador antiguo” me suena raro. En principio, el atacante controlaba el servidor que servía el CSS, y el navegador era el de un usuario inocente que visitaba el servidor comprometido, ¿no? Entonces quien usa el navegador sería la víctima, no el atacante
    No entiendo en qué situación el atacante está usando un navegador

    • Un web shell es una página, normalmente un archivo .php, que el atacante sube a un sitio después de una intrusión como RCE, y luego el atacante abre esa página con su propio navegador para realizar más acciones en el servidor web comprometido
      Pero estos archivos de web shell prefabricados fueron hechos por otros atacantes y se distribuyen con un backdoor ya implantado. En este caso, el CSS dentro del web shell hace que el navegador del atacante filtre la ubicación del web shell a un dominio controlado por el autor original

  • Cambiando un poco de tema, no entiendo por qué la tipografía de la letra y en este artículo se ve así. Resalta demasiado y molesta a la vista

    • Este tipo de cosas me molestan bastante seguido, así que desactivé downloadable_fonts. Considero que la web es un lugar para leer textos, así que no me agradan las fuentes personalizadas que perjudican la legibilidad
      Entiendo que un diseñador quiera un estilo distintivo, pero como usuario final rara vez quiero eso
    • El diseño de la fuente es así: https://abcdinamo.com/typefaces/favorit
    • Creo que algunas tipografías incluyen deliberadamente elementos así para tener rasgos distintivos. El mercado de fuentes está muy saturado, así que puede ayudar a destacar entre copias muy parecidas
      Puede que la intención sea que la parte llamativa resulte un poco molesta, pero, como una declaración polémica, igual tiene que tener cierto sentido. Me recuerda a la estrategia de algunas figuras de Internet que pronuncian mal ciertas palabras de forma deliberada una y otra vez, o exageran su entonación
      Volviendo a las fuentes, recuerdo que el sitio de letras Genius usó algo parecido durante un tiempo. En su etapa de consolidación usaba las formas cuadradas de la tipografía Programme, que pueden verse en el enlace de abajo. Todavía usa Programme, pero desde hace un tiempo parece usar las formas normales, probablemente porque realmente molestaban y afectaban la legibilidad
      https://www.typewolf.com/programme

  • Hay algunos errores tipográficos en el artículo. En “with the hopes of painting a paint a clear picture”, a paint sobra, y en “we the following stood out”, we sobra
    Además, “Atleast” en “Atleast there will be memes...” también es un error

  • Ver la mención de h0no me trajo recuerdos de golpe. Se siente como volver a los tiempos de darpanet/m00/#darknet/dikline

  • Me pregunto por qué ocultaron casi todos los dominios, pero dejaron visible el dominio de Federal High Court of Nigeria
    Aunque no se indique explícitamente, espero que hayan seguido un proceso de divulgación responsable

  • Parece que el 99% se basa en apoderarse de dominios vencidos, ¿pero no dijeron nada sobre cómo lo hicieron?

    • No sé si realmente leíste el artículo. Está explicado con bastante detalle. No “secuestraron” registros DNS; compraron dominios que habían vencido y volvieron a estar disponibles
      La única parte que no explicaron es cómo encontraron shells en línea, y eso tiene razones obvias: como dicen los autores, eran cosas que “se cayeron de la parte trasera de un camión”