Vías de compromiso

  • Artículo

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2 y Windows Server 2012.

Ley número siete: una red bien administrada es la más segura. - 10 leyes inmutables sobre la administración de seguridad

En las organizaciones que han experimentado eventos de vulneración catastróficos, las evaluaciones suelen revelar que tienen una visibilidad limitada del estado real de sus infraestructuras de TI, el cual puede diferir significativamente de sus estados "documentados". Estas variaciones presentan puntos débiles que exponen el entorno a vulneraciones, a menudo con poco riesgo de detección hasta que la vulneración ha progresado hasta el punto en el que los atacantes, en realidad, ya "poseen" el entorno.

Las evaluaciones detalladas de la configuración de AD DS, infraestructuras de clave pública (PKI), servidores, estaciones de trabajo, aplicaciones, listas de control de acceso (ACL) y otras tecnologías de estas organizaciones revelan configuraciones incorrectas y vulnerabilidades que, si se hubiesen corregido, podrían haber impedido la vulneración inicial.

El análisis de documentación, procesos y procedimientos de TI identifica vulnerabilidades que fueron introducidas debido a lagunas en las prácticas administrativas. Los atacantes sacaron provecho de ellas hasta llegar a obtener privilegios que se usaron para vulnerar completamente el bosque de Active Directory. Un bosque totalmente vulnerado es aquel en el que los atacantes ponen en peligro no solo sistemas, aplicaciones o cuentas de usuario individuales, sino que escalan su acceso hasta obtener un nivel de privilegio en el que pueden modificar o destruir todos los aspectos del bosque. Cuando se ha vulnerado una instalación de Active Directory hasta ese nivel, los atacantes pueden realizar cambios que les permitan mantener su presencia en todo el entorno, o peor, destruir el directorio y los sistemas y cuentas que administra.

Varias de las vulnerabilidades habitualmente aprovechadas descritas a continuación no son ataques contra Active Directory, pero aun así permiten que los atacantes afiancen su presencia en un entorno que podrán usar para ejecutar ataques de escalado de privilegios (también denominado elevación de privilegios) y, finalmente, tomar como objetivo a AD DS y provocar una vulneración.

Esta sección de este documento se centra en describir los mecanismos que suelen usar los atacantes para obtener acceso a la infraestructura y, finalmente, iniciar ataques de elevación de privilegios. Vea también las secciones siguientes:

Nota

Aunque este documento se centra en los sistemas Active Directory y Windows que forman parte de un dominio de AD DS, los atacantes rara vez se centran únicamente en Active Directory y Windows. En entornos con una combinación de sistemas operativos, directorios, aplicaciones y repositorios de datos, es habitual que los sistemas ajenos a Windows también se hayan vulnerado. Esto es especialmente cierto si los sistemas proporcionan un "puente" entre entornos de Windows y ajenos a él, como servidores de archivos a los que acceden los clientes de Windows y UNIX o Linux, directorios que proporcionan servicios de autenticación a varios sistemas operativos o metadirectorios que sincronizan datos entre directorios dispares.

Se toma AD DS como objetivo debido a las funcionalidades centralizadas de administración de acceso y configuración que proporciona no solo a los sistemas Windows, sino a otros clientes. Cualquier otro directorio o aplicación que proporcione servicios de administración de autenticación y configuración puede y será objeto de atacantes dedicados. Este documento se centra en las protecciones que pueden reducir la probabilidad de que las instalaciones de Active Directory se vulneren, pero todas las organizaciones que incluyan equipos, directorios, aplicaciones o repositorios de datos ajenos a Windows también se deben preparar para ataques contra esos sistemas.

Objetivos de vulneración iniciales

Nadie crea intencionadamente una infraestructura de TI que exponga a la organización a una vulneración. Cuando se construye por primera vez un bosque de Active Directory, suele ser prístino y actual. A medida que pasan los años y se adquieren nuevos sistemas operativos y aplicaciones, estos se agregan al bosque. A medida que se reconocen las ventajas de administración que proporciona Active Directory, se agrega más contenido al directorio, más personas integran sus equipos o aplicaciones con AD DS, y los dominios se actualizan para admitir las nuevas funcionalidades que ofrecen las versiones más recientes del sistema operativo Windows. Pero lo que también sucede con el tiempo es que, aunque se agregue una infraestructura, nueva es posible que otras partes de la infraestructura no reciban un mantenimiento tan concienzudo como inicialmente; los sistemas y las aplicaciones funcionan correctamente y, por tanto, no reciben atención, y las organizaciones comienzan a olvidarse de que no han eliminado su infraestructura heredada. Según vemos en la evaluación de infraestructuras vulneradas, cuanto más antiguo, grande y complejo sea el entorno, más probable es que tenga numerosas instancias de vulnerabilidades habitualmente aprovechadas.

