NewSID No servia para nada
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 todos los usuarios y 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? En realidad, "todo el
mundo asumió que otra persona sabría exactamente cuál era el problema".
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).
Más información:
The Machine SID Duplication Myth