Superficies de ataque no convencionales

Superficies de ataque no convencionales

Una superficie de ataque es el nombre que se le da a todos los activos atacables propiedad de una organización que podrían proporcionar acceso a redes internas o información confidencial si se vieran comprometidos.
Las organizaciones a menudo se enfocan en activos convencionales como dominios, subdominios, direcciones IP y rangos de IP cuando administran su superficie de ataque porque estos son relativamente fáciles de monitorear y rastrear.
Sin embargo, los tipos no convencionales de superficie de ataque a menudo se pasan por alto. Los activos de superficie de ataque no convencionales normalmente no estarían dentro del alcance de una prueba de penetración estándar ni se incluirían en sus listas de activos, pero pueden brindarle información a un atacante o incluso llevarlo a establecerse. Son cosas como repositorios públicos de GitHub y anuncios de trabajo.

La Información es poder
Tradicionalmente, los equipos de seguridad se centran en las vulnerabilidades convencionales, pero los activos no convencionales también pueden ser peligrosos. Si, por ejemplo, un atacante puede ver una lista de trabajos para un especialista interno en seguridad cibernética y ve que el rol requiere competencia en un determinado producto EDR, el atacante puede obtener una visión útil inmediata de su entorno sin enviar ningún tráfico a o activar cualquier defensa en absoluto.
Nuestro equipo de administración de superficies de ataque ha descrito varios ejemplos de superficies de ataque no convencionales que han visto en su trabajo diario.

Ejemplo 1: Postman
La plataforma Postman se utiliza para desarrollar y crear API, lo que se puede hacer de forma colaborativa.
Los espacios de trabajo están configurados como privados de forma predeterminada, lo que significa que
solo el propietario y los usuarios seleccionados específicamente pueden acceder al espacio de trabajo y a la información que contiene. Sin embargo, los usuarios pueden hacer públicos sus espacios de trabajo. Si lo hacen, la información como las claves API, los nombres de usuario y las contraseñas quedan expuestas y accesibles a través de Internet.
Katie Inns, consultora de seguridad en nuestro equipo de administración de superficie de ataque, nos contó cómo aprovechó una instancia de este tipo de exposición pública cuando trabajaba con un cliente.

“Un empleado al que llamaremos ‘Tom’ estaba desarrollando una nueva API con su equipo global, usando Postman para colaborar en el proyecto. Tom tenía una fecha límite difícil y no estaba pensando realmente en la seguridad, por lo que configuró su espacio de trabajo como público para que todos los miembros del equipo pudieran acceder a él. Como resultado, se divulgó mucha información en Internet. Encontramos un nombre de usuario y una contraseña, y teníamos el presentimiento de que estas
credenciales se usarían en otras aplicaciones. Probamos los inicios de sesión e inicialmente no eran válidos, pero luego incrementamos el número al final de la contraseña en dos (porque habían pasado dos meses desde que se divulgaron estas credenciales), y funcionaron. Así de fácil, teníamos
acceso a las aplicaciones internas del cliente”.

Katie Inns

consultora en seguridad

Katie encontró el espacio de trabajo de Postman simplemente buscándolo con una consulta de Google, ingresando site:www.postman.com “contraseña” . Puede incluir cualquier otra palabra clave relevante en una búsqueda como esta, como APIkey, nombre de usuario o el nombre de la empresa.

A largo plazo, le recomendamos que considere no utilizar herramientas externas para el desarrollo y, en su lugar, utilice soluciones internas para la colaboración.

Ejemplo 2: formateadores de código
Los profesionales de la seguridad a menudo hablan de no poner datos confidenciales en sitios web externos, porque nunca se sabe dónde terminarán.
Nuestro equipo compartió parte de la información que encontraron en el pasado simplemente buscando en los lugares correctos. Por ejemplo, los analistas de seguridad, los desarrolladores y los empleados de la mesa de servicio que usan servicios populares como formateadores y convertidores de código a menudo ingresan información confidencial, pero cuando se guarda, está disponible para ser detectada por Google Crawlers y puede indexarse en el motor de Google.
Los miembros de nuestro equipo han encontrado información de nómina, salidas del administrador de contraseñas y credenciales que se han hecho públicas por error de esta manera.
Para remediar los casos en los que la información se ha expuesto involuntariamente, recomendamos eliminar la información confidencial que se haya divulgado, hacer que los repositorios y los espacios de trabajo sean privados, y asumir que las credenciales están comprometidas y reciclarlas regularmente.

Ejemplo 3: trabajo remoto y VPN
Jake Knott, consultor de seguridad de nuestro equipo de administración de superficie de ataque, está acostumbrado a encontrar puntos finales mal configurados al evaluar los entornos de los clientes. Sin embargo, recientemente encontró indicadores de activos de clientes que aparecen en lugares inesperados.

“Uno de nuestros clientes tiene su sede en el Reino Unido, pero encontramos terminales de su entorno en India, Hong Kong y España. Era inusual, y finalmente nos dimos cuenta de que estaba siendo causado por
trabajadores remotos, que trabajaban en esos países y estaban expuestos
en su banda ancha residencial.
Debido a que estas exposiciones fueron causadas por el trabajo remoto, cuando hicimos un escaneo en Internet durante el horario laboral del Reino Unido, obtuvimos resultados muy diferentes a los escaneos realizados en otros momentos.
Encontramos puntos finales mal configurados que no restringían el protocolo de escritorio remoto (RDP). Encontramos empleados que usaban software VPN gratuito que exponía sus activos corporativos en lugares extraños como Panamá. También vimos dispositivos personales a bordo que no se habían sometido a controles de seguridad”.

Jake Knott

Consultor de seguridad

Poniendo todo junto
Cada uno de los tres ejemplos descritos anteriormente es problemático, pero considere un escenario donde algunas o todas estas exposiciones existen en una organización.
Guión
Tom todavía usa su espacio de trabajo público en Postman para desarrollar su API. Sus credenciales de dominio están expuestas a través de Postman, al igual que su RDP a través de su banda ancha residencial.
Un atacante puede usar las credenciales que se encuentran en Postman para autenticar una sesión RDP, obteniendo acceso a la red corporativa de Tom y la información confidencial que contiene.
Recomendaciones
Para evitar un escenario como el descrito anteriormente, le recomendamos que bloquee el RDP solo en rangos internos y controle el RDP entrante desde rangos no corporativos, restrinja el uso de VPN gratuitas o soluciones de VPN de terceros y desarrolle estándares en torno al uso de dispositivos personales para el trabajo, incluido el requisito de endurecimiento para cualquier dispositivo que se conecte a la red.