Independientemente de la motivación del atacante, la mayoría de las infracciones de seguridad de la información comienzan con la vulneración de uno o dos sistemas a la vez. Estos eventos iniciales, o puntos de entrada en la red, suelen aprovechar vulnerabilidades que podrían haberse corregido. El informe sobre investigaciones de vulneración de datos (DBIR) de 2012, un estudio anual producido por el equipo RISK de Verizon en cooperación con varias agencias de seguridad nacional y otras empresas, afirma que el 96 % de los ataques fueron "no muy difíciles" y que "el 97 % de las infracciones podrían haberse evitado mediante controles simples o intermedios". Estos hallazgos podrían ser consecuencia directa de las vulnerabilidades aprovechadas habitualmente, descritas a continuación.

Lagunas en la implementación de antivirus y antimalware

Ley número ocho: un escáner de malware obsoleto es solo mínimamente mejor que ningún escáner en absoluto. - Diez leyes inmutables sobre la seguridad (versión 2.0)

El análisis de las implementaciones de antivirus y antimalware de las organizaciones suele revelar que la mayoría de las estaciones de trabajo del entorno están configuradas con software antivirus y antimalware habilitado y actual. Las excepciones suelen ser estaciones de trabajo que se conectan con poca frecuencia al entorno corporativo o dispositivos de empleados en los que puede resultar complicado implementar, configurar y actualizar software antivirus y antimalware.

Las poblaciones de servidores, por otra parte, tienden a tener una protección menos constante en muchos entornos vulnerados. Como se informó en las investigaciones de vulneración de datos de 2012, el 94 % de las vulneraciones estuvieron relacionadas con servidores, lo que representa un aumento del 18 % respecto al año anterior. El 69 % de los ataques incorporaron malware. No es inusual que las instalaciones de antivirus y antimalware de poblaciones de servidores estén configuradas incoherentemente, obsoletas, mal configuradas o incluso deshabilitadas. En algunos casos, es el personal administrativo quien deshabilita el software antivirus y antimalware; en otros, los atacantes deshabilitan el software después de vulnerar un servidor a través de otras vulnerabilidades. En cuanto el software antivirus y antimalware está deshabilitado, los atacantes infiltran malware en el servidor y se centran en propagar el riesgo a lo largo de la población de servidores.

Asegurarse de que los sistemas disponen de una protección contra malware actual y exhaustiva no es el único paso importante. También lo es supervisar los sistemas para vigilar que el software antivirus y antimalware no se haya deshabilitado o eliminado, además de reiniciar la protección automáticamente cuando se deshabilita de forma manual. Ningún software antivirus y antimalware puede garantizar la prevención y detección de la totalidad de las infecciones, pero una protección antivirus y antimalware correctamente configurada e implementada puede reducir la probabilidad de infección.

Aplicación de revisiones incompleta

Ley número tres: si no se mantiene al día con las correcciones de seguridad, la red no tardará en dejar de ser suya. - 10 leyes inmutables sobre la administración de seguridad

Microsoft publica boletines de seguridad el segundo martes de cada mes, aunque en ocasiones extraordinarias se publican actualizaciones de seguridad entre boletines (también conocidas como actualizaciones "fuera de banda") cuando se determina que la vulnerabilidad supone un riesgo urgente para los sistemas de los clientes. Muchos clientes revisan sus infraestructuras de Windows con relativa diligencia, ya sea una pequeña empresa que configura sus equipos Windows para que administren las revisiones del sistema y aplicaciones con Windows Update o una gran organización que usa software de administración como Microsoft Endpoint Configuration Manager para implementar las revisiones según planes jerárquicos detallados.

Pero pocas infraestructuras incluyen solo equipos Windows y aplicaciones de Microsoft. Debido a esto, en entornos vulnerados es habitual encontrar lagunas en la estrategia de administración de revisiones de la organización. En los sistemas Windows de estos entornos, las revisiones no se aplican uniformemente. Los sistemas operativos ajenos a Windows no reciben revisiones o las reciben esporádicamente. Las aplicaciones comerciales listas para usar (COTS) contienen vulnerabilidades para las que existen revisiones, pero no se han aplicado. Los dispositivos de red suelen estar configurados con las credenciales predeterminadas de fábrica y sin actualizaciones de firmware años después de su instalación. A menudo, las aplicaciones y sistemas operativos que ya no reciben asistencia técnica de sus proveedores se siguen ejecutando, a pesar de que ya no se les pueden aplicar revisiones contra vulnerabilidades. Cada uno de estos sistemas no revisados representa otro posible punto de entrada para los atacantes.

