{"id":245,"date":"2006-02-06T12:55:31","date_gmt":"2006-02-06T12:55:31","guid":{"rendered":"http:\/\/hcastillo.wordpress.com\/2006\/02\/06\/microsoft-windows-y-el-control-de-acceso-al-desnudo"},"modified":"2015-04-19T08:06:09","modified_gmt":"2015-04-19T07:06:09","slug":"microsoft-windows-y-el-control-de-acceso-al-desnudo","status":"publish","type":"post","link":"https:\/\/heccasan.webs.upv.es\/?p=245","title":{"rendered":"Microsoft Windows y el control de acceso, al desnudo"},"content":{"rendered":"

Microsoft Windows y el control de acceso, al desnudo<\/h1>\n
\n

Sudhakar Govindavajhala y Andrew W. Appel de la Universidad de
\nPrincetown (Nueva York), han publicado un interesante estudio sobre
\npermisos y control de acceso en sistemas Microsoft Windows. En el
\nestudio se desmitifica el funcionamiento del sistema operativo Windows a
\nla hora de controlar el acceso a sus recursos y se explica c\u00f3mo algunos
\ncomportamientos han provocado vulnerabilidades no s\u00f3lo en el sistema
\noperativo, sino en conocidos programas comerciales.<\/p>\n

Estos investigadores han usado la programaci\u00f3n l\u00f3gica para implementar
\nlo que han llamado MulVAL (Multihost, Multistage, Vulnerability
\nAnalysis) una herramienta que han utilizado para analizar profundamente
\nel control de acceso de los sistemas Windows XP. Mediante la informaci\u00f3n
\nrecopilada desde distintas fuentes del sistema (el registro, sistema de
\nficheros…) el modelo implementado elabora una especie de \u00abmapa\u00bb por el
\nque se revelan varias posibles f\u00f3rmulas y distintas v\u00edas de ataque,
\ntodas destinadas a elevar los privilegios de un usuario local en el
\nsistema. Con esta herramienta, entre otras, se han encontrado hasta 20
\nformas distintas de escalar privilegios desde cuentas del grupo
\n\u00abusuarios avanzados\u00bb a administradores. Aunque los usuarios avanzados
\nposeen bastantes privilegios sobre la m\u00e1quina, no llegan a los totales
\npoderes del administrador.<\/p>\n

En el estudio se habla tambi\u00e9n de forma clara y sencilla sobre los
\npotenciales peligros de la implementaci\u00f3n incorrecta de las listas de
\ncontrol de acceso a los objetos Windows y se plantean f\u00f3rmulas por las
\nque se puede llevar a un usuario del sistema a poder ejecutar cualquier
\ntipo de c\u00f3digo con los permisos del administrador o de cuentas
\nreservadas del sistema con altos privilegios.<\/p>\n

Si Unix tiene un modelo simple de control de acceso basado en tres
\nprivilegios (adem\u00e1s del bit UID) que se dan a distintos objetos del
\nsistema (ficheros, directorios…), el sistema de Windows es mucho m\u00e1s
\ncomplejo. Se arrastra una lista de control de acceso de hasta 30
\npermisos diferentes para operaciones sobre unos 15 tipos distintos de
\nobjetos, todo ello con la posibilidad de negar o permitir expl\u00edcitamente
\nel privilegio. Esto permite afinar en extremo los permisos, pero tambi\u00e9n
\npuede suponer un verdadero galimat\u00edas para un administrador o para un
\nprogramador que quiera desarrollar una herramienta que interact\u00fae con
\nlos objetos del sistema, pues deben documentarse profusamente y
\ncomprender la compleja estructura de permisos.<\/p>\n

Aunque los permisos en Windows est\u00e1n bien documentados y detallados,
\nresulta muy com\u00fan observar c\u00f3mo los creadores de software profesionales
\na menudo no eval\u00faan correctamente el impacto que puede llegar a tener la
\ninstalaci\u00f3n de su programa en un sistema sin haber afinado correctamente
\nlos permisos que han elegido para sus aplicaciones. La consecuencia es
\nque mucho software comercial puede llevar a la elevaci\u00f3n de privilegios
\npor parte de usuarios en sistemas compartidos, y de hecho ya se han dado
\ncasos concretos.<\/p>\n

Hace poco, a principios de febrero de 2006, se han identificado errores
\nde permisos en ficheros y directorios en varios productos Adobe tales
\ncomo Adobe Photoshop CS2, Illustrator CS2, y Adobe Help Center. El grupo
\n\u00abTodos\u00bb ten\u00eda permiso de escritura en 170 archivos (ejecutables y
\nlibrer\u00edas) de productos Adobe. Un atacante podr\u00eda sustituirlos por
\nc\u00f3digo malicioso en local y esperar a que el administrador los ejecutara
\npara poder arrancar ese c\u00f3digo con mayores privilegios. La configuraci\u00f3n
\nest\u00e1ndar de AOL, entre otros, tambi\u00e9n permit\u00eda a un usuario invitado
\nejecutar c\u00f3digo con los permisos de cualquier otro usuario (incluso los
\nde \u00abLocal System\u00bb), simplemente manipulando claves de registro. Los
\npermisos de las ramas de registro, seg\u00fan apunta el estudio, pueden
\nsuponer tambi\u00e9n habitualmente un problema de seguridad.<\/p>\n

La herramienta que desarrollaron estos investigadores ha ayudado a
\ndescubrir muchos problemas de permisos tanto en software comercial como
\nen componentes del sistema. El caso de los servicios es especialmente
\nsignificativo. Al existir tantas formas y combinaciones posibles de
\npermisos, los desarrolladores optan por distintas v\u00edas (por no existir
\nuna convenci\u00f3n \u00fanica) para implementar la funcionalidad de un servicio
\npropio que correr\u00e1 en sistemas Windows. Cada servicio tiene un
\ndescriptor de seguridad que especifica a qu\u00e9 usuarios se les permite
\nconfigurar o arrancar o parar un servicio. Algunos fabricantes no
\naplican correctamente el modelo de control de acceso de Windows en sus
\nservicios y por ejemplo, otorgan indiscriminadamente el permiso \u00abSERVICE
\nCHANGE CONFIG\u00bb que permite modificar el ejecutable ligado al servicio.
\nMicrosoft recomienda que este permiso sea s\u00f3lo dado a los
\nadministradores, pero en su documentaci\u00f3n no avisa expl\u00edcitamente de que
\neste permiso tambi\u00e9n permite no s\u00f3lo modificar el ejecutable sino
\nespecificar qui\u00e9n lo har\u00e1, de forma que si, a trav\u00e9s de cualquier
\nprograma instalado se posee este privilegio, se puede ejecutar
\npotencialmente cualquier fichero bajo cualquier cuenta del sistema.<\/p>\n

Por ejemplo, el grupo \u00abTodos\u00bb ten\u00eda este permiso de configuraci\u00f3n
\nactivado en el servicio \u00abMacromedia Licensing Service\u00bb que instalaban
\nvarios productos de Macromedia. Afortunadamente este problema fue
\nsolucionado en junio de 2005. Existen otros agujeros menos graves en
\nservicios de fabricantes ajenos a Microsoft, pero en el estudio no se
\ndan detalles a la espera de que puedan ser solventados.<\/p>\n

No s\u00f3lo a trav\u00e9s de servicios de terceros es posible elevar privilegios.
\nPor ejemplo, seg\u00fan el estudio, varios servicios de Windows XP, tales
\ncomo \u00abServicio de descubrimientos SSDP\u00bb y \u00abHost de dispositivo Plug and
\nPlay universal\u00bb ten\u00edan hasta hace poco ese privilegio (\u00abSERVICE CHANGE
\nCONFIG\u00bb) activado por defecto para el grupo \u00abUsuarios Autenticados\u00bb.
\nCualquier usuario con cuenta en el sistema pertenece a ese grupo, por lo
\nque potencialmente cualquier usuario pod\u00eda modificar el ejecutable que
\narrancaba estos servicios y la cuenta bajo la que iba a ejecutarse. Se
\npermit\u00eda as\u00ed, indirectamente, la instalaci\u00f3n de un troyano o software
\nda\u00f1ino modificando la configuraci\u00f3n del servicio y esperando a que fuese
\nreiniciado. Esto fue solucionado por Microsoft en agosto de 2004, aunque
\nel peligro estaba presente desde casi dos a\u00f1os antes. Otros servicios
\ndel sistema se descubrieron vulnerables y tambi\u00e9n fueron parcheados
\nposteriormente.<\/p>\n

El problema se basa en que las aplicaciones que instalamos necesitan
\nnormalmente muchos menos privilegios de los que realmente poseen para
\nacceder a los datos con los que operan. Encontrar el conjunto de
\npermisos estrictamente necesarios para que funcione una aplicaci\u00f3n bajo
\ncondiciones lo m\u00e1s as\u00e9pticas posibles de seguridad, es objeto de otro
\nestudio liderado en 2005 por Shuo Chen, y titulado \u00abA black-box tracing
\ntechnique to identify causes of least-privilege incompatibilities\u00bb. En
\n\u00e9l se explica una t\u00e9cnica para encontrar en los programas los m&iacu
\nte;nimos
\nprivilegios posibles y necesarios que le son necesarios para funcionar.<\/p>\n

En definitiva, con la herramienta desarrollada por Sudhakar
\nGovindavajhala y Andrew W. Appel, se permite facilitar la tarea del
\nestudio de los controles de acceso a sistemas Windows, algo, como se ha
\nvisto, delicado. Como la herramienta puede considerarse potencialmente
\npeligrosa, no se ha hecho p\u00fablica, aunque s\u00ed se recomienda a los
\nadministradores usar herramientas an\u00e1logas de estudio y modificaci\u00f3n de
\npermisos, tales como SubInACL de Microsoft, y estudiar con ellas
\ncuidadosamente los permisos de los ficheros y objetos del sistema.<\/p>\n

Tanto en entornos dom\u00e9sticos como corporativos, gran parte de los
\nproblemas de seguridad de Windows vienen por el hecho de usar el sistema
\nen modo administrador. Entender los permisos y controles de acceso es
\nfundamental para limitar el impacto de los fallos de seguridad del
\nsoftware, pero parece ser que Microsoft, en este sentido, no termina de
\nentenderse con los usuarios ni con los programadores de aplicaciones. No
\nhay raz\u00f3n para pensar que los desarrolladores de Adobe, Macromedia o AOL
\nhan sido los \u00fanicos que han cometido errores y es seguro que otros
\nfallar\u00e1n en los mismos t\u00e9rminos. Estudios como los expuestos demuestran
\nque un cambio de rumbo y una mayor concienciaci\u00f3n por ambas partes en
\neste sentido har\u00eda de Windows un sistema operativo m\u00e1s seguro.
\nMicrosoft Windows y el control de acceso, al desnudo<\/p>\n<\/div>\n

 <\/p>\n","protected":false},"excerpt":{"rendered":"

Sudhakar Govindavajhala y Andrew W. Appel de la Universidad de
\nPrincetown (Nueva York), han publicado un interesante estudio sobre
\npermisos y control de acceso en sistemas Microsoft…<\/p>\n","protected":false},"author":2,"featured_media":2633,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-245","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-curiosidades"],"_links":{"self":[{"href":"https:\/\/heccasan.webs.upv.es\/index.php?rest_route=\/wp\/v2\/posts\/245","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/heccasan.webs.upv.es\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/heccasan.webs.upv.es\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/heccasan.webs.upv.es\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/heccasan.webs.upv.es\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=245"}],"version-history":[{"count":2,"href":"https:\/\/heccasan.webs.upv.es\/index.php?rest_route=\/wp\/v2\/posts\/245\/revisions"}],"predecessor-version":[{"id":2630,"href":"https:\/\/heccasan.webs.upv.es\/index.php?rest_route=\/wp\/v2\/posts\/245\/revisions\/2630"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/heccasan.webs.upv.es\/index.php?rest_route=\/wp\/v2\/media\/2633"}],"wp:attachment":[{"href":"https:\/\/heccasan.webs.upv.es\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=245"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/heccasan.webs.upv.es\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=245"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/heccasan.webs.upv.es\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=245"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}