NewSID, una herramienta de seguridad incuestionable durante 12 años, no serví­a para nada

La noticia no es nueva, realmente se hizo oficial y público en noviembre de 2009. Sin embargo, queremos recordar y ofrecer ahora esta información a nuestros lectores porque pensamos que no ha tenido la repercusión que merece. Es la historia de cómo un una herramienta de seguridad programada por el reputado Mark Russinovich ha sido utilizada durante 12 años… y no serví­a para nada.

Sysinternals (liderada por Russinovich y comprada por Microsoft en 2006) jubiló para siempre NewSID en noviembre de 2009, después de ser creada y usada intensamente por muchos administradores desde 1997. Simplemente, no serví­a para nada, declaró el propio creador. ¿Cómo es posible que alguien con tan extensa y demostrada experiencia creara una herramienta «inútil»? Repasemos la secuencia de hechos e intentemos extraer algunas conclusiones:

Detalles técnicos previos

De forma breve, el SID (Security Identifier) es una variable numérica en Windows que define internamente a sistemas y usuarios. El sistema trabaja con SIDs y no con los nombres de usuario que nos muestra, por ejemplo, a la hora de acceder a NTFS y comprobar los permisos.

Se entenderá con ejemplos:

* SID S-1-1-0 es el SID universal del grupo «Todos» en todos los Windows, así­ este grupo es reconocido por igual en cualquier máquina, por ejemplo. Los SID son siempre los mismos para los grupos por defecto que existen en los Windows (Administradores, Usuarios, «Administradores de dominio», etc.)

* S-1-5-21-1390034357-113127714-1060454298 es un ejemplo de SID de una máquina (y no de un usuario).

* S-1-5-21-1390067357-113007714-1060284298-500, serí­a el SID del administrador de esa máquina. La parte final, el RID, siempre es 500 para los administradores y 1000 para el invitado; 1001, para el primer usuario y así­ sucesivamente. Un usuario borrado y vuelto a crear, aunque sea con el mismo nombre, no será realmente el mismo usuario porque su RID será distinto.

Cuando un usuario se autentica en Windows, la Local Security Authority Subsystem (Lsass.exe) crea una sesión de logon y un token. Este token es una estructura numérica que contiene el SID de la cuenta y de los grupos a los que pertenece ese usuario además de todos los privilegios asignados a ese usuario y grupos. Se trata del «salvoconducto» que comprobará Windows cada vez que este usuario quiera realizar algo en el sistema tanto en cuestión de permisos (acceso a archivos en NTFS) como de privilegios.

Al presentarse en sesiones remotas (por ejemplo al acceder a unidades compartidas), es necesario autenticarse en el Windows remoto con una cuenta conocida para él (ya sea local o de dominio). En ese momento, el sistema hace uso de ese token para comprobar si realmente un usuario «en remoto» puede acceder.

Cuándo y por qué se usaba NewSID

En entornos corporativos es común instalar un Windows y clonarlo a otras máquinas. En 1997, Microsoft ya disponí­a de Sysprep, que es una herramienta que cambia el SID y además «generaliza» un sistema (lo prepara para que sea clonado «sin problemas»). Pero está muy limitado y (entre otros cambios) solo modifica el SID en Windows «ví­rgenes», si existen aplicaciones de terceros, no permite hacerlo. NewSID fue programado entonces para modificar consistentemente el SID de una máquina, aunque tuviese otras aplicaciones instaladas. Así­, supuestamente, se garantizaba su estabilidad y además se evitaban problemas de seguridad por convivir con otras con el mismo SID.

Es casi seguro que todas las empresas que han clonado Windows en alguna ocasión, han usado NewSID con la esperanza de eliminar problemas de seguridad potenciales que se supone podí­an surgir por existir máquinas con el mismo SID en una red. Eso decí­a todo el mundo, y nadie lo cuestionaba. Pero… ¿era necesario?

La pista

Windows Vista empezó a fallar en alguna ocasión tras usar NewSID.

Russinovich comenzó a depurar el programa y replantearse su funcionamiento. ¿De verdad mantener el mismo SID en diferentes máquinas era un problema? Este hecho no era cuestionado por nadie, mucho menos por el autor del programa. Pero cuanto más lo pensaba, más convencido estaba de que se habí­a usado una herramienta inútil: cambiar el SID no ofrece ventajas ni de seguridad ni de ningún tipo) durante más de 12 años.

Mark pensó que la única forma de que efectivamente supusiera un problema, es que el SID realmente fuera referenciado por alguna máquina externa en alguna ocasión. Sólo así­ cabrí­a la posibilidad de «usarlo ilegí­timamente» de alguna forma en una red y que el hecho de compartir el SID fuera peligroso (permitiese a personas acceder a recursos que no le corresponden). Si el SID «viajara» hacia la otra máquina al compartir una unidad, por ejemplo, podrí­a emplearse de forma insegura al comprobar los permisos.

La clave

Pero lo cierto es que Windows solo permite autenticarse en otro ordenador a través de un usuario válido para ese otro sistema (ya sea local o del dominio al que ambos pertenezcan). Una vez que se le ofrece ese usuario para autenticarse, la máquina remota toma el SID de su propia SAM, y si es el dominio, es el controlador el que lo toma de su base de datos. Ese Windows nunca hace referencia al SID de la máquina que quiere conectarse. Por tanto concluyó que el SID realmente no tiene un papel relevante a la hora de acceder a un sistema remoto y autenticarse sino que, lo que realmente cuenta, es un nombre de usuario y una contraseña. Aunque se comparta el SID, no se permitirí­a el acceso a nada.

De hecho, realmente era obvio. Desde siempre, existen SIDs «universales» como el del grupo «Todos», la cuenta SYSTEM… ¿Ha supuesto alguna vez esto un problema de seguridad en una red?

Sin embargo, se dan un par de excepciones en las que el SID sí­ que permitirí­a acceso a recursos ajenos: una de ellas es en el caso de discos duros externos formateados con NTFS. Dos máquinas con mismo SID podrí­an acceder a los archivos… pero la verdad es que existen otras maneras mucho más sencillas de acceder a un disco duro externo NTFS sin cifrar que la de «compartir» SIDs.

Mark lo habló con los desarrolladores de Microsoft y el equipo de seguridad y, tras discutirlo ampliamente, retiraron NewSID en noviembre de 2009. Mantienen Sysprep porque realiza otras acciones necesarias para los Windows a la hora de clonar sistemas.

¿Y ahora qué?

El propio Mark se sorprende de que el mito de la duplicación de SIDs no haya sido cuestionado hasta ahora. Como él mismo escribe «todo el mundo asumió que otra persona sabrí­a exactamente cuál era el problema».

Pero nadie lo sabí­a. De hecho, no habí­a problema alguno. Mark programó, con la mejor de las intenciones y de una manera técnicamente brillante, una herramienta que solucionaba un problema que no existí­a. Ni siquiera para Microsoft estaba claro el asunto, y la herramienta no fue cuestionada en ningún momento. Tuvieron que pasar más de 12 años para descubrir que el esfuerzo realmente no hací­a ningún bien (aunque afortunadamente, tampoco causaba ningún mal).

Resulta una historia realmente curiosa. Particularmente, hace que reflexionemos sobre una cuestión que nos parece relevante y, desgraciadamente, más común de lo que parece: ¿Qué otros mitos damos por sentado, pensando que «cualquier otro sabrá exactamente cuál es el problema»? ¿Con qué otros hábitos «incuestionables» convivimos?

Fuente: Boletí­n de seguridad de Hispasec