Ahora que la TI se orienta más hacia el consumidor, se han introducido desafíos adicionales. Los empleados utilizan sus propios dispositivos para acceder a datos corporativos, por lo que es posible que la organización tenga poco o ningún control sobre la aplicación de revisiones y la configuración de dichos dispositivos. Normalmente, el hardware de clase empresarial se suministra con opciones de configuración y funcionalidades de administración listas para la empresa, a costa de menos elección en la personalización individual y la selección de dispositivos. El hardware centrado en los empleados ofrece una gama más amplia de fabricantes, proveedores, características de seguridad de hardware y software, funcionalidades de administración y opciones de configuración, y muchas características empresariales pueden incluso estar ausentes.

Software de aplicación de revisiones y administración de amenazas y vulnerabilidades

Si se ha implementado un sistema de administración de revisiones eficaz para los sistemas Windows y las aplicaciones de Microsoft, se habrá reducido parte de la superficie expuesta a ataques que generan las vulnerabilidades sin revisar. Sin embargo, a menos que los sistemas ajenos a Windows, las aplicaciones ajenas a Microsoft, la infraestructura de red y los dispositivos de los empleados también se mantengan actualizados con revisiones y otras correcciones, la infraestructura seguirá siendo vulnerable. En algunos casos, el proveedor de una aplicación puede ofrecer funcionalidades de actualización automática; en otros, se necesitará diseñar un método para obtener y aplicar periódicamente revisiones y otras correcciones.

Aplicaciones y sistemas operativos obsoletos

"No puedes esperar que un sistema operativo de hace seis años te proteja contra un ataque de hace seis meses". - Profesional de seguridad de la información con 10 años de experiencia en la protección de instalaciones empresariales

"Obtén lo actual, mantente actual" puede sonar a eslogan publicitario, pero las aplicaciones y sistemas operativos obsoletos crean riesgos en las infraestructuras de TI de muchas organizaciones. Un sistema operativo que se haya publicado en 2003 podría seguir recibiendo asistencia técnica del proveedor y actualizaciones para solucionar vulnerabilidades, pero es posible que no contenga ciertas características de seguridad que hayan sido añadidas en sus versiones más recientes. Los sistemas obsoletos podrían incluso requerir que ciertas configuraciones de seguridad de AD DS se debiliten para ser compatibles con sus inferiores capacidades.

Hay aplicaciones que se han escrito para que usen protocolos de autenticación heredados y que ya no reciben asistencia técnica de sus proveedores. Normalmente, estas aplicaciones no se pueden readaptar para que sean compatibles con mecanismos de autenticación más seguros. Aun así, es posible configurar el dominio de Active Directory de una organización para que almacene hashes de LAN Manager o contraseñas con cifrado reversible para que sea compatible con dichas aplicaciones. Las aplicaciones escritas antes de la introducción de sistemas operativos más recientes podrían no funcionar o no hacerlo correctamente en sistemas operativos actuales. Esto requiere que las organizaciones mantengan sistemas cada vez más antiguos y, en algunos casos, hardware y software sin ningún tipo de asistencia técnica.

Incluso cuando las organizaciones han actualizado sus controladores de dominio a Windows Server 2012, Windows Server 2008 R2 o Windows Server 2008, es habitual encontrar partes significativas de la población de servidores miembro que ejecuten Windows Server 2003, Windows 2000 Server o Windows NT Server 4.0 (que ya no reciben ningún tipo de asistencia técnica). Cuanto más tiempo mantenga sistemas antiguos una organización, mayor será la disparidad entre conjuntos de características y más probable será que los sistemas de producción no sean compatibles. Además, cuanto más tiempo se mantiene un bosque de Active Directory, más se observa que las aplicaciones y sistemas heredados no se encuentran en los planes de actualización. Esto puede significar que un único equipo que ejecute una sola aplicación podría introducir vulnerabilidades en todo el dominio o bosque, ya que Active Directory está configurado para ser compatible con sus protocolos y mecanismos de autenticación heredados.

