Mes: septiembre 2005

Configurar la identidad de un Application Pool en IIS 6.0

Por defecto, los Application Pools en IIS 6.0 se ejecutan bajo el principal Network Service


El principal Network Service aparece a la par que el principal Local Service y se presentan por primera vez en Windows XP y Windows Server 2003. El motivo de estos dos nuevos principals tiene su origen en los planteamientos de seguridad por defecto y ejecución con mínimos privilegios. Anteriormente a estos dos principals, muchos servicios se ejecutaban bajo el principal SYSTEM (aka Local System) teniendo por tanto un nivel de privilegios altísimo, en muchos casos absolutamente innecesarios.


Los permisos que poseen estos dos nuevos principals son básicamente lo mismos que posee una cuenta de usuario que solamente pertenezca el grupo Users. A mayores, poseen el derecho de iniciar sesión como un servicio (Logon as a service), lo cuál resulta obvio por su propósito de uso.


La diferencia entre estos dos principals está en cómo se gestionan los intentos de acceso a recursos compartidos en otros equipos de la red:



  • Un servicio ejecutandose bajo Network Service se identifica para la autenticación ante las otras máquina del dominio en la red usando la cuenta de equipo. Es decir, si el servicio Service1 ejecutándose bajo Network Service en la máquina Server1 perteneciente al dominio Dominio1 intenta acceder a una carpeta compartida en Server2, se le permitirá acceso o no en base a los permisos que Dominio1Server1 tenga sobre el recurso compartido.

  • Un servicio ejecutandose bajo Local System no será capaz de autenticarse y se representará en la máquina remota como una sesión nula o null session (que es como Windows representa un usuario anónimo)

Nota importante para los dos principals: si la máquina no pertenece a un dominio o pertenece a un dominio de Windows NT 4, ninguno de los dos principals tendrá credenciales de red.


A mayores de los privilegios comentados, a ambos principals se les asignan los privilegios SeAuditPrivilege y SeAssignPrimaryTokenPrivilege. Esto permite generar auditorias de seguridad e iniciar procesos bajo diferentes cuentas.


Cómo modificar la identidad bajo la que funciona un Application Pool


Para ejecutar un Application Pool bajo unas credenciales diferentes a Network Service será necesario crear una nueva cuenta. Si es necesario credenciales de red habrá que crear una cuenta de dominio. Si no son necesarias, es mejor usar una cuenta local.


Es muy, muy, muy, muy importante asignar una buena contraseña para esta cuenta. Microsoft no nos cobrará por su tamaño así que como no tendremos que introducir esa contraseña todas las mañana al llegar a la oficina no os cortéis. 20 caracteres o más… sin cortarse. Una frase… «Voy a escribir 2 posts sobre IIS.»


A esta cuenta es necesario asignarle los permisos «Log on as a batch job» y «Log on as a service«. También es necesario que la cuenta que hayamos creado sea miembro del grupo «IIS_WPG«.


Luego deberemos dar permisos de lectura sobre los ficheros que vayamos a publicar. Por ejemplo, en el caso en el cual los ficheros de nuestro sitio están en Inetpubwwwroot por defecto los miembros del grupo Users ya tendrán permisos de lectura.


En el caso de que vayamos a ejecutar aplicaciones ASP.NET, tendremos que dar permisos de escritura en la carpeta %Windir%Microsoft.NETFrameworkversionTemporary ASP.NET Files


Nota: No os peleéis intentando ejecutar Reporting Services bajo otra cuenta que no sea Network Services. No os funcionará…


Iván

Spoofing de la variable "SERVER_NAME" de forma remota en IIS 5.X y IIS 6.0

El fallo permite modificar el valor de la variable «SERVER_NAME». Esto supone un problema para todas aquellas páginas ASP que en su código hagan uso de la misma. Incluso la página «500-100.asp» que incluye IIS 5.X y IIS 6 hace uso de esta variable. Eso permite revelar código de aquellas páginas que por algún motivo produzcan un error y lanzen esta página. Modificando la petición podemos lograr que la variable «SERVER_NAME» cambie su valor a «localhost» con lo cual la página «500-100.asp» revelará el código ASP causante del error.


Consejos


· Configurar siempre las cabeceras de host aunque sólo tengamos un sitio con un solo nombre en la misma dirección IP.


· Asociar el sitio a un interfaz de red específico.


· Modificar la página 500-100.asp localizada en %windir%/iishelp/common. Hacer el siguiente cambio, reemplazar la línea de código:


If (strServername = «localhost» Or strServerIP = strRemoteIP) And objASPError.File <> «?» Then


por


If (strServerIP = strRemoteIp) And objASPError.File <> «?» Then


Referencias


Remote IIS 5.x and IIS 6.0 Server Name Spoof


http://ingehenriksen.blogspot.com/2005/08/remote-iis-5x-and-iis-60-server-name.html


The custom error page 500-100.asp may return sensitive information in Internet Information Services 5.0 and in Internet Information Services 5.1 (KB-906910)


http://support.microsoft.com/default.aspx?scid=kb;en-us;906910


CAN-2005-2678 (under review)


http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2678


Microsoft IIS «500-100.asp» Source Code Disclosure


http://secunia.com/advisories/16548/