BeyondTrust ha publicado un estudio pormenorizado de todas las vulnerabilidades publicadas por Microsoft en 2008. Ha concluido que el 92% de las vulnerabilidades críticas y el 69% de todas (críticas o no) serían menos graves, o tendrían un impacto mucho menor, si fuesen aprovechadas por un atacante pero la víctima no fuese administrador. Cuando un atacante aprovecha una vulnerabilidad de ejecución de código en un programa que está siendo usado por un administrador, éste código hereda sus permisos y el atacante podrá campar a sus anchas (como el usuario) en el sistema una vez explotado el fallo. En un 92% de los casos, según el informe, se hubiese limitado considerablemente la gravedad del asunto.
Siempre se ha recomendado evitar la cuenta administrador, es el principal consejo para los usuarios de sistemas operativos en general y los de Windows en particular. Esta es la primera capa de seguridad con la que se debe proteger un usuario. Un "administrador" está precisamente para "administrar", y son muy pocas veces las que un usuario utiliza su sistema para realizar modificaciones importantes. La mayor parte del tiempo lee correo o navega, actividad esta última que conlleva un importante riesgo, sea con el navegador que sea. Esta irresponsable actitud de usuario administrador perpetuo está heredada de los tiempos de Windows 9x. No tenía sistema de usuarios local real, ni soportaba NTFS, con lo que no se podían establecer permisos por usuarios. Con XP, por fin, Microsoft permitía la creación de un usuario inicial distinto al administrador para el uso del sistema, pero lo incluía por defecto al grupo administradores y por tanto no lo protegía ni limitaba en absoluto.
El otro 8%
El informe no explica por qué el impacto de tantas vulnerabilidades es susceptible a la cuenta bajo la que se exploten. ¿Por qué no nos protege del 100% de las vulnerabilidades críticas el hecho de trabajar como usuario sin privilegios? Pues porque el resto, el 8% de vulnerabilidades se pueden clasificar básicamente en tres:
* Las que permiten revelación de información. Estas suelen ser independientes del usuario bajo el que se explota la vulnerabilidad.
* Las que afectan a servicios de sistema que corren siempre bajo cuentas privilegiadas. Los servicios especiales de sistema corren normalmente bajo la cuenta SYSTEM. Si un atacante aprovecha un fallo en estos servicios desde el exterior, no hay nada que el usuario pueda hacer para evitarlo excepto intentar precisamente que el servicio no esté accesible para cualquiera. Hay que recordar que ya hicieron un trabajo importante de limitación de cuentas de servicio cuando apareció XP. En 2000 todos los servicios trabajaban con los máximos privilegios. En XP y 2003, no.
* Las elevaciones de privilegios. Evidentemente, este tipo de vulnerabilidades permiten precisamente saltar de una cuenta sin privilegios a otra con mayor capacidad de actuación sobre el sistema. Si se trabaja con cuenta limitada, es una de las mayores preocupaciones. Si se trabaja como administrador, estas vulnerabilidades no suelen tienen impacto (excepto si logran privilegios de SYSTEM, ligeramente superiores a los del propio Administrador). Hoy en día, las vulnerabilidades de elevación de privilegios son poco valoradas por los atacantes (en especial los creadores de malware) porque presuponen (y presuponen bien) que su víctima será administrador.
¿Windows un 92% más seguro?
Significa que el trabajar con cuentas con privilegios menos elevados ayudaría a que el sistema fuese un 92% más seguro? Desgraciadamente no, pero sin duda ayudaría.
Trabajar como usuario con pocos privilegios no es la panacea. Trabajar como usuario raso en XP o 2000 con cierto software puede llegar a ser incómodo, incluso para usuarios experimentados (y casi siempre esto es responsabilidad de los propios programadores, que no suelen tenerlo en cuenta). Es necesario tener conocimientos sobre permisos, privilegios, NTFS, derechos, herencias, grupos… Por si fuera poco, con ánimo de no complicar al usuario, Windows XP Home Edition esconde deliberadamente la pestaña de seguridad para poder cambiar los permisos, a no ser que se trabajara en modo a prueba de fallos. En otros sistemas operativos resulta más sencillo, porque los programadores siempre han supuesto que su usuario no iba a gozar de todos los permisos.
El problema es, como de costumbre, la educación del usuario ante una estructura tan compleja como hoy en día es un sistema operativo. Estamos tan mal acostumbrados que si un usuario de cualquier sistema operativo (distinto a Windows) se convierte en víctima del exploit de una vulnerabilidad, y por ello el sistema queda totalmente comprometido, lo primero que preguntamos es si estaba trabajando como root. Si es así, inmediatamente la mayor parte de la responsabilidad cae del lado del usuario (abstrayéndonos de la responsabilidad del software). Se entiende como una especie de castigo justo por no conocer y limitar convenientemente su entorno de trabajo, o por despiste. En Windows, si un usuario es víctima de un malware que se le ha colado a través del navegador, y esta víctima trabaja como administrador (lo más habitual) el problema se achaca directamente al sistema operativo o al navegador y sus continuos fallos. No solemos pararnos a pensar en que el usuario, tampoco en este caso, conoce realmente su entorno de trabajo o no se le han proporcionado la facilidades para hacerlo, y por eso no lo ha limitado convenientemente. Limitándolo, si bien no se reduciría el número de fallos, sí se degradará considerablemente su impacto, como bien recuerda el informe.
Más Información:
Reducing the Threat from Microsoft Vulnerabilities: 92% of Critical
Vulnerabilities can be Mitigated by Removing Admin Rights
http://www.beyondtrust.com/documentation/whitePapers/wp_VulnerabilityReport.pdf
La Web de MONSI 