Para eliminar las aplicaciones y sistemas heredados, primero debe centrarse en identificarlos y catalogarlos y, a continuación, determinar si desea actualizar o reemplazar la aplicación o el host. Aunque pueda ser difícil encontrar reemplazos para aplicaciones altamente especializadas para las que no existe asistencia técnica ni ruta de actualización, es posible que pueda aprovechar un concepto denominado "destrucción creativa" para reemplazar la aplicación heredada por una nueva que proporcione la funcionalidad necesaria. La preparación ante vulneraciones se describe más a fondo en la sección "Preparación ante vulneraciones", más adelante en este documento.

Error de configuración

Ley número cuatro: no es muy útil instalar correcciones de seguridad en un equipo que nunca haya sido asegurado. - 10 leyes inmutables sobre la administración de seguridad

Incluso en entornos en los que los sistemas se mantienen actualizados y revisados, se suelen identificar lagunas o configuraciones incorrectas en el sistema operativo, las aplicaciones que se ejecutan en equipos y Active Directory. Algunas configuraciones incorrectas exponen solo el equipo local a vulneraciones, pero en cuanto adquieran la "propiedad" de un equipo, los atacantes suelen centrarse en propagar aún más la vulneración a lo largo de otros sistemas y, finalmente, a Active Directory. A continuación se muestran algunas de las áreas habituales en las que se identifican configuraciones que introducen riesgos.

En Active Directory

Las cuentas de Active Directory a las que suelen dirigirse los atacantes son las que son miembros de los grupos con más privilegios, como los miembros de los administradores de dominio (DA), administradores de empresa (EA) o cuentas predefinidas de administrador (BA) de Active Directory. La pertenencia a estos grupos debería reducirse al menor número de cuentas posible para limitar su superficie expuesta a ataques. Incluso es posible eliminar la pertenencia "permanente" de estos grupos con privilegios. Puede implementar una configuración que le permita rellenar temporalmente estos grupos solo cuando se necesiten sus privilegios de dominio y bosque. Cuando se usan cuentas con privilegios elevados, solo se deben usar en sistemas seguros designados, como controladores de dominio o hosts administrativos seguros. Se proporciona información detallada para ayudar a implementar todas estas configuraciones en Reducción de la superficie expuesta a ataques de Active Directory.

Al evaluar la pertenencia de los grupos con más privilegios en Active Directory, encontramos habitualmente una pertenencia excesiva en los tres grupos con más privilegios. En algunos casos, las organizaciones tienen docenas o incluso cientos de cuentas en grupos de DA. En otros casos, las organizaciones colocan cuentas directamente en los grupos de administradores predefinidos, ya que piensan que el grupo es "menos privilegiado" que el grupo de DA. No es así. A menudo encontramos un puñado de miembros permanentes del grupo de EA en el dominio raíz del bosque, a pesar de que los privilegios de EA son necesarios rara vez y solo temporalmente. También es habitual encontrar la cuenta administrativa de uso diario de un usuario de TI en los tres grupos a la vez, aunque se trate de una configuración redundante. Como se describe en Reducción de la superficie expuesta a ataques de Active Directory, ya sea miembro permanente de uno de estos grupos o de todos ellos, una cuenta se puede usar para vulnerar e incluso destruir el entorno de AD DS y los sistemas y cuentas administrados por él. Las recomendaciones para la configuración segura y el uso de cuentas con privilegios en Active Directory se proporcionan en Reducción de la superficie expuesta a ataques de Active Directory.

Sobre los controladores de dominio

Al evaluar controladores de dominio, a menudo encontramos que están configurados y administrados de forma similar a los servidores miembro. Los controladores de dominio a veces ejecutan las mismas aplicaciones y utilidades instaladas en los servidores miembro, no porque sean necesarias en los controladores de dominio, sino porque las aplicaciones forman parte de una compilación estándar. Estas aplicaciones pueden proporcionar una funcionalidad mínima a los controladores de dominio, pero amplían significativamente su superficie expuesta a ataques al necesitar configuraciones que abran puertos, creen cuentas de servicio con privilegios elevados o concedan acceso al sistema a usuarios que no deberían conectarse a un controlador de dominio para cualquier propósito que no sea la autenticación o la aplicación de directivas de grupo. En algunas vulneraciones, los atacantes han usado herramientas que ya estaban instaladas en los controladores de dominio no solo para obtener acceso a ellos, sino para modificar o dañar la base de datos de AD DS.

Al extraer información sobre las opciones de configuración de Internet Explorer sobre controladores de dominio, encontramos que los usuarios han iniciado sesión con cuentas con un alto nivel de privilegio en Active Directory y las han usado para acceder a Internet e intranet desde los controladores de dominio. En algunos casos, las cuentas han configurado las opciones de Internet Explorer sobre los controladores de dominio para permitir la descarga de contenido de Internet, por lo que se han descargado utilidades de software gratuito desde sitios de Internet que fueron luego instaladas en los controladores de dominio. La configuración de seguridad mejorada de Internet Explorer está habilitada para usuarios y administradores de forma predeterminada, pero a menudo observamos que se ha deshabilitado para los administradores. Cuando una cuenta con privilegios elevados accede a Internet y descarga contenido en cualquier equipo, está sometiéndolo a un grave riesgo. Cuando el equipo es un controlador de dominio, la instalación de AD DS al completo se pone en riesgo.

Proteger los controladores de dominio

Los controladores de dominio deben tratarse como componentes críticos de la infraestructura; ser protegidos de forma más estricta y configurados de forma más rígida que los servidores de archivos, impresión y aplicaciones. Los controladores de dominio no deben ejecutar ningún software que no sea necesario para que el controlador de dominio funcione o que no proteja el controlador de dominio frente a ataques. No se debe permitir que los controladores de dominio accedan a Internet y las opciones de seguridad se deben configurar y aplicar mediante objetos de directiva de grupo (GPO). Se proporcionan recomendaciones detalladas para la instalación, configuración y administración segura de controladores de dominio en Protección ante ataques de controladores de dominio.

Dentro del sistema operativo

Ley número dos: si los malos pueden alterar el sistema operativo de su equipo, el equipo ya no es suyo. - Diez leyes inmutables sobre la seguridad (versión 2.0)

Aunque algunas organizaciones crean configuraciones como base de referencia para servidores de diferentes tipos y permiten una personalización limitada del sistema operativo después de instalarse, el análisis de entornos vulnerados a menudo descubre un gran número de servidores implementados de forma ad hoc y configurados manual e independientemente. Las configuraciones entre dos servidores que realizan la misma función pueden ser completamente diferentes, sin que ninguno de los dos esté configurado de forma segura. Por el contrario, las bases de referencia de configuración del servidor pueden aplicarse de forma uniforme, pero estar uniformemente mal configuradas; es decir, los servidores se configuran de manera tal que se introduce la misma vulnerabilidad en todos los servidores de un tipo determinado. La configuración incorrecta incluye prácticas como deshabilitar características de seguridad, conceder permisos y derechos excesivos a cuentas (especialmente cuentas de servicio), usar credenciales locales idénticas entre sistemas y permitir la instalación de aplicaciones y utilidades no autorizadas que crean sus propias vulnerabilidades.

Deshabilitar características de seguridad

A veces, las organizaciones deshabilitan Firewall de Windows con seguridad avanzada (WFAS) por creer que su configuración es difícil o que requiere un trabajo intensivo. Pero a partir de Windows Server 2008, cuando se instala cualquier rol o característica en un servidor, se configura de forma predeterminada con los privilegios mínimos necesarios para que funcione, y Firewall de Windows se configura automáticamente para ser compatible con el rol o la característica. Al deshabilitar WFAS (y no usar otro firewall basado en host en su lugar), las organizaciones aumentan la superficie expuesta a ataques del entorno de Windows al completo. Los firewalls perimetrales proporcionan cierta protección ante ataques desde Internet que tienen un entorno como objetivo directo, pero no proporcionan protección ante ataques que aprovechan otros vectores de ataque, como ataques de descarga involuntaria o ataques que se originan en otros sistemas vulnerados de la intranet.

La configuración del control de cuentas de usuario (UAC) a veces está deshabilitada en los servidores porque el personal administrativo considera que los avisos que genera son intrusivos. Aunque en el artículo 2526083 del Soporte técnico de Microsoft se describen escenarios en los que el UAC se puede deshabilitar en Windows Server, a menos que ejecute una instalación básica del servidor (donde el UAC está deshabilitado por diseño) no debe deshabilitarlo en los servidores sin antes estudiarlo y considerarlo con precaución.

En otros casos, las opciones del servidor están configuradas con valores menos seguros porque las organizaciones aplican opciones de configuración de servidor obsoletas a nuevos sistemas operativos, como aplicar las bases de referencia de Windows Server 2003 a equipos que ejecutan Windows Server 2012, Windows Server 2008 R2 o Windows Server 2008, sin cambiar dichas bases de referencia para reflejar los cambios en el sistema operativo. En lugar de mantener bases de referencia de servidores antiguas en nuevos sistemas operativos, al implementar un nuevo sistema operativo, revise los cambios en la seguridad y las opciones de configuración para asegurarse de que la configuración implementada sea aplicable y adecuada para el nuevo sistema operativo.

Conceder privilegios excesivos

En casi todos los entornos que hemos evaluado, se conceden privilegios excesivos a cuentas locales y basadas en dominio en los sistemas Windows. A los usuarios se les conceden derechos de administrador local en sus estaciones de trabajo, los servidores miembros ejecutan servicios configurados con derechos más allá de lo que necesitan para funcionar, y los grupos administradores locales a lo largo de la población de servidores contienen docenas o incluso cientos de cuentas locales y de dominio. La vulneración de una sola cuenta con privilegios en un equipo permite a los atacantes vulnerar las cuentas de todos los usuarios y servicios que inician sesión en el equipo y recopilar y aprovechar las credenciales para propagar la vulneración a otros sistemas.

Los ataques pass-the-hash (PTH) y otros ataques de robo de credenciales son omnipresentes en la actualidad debido a la libre disponibilidad de herramientas que facilitan y simplifican la extracción de credenciales de otras cuentas con privilegios cuando un atacante ha obtenido acceso de nivel de administrador o incluso de sistema a un equipo. Incluso sin herramientas que permitan recopilar credenciales de sesiones de inicio, un atacante que disponga de acceso con privilegios a un equipo puede instalar fácilmente registradores de pulsaciones de teclas que capturen tanto pulsaciones de teclas como capturas de pantalla y contenido del Portapapeles. Un atacante que disponga de acceso con privilegios a un equipo puede deshabilitar el software antimalware, instalar rootkits, modificar archivos protegidos o instalar malware en el equipo que automatice los ataques o que convierta un servidor en un host de descarga involuntaria.

Las tácticas usadas para ampliar una vulneración más allá de un solo equipo varían, pero la clave para propagar las vulneraciones es la adquisición de acceso con privilegios elevados a sistemas adicionales. Al reducir el número de cuentas que dispongan de acceso con privilegios a cualquier sistema, se reduce la superficie expuesta a ataques no solo de ese equipo, sino de la probabilidad de que un atacante recopile credenciales valiosas del equipo.

Estandarizar las credenciales de administrador local

La importancia de cambiar el nombre de cuentas de administrador local en equipos Windows se ha debatido largo y tendido entre los especialistas en seguridad. Lo que es realmente importante sobre las cuentas de administrador local es si están configuradas con el mismo nombre de usuario y contraseña en varios equipos.

Si la cuenta de administrador local se nombra con el mismo valor en varios servidores y la contraseña asignada a la cuenta también está configurada con el mismo valor, los atacantes pueden extraer las credenciales de la cuenta en un equipo en el que se ha obtenido acceso a nivel de administrador o de sistema. El atacante no tiene por qué vulnerar la cuenta de administrador inicialmente; solo necesita vulnerar la cuenta de un usuario que sea miembro del grupo de administradores local o de una cuenta de servicio configurada para ejecutarse como LocalSystem o con privilegios de administrador. El atacante puede entonces extraer las credenciales de la cuenta de administrador y reproducir esas credenciales en inicios de sesión de red en otros equipos de la red.

Siempre que otro equipo tenga una cuenta local con el mismo nombre de usuario y contraseña (o hash de contraseña) que las credenciales de cuenta que se presentan, el intento de inicio de sesión se realiza correctamente y el atacante obtiene acceso con privilegios al equipo objetivo. En las versiones actuales de Windows, la cuenta predefinida de administrador está deshabilitada de forma predeterminada, pero en los sistemas operativos heredados, la cuenta está habilitada de forma predeterminada.

Nota

Algunas organizaciones han configurado intencionadamente la habilitación de cuentas de administrador local, convencidas de que esto proporciona seguridad "a prueba de errores" en caso de que todas las demás cuentas con privilegios pierdan acceso al sistema. Sin embargo, incluso si la cuenta de administrador local está deshabilitada y no hay otras cuentas disponibles que puedan habilitar la cuenta o iniciar sesión en el sistema con privilegios de administrador, el sistema se puede arrancar en modo seguro y la cuenta predefinida de administrador local se puede volver a habilitar, como se describe en el artículo 814777 del Soporte técnico de Microsoft. Además, si el sistema sigue aplicando correctamente los GPO, se puede modificar un GPO para volver a habilitar (temporalmente) la cuenta de administrador o se pueden configurar los grupos restringidos para que agreguen una cuenta basada en dominio al grupo de administradores local. Se pueden realizar reparaciones y deshabilitar de nuevo la cuenta de administrador. Para evitar una vulneración lateral que use credenciales de una cuenta predefinida de administrador local, se deben configurar nombres de usuario y contraseñas únicos para las cuentas de administrador local. Para implementar contraseñas únicas para las cuentas de administrador local a través de un GPO, consulte Solución para la administración de la contraseña de una cuenta predefinida de administrador a través de GPO en technet.  

Permitir la instalación de aplicaciones no autorizadas

Ley número uno: si los malos le convencen para ejecutar un programa en su equipo, el equipo ya no es solo suyo. - Diez leyes inmutables sobre la seguridad (versión 2.0)

Aunque una organización implemente configuraciones de base de referencia coherentes en los servidores, no se debe permitir la instalación de aplicaciones que no formen parte del rol definido de un servidor. Al permitir la instalación de software que no forma parte de la funcionalidad designada de un servidor, los servidores se exponen a la instalación involuntaria o malintencionada de software, lo que puede aumentar la superficie expuesta a ataques del servidor, introducir vulnerabilidades en las aplicaciones o provocar inestabilidad en el sistema.

APLICACIONES

Como se ha descrito anteriormente, es habitual que las aplicaciones se instalen y configuren para que usen cuentas con más privilegios de los que la aplicación realmente requiere. En algunos casos, la documentación de la aplicación especifica que las cuentas de servicio deben ser miembros del grupo de administradores locales de un servidor o que se deben configurar para ejecutarse en el contexto del LocalSystem. Esto no suele deberse a que la aplicación requiera esos derechos, sino a que determinar los derechos y permisos que necesitan las cuentas de servicio de una aplicación requiere invertir tiempo y esfuerzo adicionales. Si una aplicación no se instala con los privilegios mínimos necesarios para que la aplicación y sus características configuradas funcionen, el sistema se expone a ataques que aprovechan los privilegios de aplicación sin ningún ataque contra el propio sistema operativo.

Falta de prácticas seguras de desarrollo de aplicaciones

La infraestructura existe como apoyo para las cargas de trabajo empresariales. Cuando estas cargas de trabajo se implementan en aplicaciones personalizadas, es fundamental asegurarse de que las aplicaciones se desarrollan mediante procedimientos recomendados seguros. El análisis de la causa principal de los incidentes que afectan a la totalidad de una empresa suele revelar que la vulneración inicial se efectúa a través de aplicaciones personalizadas, especialmente aquellas accesibles desde Internet. La mayoría de estas vulneraciones se realizan a través de ataques bien documentados, como la inyección de código SQL (SQLi) y los ataques de scripting entre sitios (XSS).

La inyección de código SQL es una vulnerabilidad de aplicación que permite que la entrada definida por el usuario modifique una instrucción SQL que se pasa a la base de datos para su ejecución. Esta entrada se puede proporcionar a través de un campo de la aplicación, un parámetro (como una cadena de consulta o una cookie) u otros métodos. El resultado de esta inyección es que la instrucción SQL proporcionada a la base de datos es radicalmente diferente de la prevista por el desarrollador. Tomemos como ejemplo una consulta usada habitualmente en la evaluación de una combinación de nombre de usuario y contraseña:

SELECT userID FROM users WHERE username = 'sUserName' AND password = 'sPassword'

Cuando el servidor de base de datos recibe esto, le indica al servidor que examine la tabla de usuarios y devuelva cualquier registro userID donde el nombre de usuario y la contraseña coincidan con los proporcionados por el usuario (supuestamente a través de un formulario de inicio de sesión de algún tipo). Naturalmente, la intención del desarrollador en este caso es devolver solo un registro válido si el usuario puede proporcionar un nombre de usuario y una contraseña correctos. Si alguno de los dos es incorrecto, el servidor de bases de datos no podrá encontrar un registro coincidente y devolverá un resultado vacío.

El problema se produce cuando un atacante hace algo inesperado, como proporcionar su propio SQL en lugar de datos válidos. Dado que el servidor de base de datos interpreta SQL sobre la marcha, el código insertado se procesaría como si el propio desarrollador lo hubiese puesto ahí. Por ejemplo, si el atacante escribió aministratorcomo identificador de usuario y xyz OR 1=1 como contraseña, la instrucción resultante procesada por la base de datos sería:

SELECT userID FROM users WHERE username = 'administrator' AND password = 'xyz' OR 1=1

Cuando el servidor de base de datos procese esta consulta, se devolverán todas las filas de la tabla en la consulta porque 1=1 siempre se evaluará como True, por lo que no importa si se conoce o proporciona el nombre de usuario y la contraseña correctos. La consecuencia directa en la mayoría de los casos es que el usuario iniciará sesión como el primer usuario de la base de datos; en la mayoría de los casos, será el usuario administrativo.

Además de iniciar sesión, se pueden usar instrucciones SQL con formato incorrecto como esta para añadir, eliminar o cambiar datos, o incluso quitar (eliminar) tablas completas de una base de datos. En los casos más extremos en los que una SQLi se combina con privilegios excesivos, se pueden ejecutar comandos del sistema operativo para permitir la creación de nuevos usuarios, descargar herramientas de ataque o realizar cualquier otra acción que los atacantes elijan.

Con el scripting entre sitios, la vulnerabilidad se introduce en la salida de la aplicación. Un ataque comienza cuando un atacante proporciona datos con formato incorrecto a la aplicación, pero en este caso estos datos están en forma de código de scripting (como JavaScript), el cual se ejecutará en el explorador de la víctima. Aprovecharse de una vulnerabilidad XSS puede permitir al atacante ejecutar cualquier función de la aplicación de destino en el contexto del usuario que inició el explorador. Normalmente, los ataques XSS se inician mediante un correo electrónico de suplantación de identidad (phishing) que insta al usuario seleccionar un vínculo que se conecta a la aplicación y ejecuta el código de ataque.

El XSS se aprovecha habitualmente en escenarios de banca en línea y comercio electrónico en los que un atacante puede realizar compras o transferir dinero en el contexto del usuario vulnerado. En el caso de un ataque dirigido a una aplicación de administración de identidades basada en web personalizada, puede permitir que un atacante cree sus propias identidades, modifique los permisos y los derechos hasta que se provoque una vulneración a nivel de sistema.

Aunque una explicación completa del scripting entre sitios y la inyección de código SQL está fuera del ámbito de este documento, el Proyecto abierto de seguridad en aplicaciones web (OWASP) publica una lista de los 10 tipos de ataque más importantes con una explicación detallada de vulnerabilidades y contramedidas.

Independientemente de la inversión en seguridad de la infraestructura, si se implementan aplicaciones escritas y diseñadas incorrectamente dentro de ella, el entorno se vuelve vulnerable a los ataques. Es habitual que incluso las infraestructuras bien protegidas no puedan proporcionar contramedidas eficaces a estos ataques de aplicación. Para agravar el problema, las aplicaciones mal diseñadas pueden requerir que las cuentas de servicio tengan permisos excesivos para funcionar.

El Ciclo de vida de desarrollo de seguridad (SDL) de Microsoft es un conjunto de controles de procesos estructurales que funcionan para mejorar la seguridad desde la recopilación de requisitos inicial y a lo largo de todo el ciclo de vida de la aplicación, hasta que se retire. Esta integración de controles de seguridad eficaces no solo es fundamental desde una perspectiva de seguridad. También es crucial asegurarse de que la seguridad de las aplicaciones sea rentable tanto a nivel de coste como de tiempo. Para evaluar una aplicación para encontrar problemas de seguridad cuando su código ya está completo, es necesario que las organizaciones tomen decisiones sobre la seguridad de la aplicación justo antes o incluso después de implementarla. Una organización puede optar por abordar los errores de la aplicación en producción antes de implementarla, lo cual incurre en costes adicionales y retrasos. Por otra parte, la aplicación se puede implementar cuando todavía está en producción y tiene errores de seguridad conocidos, lo cual expone la organización a vulneraciones.

Algunas organizaciones sitúan el coste completo de corregir un problema de seguridad en el código en producción por encima de 10 000 $ por problema, y las aplicaciones desarrolladas sin un SDL eficaz pueden tener una media de más de diez problemas de gravedad alta por cada 100 000 líneas de código. En aplicaciones grandes, los costes no tardan en acumularse. Por el contrario, muchas empresas establecen un punto de referencia de menos de un problema por cada 100 000 líneas de código en la fase final de revisión de código del SDL, y aspiran a una estima de cero problemas en aplicaciones de alto riesgo en producción.

La implementación del SDL mejora la seguridad al incluir requisitos de seguridad desde la recopilación de requisitos inicial. El diseño de una aplicación proporciona modelado de amenazas para aplicaciones de alto riesgo y requiere una formación y supervisión eficaces de los desarrolladores, además de prácticas y estándares de código claros y coherentes. Un SDL proporciona mejoras significativas en la seguridad de las aplicaciones a la vez que reduce el coste de desarrollar, implementar, mantener y retirar una aplicación. Aunque una explicación completa del diseño e implementación de SDL está fuera del ámbito de este documento, consulte Ciclo de vida de desarrollo de seguridad de Microsoft para obtener instrucciones e información en detalle.